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: Steven Munroe <munroesj at linux dot vnet dot ibm dot com>
- Cc: "Hurugalawadi, Naveen" <Naveen dot Hurugalawadi at cavium dot com>, Joseph Myers <joseph at codesourcery 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 16:17:54 -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>
On Tue, Jun 20, 2017 at 01:51:24PM -0500, Steven Munroe wrote:
> I am not sure this works or is even a good idea.
>
> As an accident bmiintrin.h can be implemented as C code or common
> builtins. But bmi2intrin.h depends on __builtin_bpermd which to my
> knowledge is PowerISA only.
Right. And the plan is to only support 64-bit, LE, POWER8 and above
(I hope I got that right -- the point is, only systems with newish
features, not something generic even when considering rs6000 alone).
> As I work on mmx, sse, sse2, etc it gets more complicated. There are
> many X86 intrinsic instances that require altivec.h unique instrisics to
> implement efficiently for the power64le target and some inline __asm.
Yeah. And even then the expectation is not to get perfectly good
performance, only something good enough as a starting point for a
porting effort.
> Net the current sample size so far is to small to make a reasonable
> assessment.
Right! And we have only two implementations so far, as well.
> 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.
It's not like the "common" parts will see much (if any) maintenance,
anyway... The interface is already set in stone, that's the whole
point of this all.
Segher