This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Options of fixing biggest alignment in PR target/38736
- From: "Richard Guenther" <richard dot guenther at gmail dot com>
- To: "Ian Lance Taylor" <iant at google dot com>
- Cc: "Ye, Joey" <joey dot ye at intel dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, "Lu, Hongjiu" <hongjiu dot lu at intel dot com>, "Andrew Pinski" <pinskia at gmail dot com>, "Guo, Xuepeng" <xuepeng dot guo at intel dot com>, "Girkar, Milind" <milind dot girkar at intel dot com>
- Date: Wed, 7 Jan 2009 17:03:47 +0100
- Subject: Re: Options of fixing biggest alignment in PR target/38736
- References: <F2363DE71B5050498545B523673042DE0190C38B78@pdsmsx503.ccr.corp.intel.com> <m3iqordsap.fsf@google.com>
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
>