This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: Enable Intel AES/CLMUL
On Fri, Apr 04, 2008 at 03:16:06PM +0200, Uros Bizjak wrote:
> On Fri, Apr 4, 2008 at 2:48 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> > On Fri, Apr 04, 2008 at 08:30:40AM +0200, Uros Bizjak wrote:
> > > On Thu, Apr 3, 2008 at 11:51 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> > >
> > > > + /* Enable SSE 4.2 if AES or CLMUL is enabled. */
> > > > + if ((x86_aes || x86_clmul)
> > > > + && !(ix86_isa_flags_explicit & OPTION_MASK_ISA_SSE4_2))
> > > > + {
> > > > + ix86_isa_flags |= OPTION_MASK_ISA_SSE4_2_SET;
> > > > + ix86_isa_flags_explicit |= OPTION_MASK_ISA_SSE4_2_SET;
> > > > + }
> > > > +
> > >
> > > Do we really want to enable all SSE builtins if only AES functionality
> > > is required? I think that -msse -maes is more appropriate, since -msse
> > > instructs the compiler to enable support for SSE registers and -maes
> > > enables special AES instructions that depend on SSE registers.
> > > Unfortunately, we don't have separate option to enable only SSE
> > > registers without SSE builtins, but IMO we can live with that. Similar
> > > situation is with -mclmul. At minimum, -msse -mclmul should be
> > > required, I see no reason to enable everything up to sse4_2 for this
> > > insn.
> >
> > SSE doesn't support V2DI. You need at least SSE2.
> >
>
> OK.
>
> >
> > >
> > > > +/* We need definitions from the SSE4, SSSE3, SSE3, SSE2 and SSE header
> > > > + files. */
> > > > +#include <smmintrin.h>
> > > > +
> > >
> > > Actually we only need __v2di and __m128i typedefs here. Perhaps we can
> > > copy these two definitions here, or we can define
> > >
> > > typedef long long __m128a __attribute__ ((vector_size (16), __may_alias));
> > >
> > > and rewrite these new intrinsics to use this type?
> >
> > <wmmintrin.h> from icc 10.1 includes SSE4 intrinsic header file. If
> > <wmmintrin.h> from gcc doesn't support SSE4 intrinsics, it will be
> > incompatible with icc. I can image other companies may implement
> > AES/CLMUL. I think it should be handled similar to SSE4 intrinsics.
> > That is we put AES/CLMUL intrinsics in a common intrinsic header file
> > and 2 different options, one of them is -maes/-mclmul, will enale
> > them. -maes/-mclmul will still imply SSE4.
>
> This practically forces usage of -msse4.1 for -maes/-mclmul, since
> these instructions are used only through intrinsics, defined in their
> corresponding header file. wmmintrin.h includes smmintrin.h that will
> error out by #ifndef __SSE4_1__.
>
> I think that user should explicitly enable sse4.1 manually in the
> command line together with -maes/-mclmul to access these new
> instructions. Including wmmintrin.h will error out when neither
> -maes/-mclmul is enabled, and smmintrin.h will error out with a
> message that SSE4.1 instruction set is not enabled.
There is a proposal to get rid of all *mmintrin.h. Users should
include one header file, something like <ia32intrin.h> ,for all
current and future intrinsics. The name of the meta intrinsic
heade file hasn't be decided. Do we have any preferences/suggestions?
With that in mind, I will change it to include emmintrin.h.
>
> Does icc automatically enable all SSE intrinsics for -maes/-mclmul?
Icc has a different switch to enable SSE 4 and AES. -maes/-mclmul
is for gcc emulation.
>
> > I can change
> >
> >
> > { OPTION_MASK_ISA_SSE4_2, CODE_FOR_aesimc, 0, IX86_BUILTIN_AESIMC128, UNKNOWN , 0 },
> >
> > to
> >
> > { OPTION_MASK_ISA_SSE2, CODE_FOR_aesimc, 0, IX86_BUILTIN_AESIMC128, UNKNOWN , 0 },
> >
>
> Since there is no other way to generate these insns than through
> intrinsics (__builtin_X should not be used by user as this is not
> considered stable interface), we can put OPTION_MASK_ISA_SSE4_1 here.
> At least SSE4_1 should be active due to constraint forced by
> wmmintrin.h/smmintrin.h
>
> > +#if !defined (__AES__) && !defined (__CLMUL__)
> > +# error "AES/CLMUL instruction set not enabled"
> > +#else
>
> "instruction set" or "instructions" in the error message?
I can use instructions.
H.J.