Re: [GCC 3.0] Bad regression, binary size

[Joern Rennecke <amylaar at redhat dot com>]

> >Not quite -- you have to play games to get a proper pointer 
> >to the argument list so that you can do your step 3.
> 
> Ehh, what's wrong with just
> 
>         pushl %ebp
>         movl %esp,%ebp
>         subl $needed+16,%esp
>         andl $-15,%esp
> 
> which is just one instruction longer than the current regular frame 
> prologue, and leaves you with a aligned stack pointer AND a perfectly   
>       
> good way to get to the argument frame (the frame pointer).
> 
> Sure, if people use "alloca()" or other fancy stuff (variable-sized
> automatic variables etc), then you might need an extra instruction or   
> two to actually align the stack. How common is that? That case does need
> some extra work, I agree.

You can only ause your prologue variant when you could otherwide use
-fomit-frame-pointer.  And you also pay the price of having prefix bytes
for all the variable accesses on the stack.  Yet you won't get the benefit
of using %ebp as a general purpose registers.

> Anyway, there's a simpler approach for that: when passing in values that
> need alignment, we align the stack in the caller.  That way you know
> that your frame is always as aligned as it can be, AND the callee has
> the additional knowledge that because it was passed in a FP value it
> doesn't need to do the extra alignment itself.

IMHO marking functions in libc that have callbacks to user code or that
generally call - directly or indirectly - functions that do floating point
processing or callbacks, so that these specifically preserve 16 byte
alignment, should go a long way to avoid misalignment slowdown for programs
that want alignment, while not significantly slowing down integer code due
to data cahe misses.