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

[Jan Hubicka <hubicka at ucw dot cz>]

> 
> On Jan 13, 2004, at 5:03 PM, Jan Hubicka wrote:
> 
> >>
> >>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.
> >
> >Yes, it is tricky, but it would allow us to simply align frame when we
> >know we need it aligned.
> 
> The Darwin linker supports a scheme called "scatter loading," where 
> functions will be linked in the order given in a file supplied by the 
> user.  Since the Mach object format has no markers to say "function foo 
> begins here" and "function foo ends there," the linker assumes that 
> global labels in TEXT sections mark the beginning of functions, and 
> implicitly, the ends of other functions.
> 
> If the multiple entry points in this scheme are globally visible, the 
> Darwin linker will cut them apart when asked to scatter-load the 
> enclosing program.  :-(
> 
> Fortunately, work is underway to fix this in the Darwin linker...

Also the multiple entries are currently used only for local labels, so
this will just work.
I would really like to see multiple entry points concept to finally
work.  In combination with unit-at-a-time we can get pretty smart about
cheating i386 calling conventions to pass things in registers.
> 
> Hm.  What happens if -mfpmath=sse, and we try to load a 64-bit double 
> with 32-bit alignment into an XMM register ?

This is also safe.  Only 128bit entities can trap and there are special
moves for misalligned acceses.
> 
> Well, if noparm_v() has vector local variables, we know when it is 
> compiled if it has sufficient stack alignment or not, and we can tell 
> the user (probably a hard error).
> 
> If main() has 32-bit stack alignment...  shucks.  If main() has no 
> vector parameters, but wants to use vectors internally, it will work so 
> long as main() declares no vectors on its local stackframe (only 
> statics and globals).  But that won't stop GCC from creating vector 
> temporaries on main()s local stackframe (e.g. 
> want_vector(returns_vector())).
> 
> If the user compiles module A.c with align=2, and B.c with 
> align=vector, and there is a call from module A into a vector-infected 
> function in B, it will break, the only "fix" would be a link-time 
> check.  I guess we have to let this one break, silently.

Yes, only scenario one can not detect with this cheme is function having
no vector argument beging called from other module having low
preferred-stack-boundary.
> 
> >>To insure safety, any function that accepts vector arguments would
> >>insist upon a suitable stack alignment at compile time (hard error).
> >Outputting such hard errors when compiling function that accepts 
> >vectors
> >can be implementable and can tell user that -Os without
> >-mpreferred-stack-boundary is no-go, so perhaps this is pretty good
> >idea.  WHat other thinks?
> 
> Since any function that uses any 128-bit vector expression could spawn 
> a vector temporary, every such function needs the vector stack 
> alignment, and should insist upon it with an error.
> 
> Since MMX registers (64-bit vectors) will work with weaker alignment, I 
> suppose a warning ("weak stack alignment") would be in order.
> 
> The logical conclusion is that my initial suggestion to align the stack 
> for one call is moot.  I can envision a "safe mode" where a function 
> could realign its own stackframe, and be able to dereference possibly 
> misaligned parameters, but it's only use would be to find bugs that 
> would be resolved if the correct alignment was used everywhere.  Not 
> worthwhile.

It is not needed to expect missaligned operands.  The caler notice that
operands are vector and will align them.  The other part is dealt with
by Bernd's patch.
> 
> Suggestion: the testcase I offered should provoke an error, saying 
> "vector codes compiled with -Os need -mpreffered-stack-boundary=7" or 
> whatever.  In any case, the current practice of silently generating bad 
> code when vector.c is optimized with -Os is clearly unacceptable.  
> Would a patch with this approach be acceptable ?  Any suggestions where 

i think this is best sollution in short term.
> the checking should be done ?

Nope, unfortunately.  We don't have way to check that vector has been
spilled to stack frame I know of.  It probably needs special hook
somewhere.

Honza
> 
> >>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.  :-(
> >
> >You can do such tricks in init_cumulative_args code.
> 
> stuart hastings
> Apple Computer