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: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Joseph Myers <joseph at codesourcery dot com>
- 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 17:16:04 -0500
- 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> <alpine.DEB.2.20.1706202130350.3448@digraph.polyomino.org.uk>
On Tue, Jun 20, 2017 at 09:34:25PM +0000, Joseph Myers wrote:
> 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 think there is much that will end up in the common header
eventually. If it was possible to describe most of this in plain C,
and in such a way that it would optimise well, there would not *be*
these intrinsics.
> 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).
Yeah, I think it should be possible to share the tests, perhaps with
some added dg things (so that we don't have to repeat the same things
over and over).
Segher