On Fri, Sep 13, 2013 at 11:57 AM, James Greenhalgh
<james.greenha...@arm.com> wrote:
> On Fri, Sep 13, 2013 at 07:39:08PM +0100, Andrew Pinski wrote:
>> I don't think this works for big-endian due to the way ARM decided the
>> lanes don't match up with array entry there.
>
> Hi Andrew,
>
> Certainly for the testcase I've added in this patch there are no issues.
>
> Vector indexing should work consistently between big and little endian
> AArch64 targets. So,
>
> int32_t foo[4] = {0, 1, 2, 3};
> int32x4_t a = vld1q_s32 (foo);
> int b = foo[1];
> return b;
>
> Should return '1' whatever your endianness. Throwing together a quick
> test case, that is the case for current trunk. Do you have a testcase
> where this goes wrong?
I was not thinking of that but rather the definition of lanes in ARM64
is different than from element due to memory ordering of endian.
That is lane 0 is element 3 in big-endian. Or is this only for
aarch32 where the issue is located?
Thanks,
Andrew Pinski
>
> Thanks,
> James
>
