From mboxrd@z Thu Jan 1 00:00:00 1970 From: Craig Burley To: john@feith.com Cc: law@cygnus.com, d.love@dl.ac.uk, toon@moene.indiv.nluug.nl, egcs@cygnus.com Subject: Re: ix86 `double' alignment (was Re: egcs-1.1 release schedule) Date: Tue, 23 Jun 1998 14:56:00 -0000 Message-id: <199806231929.PAA12377@melange.gnu.org> References: <199806231723.NAA12151@jwlab.FEITH.COM> X-SW-Source: 1998-06/msg00808.html > 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)