On Wed, Jan 7, 2009 at 7:55 AM, 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. >
Fixing BIGGEST_ALIGNMENT to 16 may require extensive changes. I am thinking to add DEFAULT_ALIGNMENT with #ifndef DEFAULT_ALIGNMENT #define DEFAULT_ALIGNMENT BIGGEST_ALIGNMENT #endif and use it only for attribute((aligned)). x86 will define DEFAULT_ALIGNMENT as 16. Of course, we need to update document for attribute((aligned)). -- H.J.
