On Wed, Jan 7, 2009 at 4:55 PM, Ian Lance Taylor <i...@google.com> wrote: > "Ye, Joey" <joey...@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 >
