arm_neon.h / vext_u64 (uint64x1_t __a, uint64x1_t __b, __const int __c)
Thu Sep 10 10:35:48 GMT 2020
Thanks a lot! Regards, Jochen
Von meinem iPhone gesendet
> Am 10.09.2020 um 10:35 schrieb Tamar Christina <Tamar.Christina@arm.com>:
> Hi Jochen,
>> -----Original Message-----
>> From: Jochen Barth <email@example.com>
>> Sent: Thursday, September 10, 2020 9:14 AM
>> To: Tamar Christina <Tamar.Christina@arm.com>
>> Cc: gcc-help <firstname.lastname@example.org>
>> Subject: Re: arm_neon.h / vext_u64 (uint64x1_t __a, uint64x1_t __b,
>> __const int __c)
>> Dear Tamar,
>> Sorry, I do no get the point:
>>>>> EXT is a byte level extract, if you have a 64 bit vector and a
>>>>> 64-bit type like uint64x1_t then the only possible index for n is 0.
> Because those intrinsics are not doing byte level extraction. They are convenience functions that
> do not allow partial extraction of a type. For instance vext_s16 which takes an int16x4_t as input
> restricts the values of n to 0 to 3 because when used with the EXT instruction it always
> makes sure they're a multiple of 2 bytes since a int16 is two bytes.
> A uint64x1_t is a vector of 8 bytes which the intrinsic does as a group of 8 bytes since it
> Always wants to extract whole numbers. As such the only possible index is 0.
> To get the behavior you have in your example you need to do the extraction on bytes using
> vext_u8 which will allow you to corrupt the number. i.e.
> what you want is
> vreinterpret_u64_u8 (vext_u8 (vreinterpret_u8_u64 (a), vreinterpret_u8_u64 (b), <number>))
> where your extraction happens on bytes. In this case n has the range 0-7.
> Instead of looking at the Arm ARM you should look at the definition of the intrinsics
>> But my previous examples with n=c=1..7 showed that different (n=c)'s are
>> why is "the only possible index for n=0" ?
>> Kind regards, Jochen
More information about the Gcc-help