Re: ix86 `double' alignment (was Re: egcs-1.1 release schedule)

[Craig Burley <burley@gnu.org>]

>Basically the ABI just mandates a 4 byte alignment, we get better
>performance if we could get the args 8 byte aligned.  But  I'll be
>a little suprised if we can do this without having the callee copy
>it out of the arglist to an aligned memory slot.

I guess we shouldn't try aligning outoing/incoming doubles passed
"by value" (C style) at all, now that I think about it more.  It'd
surely break the ABI.

>My gut tells me aligning variables inside the arglist isn't going to
>win as much as the other cases noted above.

Especially not for Fortran, since g77 doesn't generally pass doubles
(or anything) by value, with some exceptions for the run-time
library.

And, I suspect the real performance penalties come mostly from arrays
and such inside loops anyway.  People don't pass arrays by value
(not usually ;-), and if an incoming by-value double is used
frequently in a loop, all that's really needed is to make the
compiler smart enough to make an aligned copy of that argument...but
let's wait until we see real code that could benefit from that.

>  > Again, what is the *real* problem with just doing what is currently
>  > done for that case, ending up with a misaligned double arg for
>  > the incoming procedure -- must it really assume its double is
>  > 64-bit aligned?  Or is this really just an internal problem with
>  > gcc's housekeeping?
>There's no problem other than the performance issues.  The code will
>still work.  Maybe that's where we're mis-communicating :-)

Oh, okay, good, indeed we were.  My priorities here are first to
make sure nothing that does work stops working; second to make
sure nothing reasonable suddenly goes lots slower; third to
make lots of stuff go faster.  Its the third priority we're discussing,
of course, but some of the solutions that have been proposed
(including, I though, mine) might violate the first two.

But I now don't see how we can align doubles in an arglist while
both aligning the callee's incoming stack frame *and* meeting the
ABI requirements.  After all, any arglist consisting of arbitrary
float, double, and int (32-bit) must be laid out with no padding
between args and no padding between the last-pushed arg (the
first arg and the return address `call' pushes), right?  The only
way to ensure that the incoming stack frame is aligned is to
optionally reserve a 4-byte pad before pushing any of the args,
as we've discussed.

So, AFAICT, the doubles end up where they end up, either aligned
or not, and there's nothing we can do about it at that point.

Of course, the callee can, as you point out, copy them to aligned
locations on its stack frame and use that, which is worthwhile
if it sees the potential for frequent references during the call.

>Before we can do *anything* about the alignment of args and autos we
>first need to get the stack pointer aligned at all times.  Let's deal
>with that first, then try to come up with solutions for the auto and
>argument alignment afterwards.

Uh-guh-reed!  :)

        tq vm, (burley)