This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch][ARM,AArch64] more poly64 intrinsics and tests
- From: Christophe Lyon <christophe dot lyon at linaro dot org>
- To: James Greenhalgh <james dot greenhalgh at arm dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, nd <nd at arm dot com>
- Date: Wed, 14 Dec 2016 23:09:16 +0100
- Subject: Re: [Patch][ARM,AArch64] more poly64 intrinsics and tests
- Authentication-results: sourceware.org; auth=none
- References: <CAKdteObQJA=UH0snnyPBnOJxQDaeaQMGxYDQj56=do3=FF4ZmQ@mail.gmail.com> <20161214165550.GA31834@arm.com>
On 14 December 2016 at 17:55, James Greenhalgh <james.greenhalgh@arm.com> wrote:
> On Mon, Dec 12, 2016 at 05:03:31PM +0100, Christophe Lyon wrote:
>> Hi,
>>
>> After the recent update from Tamar, I noticed a few discrepancies
>> between ARM and AArch64 regarding a few poly64 intrinsics.
>>
>> This patch:
>> - adds vtst_p64 and vtstq_p64 to AArch64's arm_neon.h
>> - adds vgetq_lane_p64, vset_lane_p64 and vsetq_lane_p64 to ARM's arm_neon.h
>> ( vget_lane_p64 was already there)
>> - adds the corresponding tests, and moves the vget_lane_p64 ones out
>> of the #ifdef __aarch64__ zone.
>>
>> Cross-tested on arm* and aarch64* targets.
>>
>> OK?
>
> The AArch64 parts of this look fine to me, but I do have one question on
> your inline assembly implementation for vtstq_p64:
>
>> +__extension__ extern __inline uint64x2_t
>> +__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
>> +vtstq_p64 (poly64x2_t a, poly64x2_t b)
>> +{
>> + uint64x2_t result;
>> + __asm__ ("cmtst %0.2d, %1.2d, %2.2d"
>> + : "=w"(result)
>> + : "w"(a), "w"(b)
>> + : /* No clobbers */);
>> + return result;
>> +}
>> +
>
> Why can this not be written as many of the other vtstq intrinsics are; e.g.:
>
> __extension__ extern __inline uint64x2_t
> __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> vtstq_p64 (poly64x2_t __a, poly64x2_t __b)
> {
> return (uint64x2_t) ((((uint64x2_t) __a) & ((uint64x2_t) __b))
> != __AARCH64_INT64_C (0));
> }
>
I don't know, I just followed the pattern used for vtstq_p8 and vtstq_p16
just above...
> Thanks,
> James
>
>> gcc/ChangeLog:
>>
>> 2016-12-12 Christophe Lyon <christophe.lyon@linaro.org>
>>
>> * config/aarch64/arm_neon.h (vtst_p64): New.
>> (vtstq_p64): New.
>> * config/arm/arm_neon.h (vgetq_lane_p64): New.
>> (vset_lane_p64): New.
>> (vsetq_lane_p64): New.
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2016-12-12 Christophe Lyon <christophe.lyon@linaro.org>
>>
>> * gcc.target/aarch64/advsimd-intrinsics/p64_p128.c
>> (vget_lane_expected, vset_lane_expected, vtst_expected_poly64x1):
>> New.
>> (vmov_n_expected0, vmov_n_expected1, vmov_n_expected2)
>> (expected_vld_st2_0, expected_vld_st2_1, expected_vld_st3_0)
>> (expected_vld_st3_1, expected_vld_st3_2, expected_vld_st4_0)
>> (expected_vld_st4_1, expected_vld_st4_2, expected_vld_st4_3)
>> (vtst_expected_poly64x2): Move to aarch64-only section.
>> (vget_lane_p64, vgetq_lane_p64, vset_lane_p64, vsetq_lane_p64)
>> (vtst_p64, vtstq_p64): New tests.
>>
>
>