[PATCH] D33205: ARM] Fix Neon vector type alignment to 64-bit

[Stephen Hines via llvm-commits]

On Tue, May 16, 2017 at 9:53 AM, Renato Golin <renato.golin at linaro.org>
wrote:

> On 16 May 2017 at 17:31, Stephen Hines <srhines at google.com> wrote:
>
>> I would request that this not change for Android. Our implementation has
>> been using 128-bit alignment for far too long, and I would rather see that
>> document updated to say 128-bit alignment to match the behavior as
>> implemented. Changing this in LLVM now would cause all sorts of binary
>> compatibility issues that we don't want to force on our users. Past
>> vector-related ABI issues have been grandfathered in before, so I do hope
>> you reconsider this patch.
>>
>
> Should be simple to make that an environment-specific behaviour, no?
>

I'm ok with making it conditional, assuming that the ABI doc can be updated
to say that the alignment is implementation-defined. Otherwise, the doc
goes against the Android implementation, which makes it hard for others to
understand what it happening (and why).

Do you really want to do this to other users too? Vector types are more
common in 2017 than they were 5-10 years ago. Last time there was a
discrepancy with the implementation vs. the specification, ARM sided with
Apple and rewrote the specification (something that I still deal with,
despite Android shipping the correctly specified version for quite some
time). In that case, the implementation and later, the specification, were
changed to satisfy a different set of requirements. Here, the
implementation has existed for an even longer time, so I think it is a
mistake to change this now. Does the ARM compiler do something different
(or does GCC)? Last time I checked, ext_vectors couldn't be safely used
across compilers for various other reasons beyond just alignment/padding.

Thanks,
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170516/98a2b26b/attachment.html>