This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


>  doubles be aligned on 8 byte boundarys
>
>  long doubles be aligned on 16 byte boundarys
>
>  objects >= 32 bytes in size be aligned on 32 byte boundarys
>
>I believe that they all have similar issues with regards to encouraging
>gcc to align them for optimal performance on the stack so it's possible
>that they may all be "solved" with the same solution in the back end.
>
>Just something to think about. :-)

I'm all for that.  g77 doesn't (yet) support long doubles (these
are 80-bit, IIRC), but certainly both g77 and its run-time
library make use of larger objects (EQUIVALENCE aggregates on the
stack, plus plenty of internally generated structures to pass
between the generated code and the library).  Though I'd be
interested in seeing an example of an app that is significantly
speeded up by aligning long doubles and aggregates according to
Intel's spec, over and above what is achieved if we simply align
non-ABI doubles according to that spec -- it'd surprise me if
such an app existed and was written in Fortran.  (I'd guess it'd
have to have tight inner loops using local EQUIVALENCE vars,
because I think that anytime internal stack-based aggregates are used,
the run-time library is involved, and that usually means I/O
and other operations that are inherently slow, i.e. not tight and
probably not helped noticeably by improving alignment.)

So IMO it'd indeed be nice to keep the additional alignment advice
in mind when we improve the `double' alignment situation, but
not necessary to actually implement it.  The `double' alignment
stuff really means big speedups for some codes.

        tq vm, (burley)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]