Options of fixing biggest alignment in PR target/38736

[Richard Guenther]

On Wed, Jan 7, 2009 at 4:55 PM, Ian Lance Taylor <iant@google.com> wrote:
> "Ye, Joey" <joey.ye@intel.com> writes:
>
>> Option 3: Define BIGGEST_ALIGNMENT as a fixed value 32 bytes, for
>> all x86 target, and extend to 64 or more bytes in future.
>
> Assuming that code compiled with -mavx is intended to interoperate
> with code compiled without -mavx, I believe that this is the only
> viable long-term option.  Unfortunately that would be a change in the
> ABI for any code which exposes a struct with an attribute((aligned))
> field.
>
> BIGGEST_ALIGNMENT should always be a constant for code which can
> interoperate.
>
> I doubt that many ABIs expose a struct with a field with
> attribute((aligned)), but as far as I can see we are going to have to
> break those ABIs eventually.  The question now is whether we should
> break them for 4.4, for 4.5, or for some later version.
>
> That said, I should also note that the glibc solution has been to fix
> the maximum alignment at 8, in that that is the alignment which malloc
> returns on the x86.  I don't think that is a wise choice, but it is a
> choice that we could also make: we could simply fix the x86
> BIGGEST_ALIGNMENT at 16 and never change it in the future.

As there is no hardware implementation of AVX available I think
we definitely should stay with 16 for 4.4.  And IMNSHO also for
all future - __attribute__((aligned)) is part of the ABI, and if it is
not the only user of BIGGEST_ALIGNMENT then BIGGEST_ALIGNMENT
should be properly split between an ABI part and an optimization
related part.

Richard.

> Ian
>