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
On Thu, Jan 8, 2009 at 7:56 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Wed, Jan 7, 2009 at 4:44 PM, Ian Lance Taylor <iant@google.com> wrote:
>> "Ye, Joey" <joey.ye@intel.com> writes:
>>
>>> From: Ian Lance Taylor [mailto:iant@google.com]:
>>>> Therefore, I propose that we do the following:
>>>>
>>>> 1) Introduce __attribute__ ((aligned (scalar))). This will be
>>>> documented as having a fixed value for each ABI. The value will be
>>>> guaranteed to be sufficient to hold any ordinary non-vector type.
>>>> The default will be BIGGEST_ALIGNMENT. The value for the
>>>> x86/x86_64 will be 128.
>>>>
>>>> 2) Introduce __attribute__ ((aligned (max))). This will be documented
>>>> as having the largest value available for any version of the
>>>> architecture, and thus in particular it may change if new versions
>>>> of the architecture are released. The value will not change based
>>>> on command line options which do not change the ABI; that is, if it
>>>> is possible to link together two files compiled with different set
>>>> of command line options and expect the result to work, then those
>>>> command line options must not change the value of this attribute.
>>>> The value will be guaranteed to be sufficient to hold any type,
>>>> including any vector type. The default will be BIGGEST_ALIGNMENT.
>>>> The value for the x86/x86_64 will (presumably) be 256.
>>> To me "new version of x86 architecture are released" usually means
>>> "change based on command line option". How about the default value
>>> grow to 512 or even higher in future?
>>
>> There is a command line option change, sure, but in general, as far as
>> I know, files compiled with -march=NEW can be linked with files
>> compiled with -march=OLD, and the result is expected to work.
>>
>> If that is not the case--if files compiled with -march=avx and
>> -march=i386 (or -march=nocona) can not be linked together and
>> work--then there is no problem here.
>>
>> Ian
>>
>
> Given that __attribute__ ((aligned (max))) may change, I don't
> think it is very useful. A portable generic memory allocator should
> take an additional argument for alignment.
>
If we really want the maximum useful alignment for the target machine
we are compiling for, I would prefer __attribute__ ((aligned (best)))
and document that it may be changed by -mXXX.
--
H.J.