Options of fixing biggest alignment in PR target/38736

[H.J. Lu]

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.

-- 
H.J.