This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [AArch64] Implement vset_lane intrinsics in C
- From: Andrew Pinski <pinskia at gmail dot com>
- To: James Greenhalgh <james dot greenhalgh at arm dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>
- Date: Fri, 13 Sep 2013 14:47:01 -0700
- Subject: Re: [AArch64] Implement vset_lane intrinsics in C
- Authentication-results: sourceware.org; auth=none
- References: <1379097315-27647-1-git-send-email-james dot greenhalgh at arm dot com> <CA+=Sn1kp7s6UJ_5YF5jfHaw7bT0473D0RT_Jh9Krf=UYQgCSSg at mail dot gmail dot com> <20130913185750 dot GA4569 at arm dot com>
On Fri, Sep 13, 2013 at 11:57 AM, James Greenhalgh
<james.greenhalgh@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
>