RE: g++ 3.4.0 cygwin, codegen SSE & alignement issues

[Tim Prince <tprince@computer.org>]

At 08:51 AM 4/28/2004, Dave Korn wrote:

> > -----Original Message-----
> > From: cygwin-owner On Behalf Of tbp
> > Sent: 28 April 2004 16:16
>
>[  Now x-posted to gcc list, since it's seemingly a gcc issue rather than a
>cygwin environment issue.  You might also care to refer to the current
>discussion on the gcc-patches mailing list under the thread
>
>"Re: [Bug target/15106] Vector varargs failure for AltiVec on ppc32 linux"
>
>which is discussing the same problem arising on ppc targets.  ]
>
>
> > > It's an ABI incompatiblity issue, GCC expects a 16-byte
> > aligned stack,
> > > but the Windows ABI, to the extent one actually exists, only assumes
> > > a 4-byte aligned stack (and even that's not a strict requirement).
> > Is there an official or semi official way to fix it or do i have to
> > insert something like "mov esp, eax; and 0x15, eax; sub eax,
> > esp" where
> > it helps?
>
>   I'd recommend doing that in the startup code in gcc's crt0.s myself.  The
>real question is, is the compiler generating code that guarantees the stack
>stays aligned, so you can do that just once at startup?  It certainly ought
>to.
>
> > I understand -mfpmath=sse is flagged as experimental. What i
> > don't get
> > is why the compiler emits totally bogus code when using default
> > switches: -O3 -march=k8 -> boom. -O3 -march=pentium4 -> boom.
>
>   The division of responsibility between OS, CRT/startup and compiler leaves
>it unclear as to who is supposed to ensure the alignment of the stack.  IMO,
>it's a compiler's problem to see to it that if the stack starts off aligned
>it remains that way, by always generating stack frames that are a multiple
>of the alignment requirement, and it's the CRT/startup code that is
>responsible for mediating between what the compiled code requires and what
>the underlying OS/arch provides for stack pointer alignment at startup.  Of
>course, that's IMO, and my opinion is hardly definitive.
>

As Dave said, this is more of a gcc than a cygwin issue, provided that 
cygwin doesn't defeat one of the functions of binutils or gcc (as it did in 
the past).  gcc made a decision, which is different from commercial 
compilers, that stack alignment requires each function to be compiled with 
-mpreferred-stack-alignment=4, so that it passes an aligned stack to the 
callee.  binutils has to be built with maximum alignment set to at least 4 
(as cygwin has done for some months now).

stack-alignment=4 is a default for gcc, except when -Os is specified.  If 
you use -Os, and any called function uses SSE, you must over-ride the stack 
alignment set by -Os.  gcc did this because the stack alignment caused some 
applications (which don't use SSE) to fail with stack overflow.  I suspect 
this could happen in cygwin.

Because of the different division of responsibilities, if a function built 
by gcc is called by a function built by a commercial compiler (or by gcc 
-Os), the stack has a 75% probability of being mis-aligned.  It may be 
possible to overcome this by having a wrapper function between, which is 
built by gcc with alignment specified, but does not use SSE.

Presumably, there is a performance advantage to gcc of assuming that the 
caller passes an aligned stack, but not enough to persuade commercial 
compilers to adopt a compatible scheme.


Tim Prince