Re: recommended alignment for local i386 FP variables patch

[John Vickers <jvickers at acorn dot com>]

Jeffrey A Law wrote:
> 
>   In message <199812041752.MAA03801@jwlab.FEITH.COM>you write:
>   > > This scheme is going to require an extra register at all times
>   >
>   > It doesn't require any more registers than the "normal" case of
>   > compiling a function with a frame pointer and it only affects
                                                    ^^^^^^^^^^^^^^^^
>   > those functions which may have a local variable which requires
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   > extra alignment.  This does mean that the hard frame pointer
      ^^^^^^^^^^^^^^^^
>   > can't be eliminated in this case.  However functions which
>   > don't need extra alignment are not affect and the frame pointer
>   > can be eliminated.
> There are two cases:
>   Either the offset between the stack and frame pointer is not a compile
>   time constant.
>   Or the offset between the frame pointer and arg pointer is not a compile
>   time constant.
> 
> Either way, that is a lose.  In any function that has to align the stack
> pointer you will have to have either a frame pointer or an arg pointer.  That
> is a major lose, particularly for the masses that compile with
> -fomit-frame-pointer.
> 
>   > I'm not sure how "grody" this make the prologue ... it only adds
>   >
>   >   andl $0xfffffff8,%esp
>   >
>   > to the prologue.
> I consider it "grody" :-)


> 
>   > > thus the offset to the args is not a compile time constant.  Bad news.
>   >
>   > Ah, however the offset to the args * is * a compile time constant with
>   > regards to the hard frame pointer.
> But then the frame pointer is not at a constant offset from the stack pointer
> and you can not eliminate the frame pointer.
> 
>   > > Bernd put into the compiler recently.  Then we have the compiler always
>   > > allocate doubles at an 8 byte offset from the stack pointer.
>   >
>   > Doesn't this mean that extra instructions will be generated to align the
>   > stack for * all * function calls in addition to potentially requiring extra
>   > instructions in the prologue to keep the stack aligned?  My approach
>   > doesn't require any extra instructions in the caller and only affects
>   > callees which need the extra alignment.
> Not exactly.  It requires nothing new in the prologue, but may require an
                                                        
^^^^^^^^^^^^^^^^^^
> extra word push at call sites.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> It does not guarantee stack alignment.  Instead it guarantees alignment if
 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> presented with correct alignment.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> [...]
> At a call site, we may have to add an extra push if the function call does not
> push a multiple of 8 bytes of argument space.

Have I got this right ?

John W has a solution which does guarantee that 8-byte alignment
will be provided if needed, an has no impact on code (i.e. code not
using doubles) which does not need such alignment.

Jeff favours Bernd's solution which adds extra insns at a large number
of call sites, even if the generated code won't benefit from such
alignment
(it doesn't use doubles). Bernd's solution does not guarantee alignment
of doubles, even when the code would benefit from it.

The principle that the cost of a feature should be bound to its use
makes
John's solution look much better to me.  Particularly since the code
most
people run most of the time doesn't do a whole lot of double arithmetic.

Maybe time to do some experiments on both techniques ?

John.