This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, AArch64] Add x86 intrinsic headers to GCC AArch64 taget
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "Hurugalawadi, Naveen" <Naveen dot Hurugalawadi at cavium dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "Pinski, Andrew" <Andrew dot Pinski at cavium dot com>, James Greenhalgh <james dot greenhalgh at arm dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, Marcus Shawcroft <marcus dot shawcroft at arm dot com>
- Date: Thu, 1 Jun 2017 21:23:56 +0000
- Subject: Re: [PATCH, AArch64] Add x86 intrinsic headers to GCC AArch64 taget
- Authentication-results: sourceware.org; auth=none
- References: <CO2PR07MB2694F86C1521A6607290071983F30@CO2PR07MB2694.namprd07.prod.outlook.com>
On Mon, 29 May 2017, Hurugalawadi, Naveen wrote:
> Hi,
>
> Please find attached the patch that adds first set of X86 instrinsic
> headers to AArch64 target.
> The implementation is based on similar work targeted at PPC64LE.
> https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00550.html
>
> We are using the corresponding DejaGnu tests similar to Powerpc from
> gcc/testsuite/gcc.target/i386/ to gcc/testsuite/gcc.target/aarch64 as the
> source remains same. Only modifications are target related as appropriate.
Where intrinsics can be implemented in plain GNU C without
architecture-specific built-in functions being involved in the
implementation, it would seem to me to be a bad idea to duplicate the
implementation for more and more architectures.
Rather, it would seem better to refactor the powerpc implementation into a
part that's shared by all architectures (maybe even by x86 as well) and
possibly architecture-specific pieces (though if multiple architectures
have architecture-specific built-in functions for the same thing, an
architecture-independent built-in function might make sense). For "all
architectures" read "all little-endian architectures" for any intrinsics
whose definition is problematic for big endian. Likewise, tests should
then be shared.
(I realise that there may be issues with type sizes as well, making some
intrinsics problematic with e.g. 16-bit int. But implementations shared
for all architectures with 32-bit int and 64-bit long long, for example,
would still make sense.)
--
Joseph S. Myers
joseph@codesourcery.com