Re: x86: -Os -msse2 needs -maccumulate-outgoing-args

[Stuart Hastings <stuart at apple dot com>]

On Jan 13, 2004, at 12:51 PM, Jan Hubicka wrote:

> > This testcase
>
> Hi,
> this is not -maccumulate-outgoing-args that breaks, it is
> -mpreffered-stack-boundary=2 implied by -Os.  We still don't have the
> dynamic stack alignment code merged in, unfortunately.

I looked at this, and it's not clear to me how it would help.  Here's 
the thread:

	http://gcc.gnu.org/ml/gcc-patches/2002-05/msg02282.html

Also, given the unique semantics of the Darwin linker, I'm not sure 
this could work on Darwin today (our linker "knows" too much about 
entry points).  I think this would be implementable with a future 
Darwin linker.

> It would be probably sane to give some warning or hard error when SSE
> register is put onto stack, but I don't see easy way to do this, as we
> should not output such a warning for long doubles that have same
> alignment properties.

I'm sorry, I didn't fully understand this.

If a long double has the same alignment properties as a vector, then 
misaligned loads of that long double should fault just like a 
misaligned vector load (?).  If the long double prefers a high 
alignment, but will work with lesser alignment, then its alignment 
requirements aren't the same as a vector (??).

> Ideas?

Here's another approach:

If main() is part of a module compiled with 
-mpreferred-stack-boundary=2, and main() wants to pass a vector 
argument to function foo_v() in another module, main() knows that A) 
main()s own stackframe is not aligned, and B) since foo_v() is 
expecting a vector parameter, foo_v() must have been compiled with a 
suitable stack alignment.  (O.K., it's a weak argument.)

Instead of generating a warning, howabout forcing the stack into 
alignment just for the call to foo_v() ?  Sort of a per-call variant of 
FORCE_PREFERRED_STACK_BOUNDARY_IN_MAIN (see 
function.c:expand_main_function()).

To insure safety, any function that accepts vector arguments would 
insist upon a suitable stack alignment at compile time (hard error). 
The problem I see here is what to do when a function accepts variable 
arguments...

Ack!  I just suggested an additional check to calls.c; it is already 
much too complicated.  :-(

stuart hastings
Apple Computer