This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [PATCH] A new meta intrinsic header file for current and future x86 instrinsics.
- From: "rajagopal, dwarak" <dwarak dot rajagopal at amd dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: "Uros Bizjak" <ubizjak at gmail dot com>, "Richard Guenther" <richard dot guenther at gmail dot com>, "Guo, Xuepeng" <xuepeng dot guo at intel dot com>, <gcc-patches at gcc dot gnu dot org>, <jakub at redhat dot com>, "Ye, Joey" <joey dot ye at intel dot com>, "Lin, Weiliang" <weiliang dot lin at intel dot com>, "Harle, Christophe" <christophe dot harle at amd dot com>, "Sebastian Pop" <sebpop at gmail dot com>
- Date: Fri, 21 Nov 2008 12:01:26 -0600
- Subject: RE: [PATCH] A new meta intrinsic header file for current and future x86 instrinsics.
- References: <820531547ADB6847AF89CC220F6128F1737F@pdsmsx001.ccr.corp.intel.com> <4923023C.3090106@gmail.com> <9E1304B144EBEB4C97F4162BFAC4788602D3A6CD@SAUSEXMB2.amd.com> <5787cf470811192337q7ee8ae1eid0e296650f1d9fdb@mail.gmail.com> <84fc9c000811200213w13f1774cif607d50cfad5741d@mail.gmail.com> <5787cf470811200230n61a73f4dn43ba4c1cfbb5520c@mail.gmail.com> <9E1304B144EBEB4C97F4162BFAC4788602D3AAB5@SAUSEXMB2.amd.com> <6dc9ffc80811210941h35b40f8hfb4e60aa96b80426@mail.gmail.com>
> On Fri, Nov 21, 2008 at 9:31 AM, rajagopal, dwarak
> <dwarak.rajagopal@amd.com> wrote:
> >>
> >> On Thu, Nov 20, 2008 at 11:13 AM, Richard Guenther
> >> <richard.guenther@gmail.com> wrote:
> >>
> >> >> So I propose that AMD introduces its own intrinsic file,
following
> >> >> immintrin.h example. There *will be* a vendor neutral
x86intrin.h
> > (or
> >> >> whatever the name will be agreed to), and AMDs file will be
> > included
> >> >> through this vendor neutral header just in the same way as
Intels
> >> >> file.
> >> >
> >> > I fail to see a compelling reason to have vendor specific headers
at
> >> all.
> >>
> >> Me too, but this is the situation we live in (bmmintrin.h vs.
> >> gmmintin.h) and will always live in. Everybody wants its own
sandbox
> >> to play in.
> >>
> >> Uros.
> >
> > Yes. We are beginning to realize this as well.
> > I'm planning to create an <x86intrin.h>, which will do the
following:
> >
> > #ifndef _x86INTRIN_H_INCLUDED
> > #define _x86INTRIN_H_INCLUDED
> >
> > #ifdef __MMX__
> > #include <mmintrin.h>
> > #endif
> >
> > #ifdef __SSE__
> > #include <xmmintrin.h>
> > #endif
> >
> > #ifdef __SSE2__
> > #include <emmintrin.h>
> > #endif
> >
> > #ifdef __SSE3__
> > #include <pmmintrin.h>
> > #endif
> >
> > #ifdef __SSSE3__
> > #include <tmmintrin.h>
> > #endif
> >
> > #ifdef __SSE4a__
> > #include <ammintrin.h>
> > #endif
> >
> > #if defined (__SSE4_2__) || defined (__SSE4_1__)
> > #include <smmintrin.h>
> > #endif
> >
> > #ifdef __SSE5__
> > #include <bmmintrin.h>
> > #endif
> >
> > #if defined (__AES__) || defined (__PCLMUL__)
> > #include <wmmintrin.h>
> > #endif
> >
> > #ifdef __AVX__
> > #include <avxintrin.h>
> > #endif
> >
> > #ifdef __3dNOW__
> > #include <mm3dnow.h>
> > #endif
> >
> > #endif /* _x86MMINTRIN_H_INCLUDED */
> >
> > Is this approach ok?
>
> There is no need to include SSE to AVX header files separately.
>
> #include <immintrin.h>
>
> will just work. I would suggest you include all AMD intrinsic files
from
> one file, saying <AMDintrin.h>. Then x86intrin.h becomes
>
> #include <immintrin.h>
> #include <AMDintrin.h>
>
Hi H.J,
We have already responded that vendor specific header files are not a
proposal that is acceptable to AMD.
We agree with Uros and Richi's views that we should not have vendor
specific header files. We should instead have architecture extension
specific header files.
Thanks,
Dwarak