This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: x86 double alignment (was egcs-1.1 release schedule)


>The original patch turned on -mstack-align-double, which I thought is safe,
>but it isn't. I got a report from a windows user that it breaks most windows
>function semantics, as these functions deallocate the stack themselves. In
>this case, -mstack-align-double will break the program.

Wait, how can these functions deallocate the stack themselves when
the *caller* also is deallocating the stack, as is normally the
case for x86-ABI code?  Aren't these functions essentially violating
the ABI in a way the compiler producing code that calls them *must*
know about?

What I haven't looked into yet is whether subtracting 4 from %esp
before pushing args might upset some varargs/stdargs implementation
on the callee side (that the caller doesn't know about), i.e. if
that can even happen.

>If we had -mstack-align-double in egcs, maybe glibc could compile _some_ functions
>(like qsort or __libc_start) with it, so the problem of combine breaking code
>is solved, so we can either
>
>- document that -mno-stack-align-double should be used when linking against third-party-libs
>- not making it on by default.

If it's not on by default, it's of only limited benefit, though that'd
still take care of lots of Fortran users who are willing to learn about
and use an option like -mstack-align-double.

My feeling is that if -mstack-align-double doesn't break the ABI,
then make it the default.  Any bugs resulting from this are thus
likely to be because *other* code breaks the ABI.  Our compiler
should be "told" about those codes explicitly anyway, via attributes
or something.

>there are also speed issues, i.e. in integer-only programs, -mstack-align-double
>slows down code (a bit), so it should probably be disabled anyway.

I was thinking earlier this week that, for example, the Linux kernel
perhaps would run faster if -mno-stack-align-double was specified
for compiling it.

But, the problem is that if we don't make -mstack-align-double the
default, lots of code that uses `double' will not get proper
alignment and will continue have *big* performance degradation.

>-marg-align-double never worked, due to limitations in calls.c (FUNCTION_ARG_BOUNDARY
>is effectively ignored on calls, but not within the called function), and
>breaks the abi, and was thus always optional. (it would align doubles in the
>argument area, this _severely_ breaks the abi, of course)

Yup, we pretty much ended up concluding this (I should say, I finally
understood what others were saying).

        tq vm, (burley)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]