This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [patch][x86] GFNI enabling [2/4]
- From: "Koval, Julia" <julia dot koval at intel dot com>
- To: 'Jakub Jelinek' <jakub at redhat dot com>
- Cc: 'Kirill Yukhin' <kirill dot yukhin at gmail dot com>, 'GCC Patches' <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 3 Nov 2017 08:27:24 +0000
- Subject: RE: [patch][x86] GFNI enabling [2/4]
- Authentication-results: sourceware.org; auth=none
- Dlp-product: dlpe-windows
- Dlp-reaction: no-action
- Dlp-version: 11.0.0.116
- References: <4E89A029A0F8D443B436A5167BA3C53F42AC2A4B@IRSMSX101.ger.corp.intel.com> <20171030102631.GP16502@titus> <4E89A029A0F8D443B436A5167BA3C53F42AC6A0A@IRSMSX101.ger.corp.intel.com> <20171031192748.GY14653@tucnak> <4E89A029A0F8D443B436A5167BA3C53F42AC83A0@IRSMSX101.ger.corp.intel.com>
> But what do you think about adding AVX/SSE flags to this special set instead?
Ok, was wrong, it is impossible to add SSE, because it is used in normal "or" way. Then I'll add GFNI/VAES instead.
There is also another problem there: GFNI belongs to isa_flags2, while AVX512VL/AVX/SSE belong to isa_flags, so we can't keep them in the same field. There are candidates, which can be moved from isa_flags to isa_flags2 instead of GFNI, because there are no dependencies on other flags, but it is only a short term solution.
> -----Original Message-----
> From: Koval, Julia
> Sent: Thursday, November 02, 2017 12:57 PM
> To: Jakub Jelinek <jakub@redhat.com>
> Cc: Kirill Yukhin <kirill.yukhin@gmail.com>; GCC Patches <gcc-
> patches@gcc.gnu.org>
> Subject: RE: [patch][x86] GFNI enabling [2/4]
>
> The documentation is right, I was wrong not adding SSE/AVX flags in these
> builtin declaratuin.
>
> > The exceptions are
> > MMX, AVX512VL and 64BIT is also special.
> > So, shall GFNI be added to that set?
> Turns out only GFNI and VAES(haven't sent those yet, they are from the same
> Icelake pdf) are like this, others rely on AVX512VL/BW. But what do you think
> about adding AVX/SSE flags to this special set instead? Looks like they more
> probably will be used as a flags, on which new instructions may depend in the
> future, than GFNI/VAES flags.
>
> -Julia
>
> > -----Original Message-----
> > From: gcc-patches-owner@gcc.gnu.org [mailto:gcc-patches-
> > owner@gcc.gnu.org] On Behalf Of Jakub Jelinek
> > Sent: Tuesday, October 31, 2017 8:28 PM
> > To: Koval, Julia <julia.koval@intel.com>
> > Cc: Kirill Yukhin <kirill.yukhin@gmail.com>; GCC Patches <gcc-
> > patches@gcc.gnu.org>
> > Subject: Re: [patch][x86] GFNI enabling [2/4]
> >
> > On Mon, Oct 30, 2017 at 07:02:23PM +0000, Koval, Julia wrote:
> > > gcc/testsuite/
> > > * gcc.target/i386/avx-1.c: Handle new intrinsics.
> > > * gcc.target/i386/avx512-check.h: Check GFNI bit.
> > > * gcc.target/i386/avx512f-gf2p8affineinvqb-2.c: Runtime test.
> > > * gcc.target/i386/avx512vl-gf2p8affineinvqb-2.c: Runtime test.
> > > * gcc.target/i386/gfni-1.c: New.
> > > * gcc.target/i386/gfni-2.c: New.
> > > * gcc.target/i386/gfni-3.c: New.
> > > * gcc.target/i386/gfni-4.c: New.
> >
> > The gfni-4.c testcase ICEs on i686-linux (e.g. try
> > make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32/-msse,-m32/-
> > mno-sse,-m64\} i386.exp=gfni*'
> > to see it).
> >
> > I must say I'm confused by the CPUIDs, the
> > https://software.intel.com/sites/default/files/managed/c5/15/architecture-
> > instruction-set-extensions-programming-reference.pdf
> > lists GFNI; 2x AVX+GFNI; 2x AVX512VL+GFNI; AVX512F+GFNI CPUIDs for the
> > instructions, but i386-builtins.def has:
> > BDESC (OPTION_MASK_ISA_GFNI, CODE_FOR_vgf2p8affineinvqb_v64qi,
> > "__builtin_ia32_vgf2p8affineinvqb_v64qi",
> > IX86_BUILTIN_VGF2P8AFFINEINVQB512, UNKNOWN
> > BDESC (OPTION_MASK_ISA_GFNI | OPTION_MASK_ISA_AVX512BW,
> > CODE_FOR_vgf2p8affineinvqb_v64qi_mask,
> > "__builtin_ia32_vgf2p8affineinvqb_v64qi_mask", IX86_
> > BDESC (OPTION_MASK_ISA_GFNI, CODE_FOR_vgf2p8affineinvqb_v32qi,
> > "__builtin_ia32_vgf2p8affineinvqb_v32qi",
> > IX86_BUILTIN_VGF2P8AFFINEINVQB256, UNKNOWN
> > BDESC (OPTION_MASK_ISA_GFNI | OPTION_MASK_ISA_AVX512BW,
> > CODE_FOR_vgf2p8affineinvqb_v32qi_mask,
> > "__builtin_ia32_vgf2p8affineinvqb_v32qi_mask", IX86_
> > BDESC (OPTION_MASK_ISA_GFNI, CODE_FOR_vgf2p8affineinvqb_v16qi,
> > "__builtin_ia32_vgf2p8affineinvqb_v16qi",
> > IX86_BUILTIN_VGF2P8AFFINEINVQB128, UNKNOWN
> > BDESC (OPTION_MASK_ISA_GFNI | OPTION_MASK_ISA_AVX512BW,
> > CODE_FOR_vgf2p8affineinvqb_v16qi_mask,
> > "__builtin_ia32_vgf2p8affineinvqb_v16qi_mask", IX86_
> > and the gfniintrin.h requires just gfni for the first insn,
> > and then some combinations of gfni,avx, or gfni,avx512vl, or
> > gfni,avx512vl,avx512bw, or gfni,avx512f,avx512bw.
> >
> > So, what is right, the paper, i386-builtins.def or gfniintrin.h?
> >
> > Obviously even if the GF2P8AFFINEINVQB instruction doesn't list SSE as
> > required CPUID, we can't really emit it without at least SSE because
> > then the operands can't be emitted. So, at least in GCC we should
> > require both GFNI and SSE for the first instruction.
> >
> > Which leads to another issue, as ix86_expand_builtin documents,
> > we treat the BDESC ISAs OPTION_MASK_ISA_ISA1 | OPTION_MASK_ISA_ISA2
> > as either ISA1 or ISA2, not ISA1 and ISA2. The exceptions are
> > MMX, AVX512VL and 64BIT is also special.
> > So, shall GFNI be added to that set? Do we have other ISAs that
> > should be handled the same? I guess maybe OPTION_MASK_ISA_AES, but
> > that is handled weirdly.
> >
> > Jakub