New optimized string routines for Intel and alignment of stack.
Florian Weimer
fweimer@redhat.com
Tue Jun 7 09:52:00 GMT 2016
On 06/07/2016 07:56 AM, Carlos O'Donell wrote:
> H.J.,
>
> We have had several users that have built legacy applications
> for 32-bit x86 with stack alignment that does not match the
> ABI.
Let's say the GNU project broke the i386 ABI, which is more accurate.
The stack pointer alignment requirement is a recent change.
> In all of these cases it has to do with the application
> having been compiled with -falign-stack=assume-4-byte which
> violates the ABI, usually with icc. However, if you're careful
> it all just works.
It will get worse with increased vectorization and GCC 6. We already
saw this on x86_64 with the non-compliant malloc in tcsh, where GCC 6
used vector instructions to copy a struct dirstream object. I assume
this could easily happen with any stack-to-stack copy with SSE2 enabled.
Currently, GCC does not seem to exploit the fact that it knows the
alignment of stack objects. I played with this:
struct fields
{
double a, b;
};
struct fields get (void);
void put (struct fields *, struct fields *);
void
copy (void)
{
struct fields f1 = get ();
struct fields f2 = f1;
put (&f1, &f2);
}
And: gcc -m32 -O3 -msse2 -march=westmere -mtune=westmere -o- -S
stack-align.c
I expected to see an SSE load/store for the copy, but that's not what I got.
I think we need to decide if we want to roll back the ABI change before
GCC learns about this optimization because eventually, it will not just
be a matter of string routines. Any glibc code optimized for 32-bit x86
CPUs with SSE2 enabled could be affected.
Florian
More information about the Libc-alpha
mailing list