Re: PATCH: PR target/38736: [4.4 Regression] -mavx can change the ABI via BIGGEST_ALIGNMENT

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Wed, Jan 7, 2009 at 12:13 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Wed, Jan 07, 2009 at 11:59:14AM -0800, Ian Lance Taylor wrote:
>> How about something like this for the second paragraph?  Other
>> opinions welcome.
>>
>>     When you leave out the alignment factor in an @code{aligned}
>>     attribute specification, the compiler sets the alignment for the
>>     variable or field to the largest useful alignment on the target
>>     machine for which you are compiling.  Doing this can often make
>>     copy operations more efficient, because the compiler can use
>>     whatever instructions copy the biggest chunks of memory when
>>     performing copies to or from the variables or fields that you have
>>     aligned this way.
>>
>>     When new instructions are added to a processor, they may cause the
>>     largest useful alignment to increase.  A compiled library should
>>     not rely on the precise effect of the @code{aligned} attribute
>>     with no alignment factor remaining the same across different
>>     compiler versions.  For example, if you expect to distribute a
>>     binary version of a library which will be linked with code
>>     compiled with future versions of GCC, be careful about putting
>>     something like this in a header file for users of the library:
>>
>>     @smallexample
>>     struct s { char a; char buf[64] __attribute__ ((aligned)); };
>>     extern void f(struct s*);
>>     @end smallexample
>>
>>     The precise offset of the field @code{buf} may change in different
>>     compiler versions.
>
> That doesn't reflect what the patch does for i386 (where it doesn't
> set the default alignment to the largest useful alignment, but to the
> 4.3 and older default for compatibility) and I think it would be a very bad
> idea to change it between compiler versions, that would make the aligned
> attribute quite useless.  glibc uses it in its exported headers, so does
> libstdc++ and so does unwind.h.
>

I agree that we should fix it to 16 for x86. If we do want a maximum
alignment, we can introduce another attribute, like

 __attribute__ ((max_aligned))

and document it may change, depending on -mXXX.


-- 
H.J.