Re: Options of fixing biggest alignment in PR target/38736

[Ian Lance Taylor <iant at google dot com>]

"H.J. Lu" <hjl.tools@gmail.com> writes:

> On Thu, Jan 8, 2009 at 10:49 AM, Ian Lance Taylor <iant@google.com> wrote:
>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>
>>> It it hard to guess what the alignment should be for C++ new operator.
>>> Whatever you choose today may not be appropriate tomorrow
>>> or for others. I think g++ should issue a warning when new operator
>>> is used on a type whose alignment greater than MALLOC_ABI_ALIGNMENT:
>>
>> The real problem is not a single value, but an array of some type.
>> Auto-vectorization optimizations may apply, and they may require a
>> larger alignment, and the compiler may believe that the memory
>> allocator provides a larger alignment than it actually does.  The
>> compiler can not know the minimal alignment returned by the memory
>> allocator, because the user can change the memory allocator.
>>
>> We need to write __attribute__ ((aligned (XXX))) accordingly.
>>
>> I see that MALLOC_ABI_ALIGNMENT exists, but the value is overly
>> conservative by default, and no target defines it, and the only thing
>> which actually uses is the Ada frontend.
>>
>
> Compiler can only use the minimum alignment on memory returned
> by memory allocator, which is MALLOC_ABI_ALIGNMENT.  I am
> not sure how __attribute__ ((aligned (max)) can solve this.

But the compiler does not actually use MALLOC_ABI_ALIGNMENT,
MALLOC_ABI_ALIGNMENT is not correctly defined for most target, (i.e.,
actually using the current definition would be an optimization
regression in some cases), and even if the compiler did use
MALLOC_ABI_ALIGNMENT there is no guarantee that it would be correct.

> For the memory allocator writers, they should provide an interface
> with a parameter to specify alignment requirement. User can use
> __attribute__ ((aligned (XXX))) to tell compiler memory alignment.

Think harder about new[] and auto-vectorization.  What you describe
seems to me to be a theoretical argument rather than a practical one.

Ian