Re: Arranging for -Os to imply -mpreferred-stack-boundary=2 on x86

[Jan Hubicka <jh at suse dot cz>]

> On Oct 23, 2001, Jan Hubicka <jh@suse.cz> wrote:
> 
> > Also note that I do have patches somewhere to compute alignment required
> > by given function after reload and use the value when compiling later
> > calls to that function.
> 
> So we're talking about two different things.  The attribute I
Sure, this is just trick how to make -mpreferred-stack-boundary cheaper
and your patch has rang the bell that I do have it done and believe
it is usefull.
> suggested would get a function to ensure its stack pointer is aligned
> to a certain boundary, so that its automatic variables are properly
> aligned.  But now I realize this would require an additional register,
> because %ebp can't be re-aligned otherwise you can't get to the
> arguments.

There is RH patch to do the dynamic stack alignment better than current's
Richard method does.  Notice that the current method requires all callers
to be notified about preferred boundary, not calee as main's stack frame
is not aligned.

The patch is able to produce multiple entry points and get rid of
extra alignments if the alignment is already done by outer function.

It needs major changes to be acceptable tought.
> 
> Getting the caller to align the stack would also have the advantage
> that sometimes the caller may be able to guarantee that the stack is
> already properly aligned, thus avoiding the overhead in the callee of
> introducing additional stack alignment, and the arguments, when passed
> in the stack, would also be aligned correctly.
> 
> So I guess this is the way to go.
> 
> The problem that remains is that the preferred alignment of a function
> won't be enforced when it's called from another translation unit,
> unless the alignment requirements are explicitly stated in a function
> declaration visible for the caller.  But then, when performance
> matters so much, one may always make the actual hotspot into a static
> function called by an exported wrapper function that introduces the
> alignment and calls the other function.  But figuring out how this
> interacts with tail calls and inlining is left as an exercise to the
> reader :-)
Hmm, this looks quite tricky for the user.  We basically want to generate
good FP performance (and working SSE code, where alignment is a must) w/o
too much of help from programmer.

Honza
> 
> -- 
> Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
> Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
> CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
> Free Software Evangelist    *Please* write to mailing lists, not to me