This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH][AArch64] Implement new intrinsics vabsd_s64 and vnegd_s64
- From: Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>
- To: James Greenhalgh <james dot greenhalgh at arm dot com>, Vlad Lazar <Vlad dot Lazar 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>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>
- Date: Wed, 01 Aug 2018 12:52:41 +0100
- Subject: Re: [PATCH][AArch64] Implement new intrinsics vabsd_s64 and vnegd_s64
- References: <email@example.com> <20180731214839.GE1826@arm.com>
On 31/07/18 22:48, James Greenhalgh wrote:
On Fri, Jul 20, 2018 at 04:37:34AM -0500, Vlad Lazar wrote:
> The patch adds implementations for the NEON intrinsics vabsd_s64 and vnegd_s64.
> Bootstrapped and regtested on aarch64-none-linux-gnu and there are no regressions.
> OK for trunk?
> +__extension__ extern __inline int64_t
> +__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> +vnegd_s64 (int64_t __a)
> + return -__a;
Does this give the correct behaviour for the minimum value of int64_t? That
would be undefined behaviour in C, but well-defined under ACLE.
Similar intrinsics such as vneg_s8, vneg_s16 etc use the same implementation
(though on vector types) and the test in the testsuite for them (gcc.target/aarch64/vneg_s.c)
has cases for these limit values, so it seems to work there.
Does the fact that those are using vector types rather than the scalar int64_t matter?