[PATCH] AARCH64_BE load/store rules fix for ARM ABI

[Jiangning Liu]

Tim,

Thanks for your example.


> Well, take a look at the file I attached for example. Running "opt" on
> it allows inlining and the real alignment of 8 is propagated to the
> load. As a result, you'd get different results depending on
> optimisation level (if we used "ld1 {v0.4h}").
>
>
I don't this is a good example to illustrate the bad consequence. For this
case, we would always have correct result for little-endian, right?

And for big-endian, the semantic should be guaranteed by the programmer, so
I would treat it as invalid code, and programmer intends to mixing/casting
the alignment. If programmer wants to have a 'stable' result for both
'inline' and 'non-inline', she/he should not explicitly write alignment
like this.

If this is generated by auto-vectorizer, I would expect the action of
storing data into that var uses st1, then the 'var with alignment 8' would
be transparent, I mean if only we always use ld1/st1 in pair, we would not
have issue. If the code writing var is in a different module, and probably
it's possible the action of writing var is str, but isn't it an interface
programmer should have known about the layout and why she/he use 'alignment
2' on purpose?

As Albrecht mentioned, maybe the solution is "The frontend must give the
backend a totally different type for short vectors". To some extension, I
agree with his point.


> > If we don't use ld1 for "align 2" case, which instruction we should
> > use? ldr requires total size alignment, otherwise exception would
> > be raised if strict alignment is enabled.
>
> If we decided to support strict alignment mode efficiently, we would
> probably want to emit an "ld1 {v0.8b}" (i.e. always use the .8b or
> .16b version), since that's got the same semantics as ldr.


It is only true for little-endian, isn't it?

If we always use ldr/str for bit-endian without caring about alignment,
1) It would not work for non-strict mode, because the address might be
unaligned.
2) The data may come from a real array of elements rather than HVA, and
the semantic of using ldr/str is conflict with the end-user's definition,
because on memory address of an array, we always expect the element with
lower index is located at lower address. it would bring issues crossing
different modules built with different tools.

Thanks,
-Jiangning
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140313/e11f06e3/attachment.html>