This is the mail archive of the
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: Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: Steven Munroe <munroesj at linux dot vnet dot ibm dot com>, "Hurugalawadi, Naveen" <Naveen dot Hurugalawadi at cavium dot com>, "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>, "dje dot gcc at gmail dot com" <dje dot gcc at gmail dot com>
- Date: Tue, 20 Jun 2017 21:34:25 +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> <CO2PR07MB2693494535305C1AF011A15983C50@CO2PR07MB2693.namprd07.prod.outlook.com> <1497984684.25802.13.camel@oc7878010663> <20170620211753.GT16550@gate.crashing.org>
On Tue, 20 Jun 2017, Segher Boessenkool wrote:
> > And as you see see below the gcc.target tests have to be duplicated
> > anyway. Even if the C code is common there will many differences in
> > dg-options and dg-require-effective-target. Trying to common these
> > implementations only creates more small files to manage.
> So somewhere in the near future we'll have to pull things apart again,
> if we go with merging things now.
The common part in the intrinsics implementation should be exactly the
parts that can be implemented in GNU C without target-specific intrinsics
being needed. There should be nothing to pull apart if you start with the
right things in the common header. If a particular header has some
functions that can be implemented in GNU C and some that need
target-specific code, the generic GNU C functions should be in a common
header, #included by the target-specific header. The common header should
have no conditionals on target architectures whatever (it might have
conditionals on things like endianness).
I don't expect many different effective-target / dg-add-options keywords
to be needed for common tests (obviously, duplicating tests for each
architecture wanting these intrinsics is generally a bad idea).
Joseph S. Myers