This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [ARM] Fix vget_lane for big-endian targets
- From: Christophe Lyon <christophe dot lyon at linaro dot org>
- To: Kyrill Tkachov <kyrylo dot tkachov at arm dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 4 Aug 2015 14:09:06 +0200
- Subject: Re: [ARM] Fix vget_lane for big-endian targets
- Authentication-results: sourceware.org; auth=none
- References: <1437033404-4759-1-git-send-email-christophe dot lyon at linaro dot org> <55AE50B5 dot 1040507 at arm dot com>
On 21 July 2015 at 16:01, Kyrill Tkachov <kyrylo.tkachov@arm.com> wrote:
>
> On 16/07/15 08:56, Christophe Lyon wrote:
>>
>> AdvSIMD vget_lane tests currently fail on armeb targets when dealing
>> with vectors of 2 64-bits elements. This patches fixes it, by adding a
>> code fragment similar to what is dones in other cases. I could have
>> simplified it a bit given that the vector width is known, but I chose
>> to hardcode 'reg_nelts = 2' to keep the code closer to what is done
>> elsewhere.
>>
>> OK for trunk?
>>
>> Christophe
>>
>> 2015-07-16 Christophe Lyon <christophe.lyon@linaro.org>
>>
>> * config/arm/neon.md (neon_vget_lanev2di): Handle big-endian
>> targets.
>
>
> I see we do this for other lanewise patterns as well.
> Has this been tested on an arm big-endian target?
>
> If so, ok for trunk.
I forgot to mention that yes, I actually tested it on arm big-endian,
using QEMU.
Christophe.
>
> Thanks,
> Kyrill
>
>
>>
>> diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
>> index 654d9d5..59ddc5b 100644
>> --- a/gcc/config/arm/neon.md
>> +++ b/gcc/config/arm/neon.md
>> @@ -2736,6 +2736,19 @@
>> (match_operand:SI 2 "immediate_operand" "")]
>> "TARGET_NEON"
>> {
>> + if (BYTES_BIG_ENDIAN)
>> + {
>> + /* The intrinsics are defined in terms of a model where the
>> + element ordering in memory is vldm order, whereas the generic
>> + RTL is defined in terms of a model where the element ordering
>> + in memory is array order. Convert the lane number to conform
>> + to this model. */
>> + unsigned int elt = INTVAL (operands[2]);
>> + unsigned int reg_nelts = 2;
>> + elt ^= reg_nelts - 1;
>> + operands[2] = GEN_INT (elt);
>> + }
>> +
>> switch (INTVAL (operands[2]))
>> {
>> case 0:
>
>