This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] A new meta intrinsic header file for current and future x86 instrinsics.
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: "Chris Lattner" <clattner at apple dot com>
- Cc: "rajagopal, dwarak" <dwarak dot rajagopal at amd dot com>, "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: Tue, 25 Nov 2008 21:34:44 -0800
- Subject: Re: [PATCH] A new meta intrinsic header file for current and future x86 instrinsics.
- References: <820531547ADB6847AF89CC220F6128F1737F@pdsmsx001.ccr.corp.intel.com> <CA9EADC1-DA94-4025-8CB3-796FF65FD0E5@apple.com> <email@example.com> <07F78718-6245-4951-8479-3AB811BBEC80@apple.com> <firstname.lastname@example.org> <CB19A7AB-D9F7-4CDE-ACA3-9DAE86CA2F28@apple.com> <email@example.com> <2A0B48A2-F0E5-4BAC-8D3B-6170F813EFE6@apple.com> <firstname.lastname@example.org> <E5B626AE-195A-4A46-8237-8838F06AFDC7@apple.com>
On Tue, Nov 25, 2008 at 9:08 PM, Chris Lattner <email@example.com> wrote:
> Previous practice has been to add new ISA features to a new header file.
> For example, when SSE1 was introduced, a new emmintrin.h file was added for
> the new ISA features it introduced. When SSE2 was introduced, a new
> xmmintrin.h file was introduced, etc.
> This provides significant value to people, because they can just include the
> header that they want, and have the ISA features they expect available to
> their program. If they accidentally use something that is not supported by
> the header, the compiler tells them through errors and warnings.
> My understanding is that you're proposing to break this long-standing
> tradition by adding new ISA features to an existing header over time. This
> will break this very valuable property of existing practice.
The content of <immintrin.h> is controlled by -mXXX. If you don't put
-mXXX at command line and use XXX features in your program, you will
get an error at compile/link time. If you don't want XXX, you have to use
-mno-XXX if XXX is enabled by default. In this case, even if you don't
include <immintrin.h>, gcc may still use XXX feature. So you don't lose
much with a single <immintrin.h>.
> On the other hand, independent of AVX, I agree that it is useful to have a
> "bring in all possible X86 ISA extensions" header. This header should bring
> in all extensions, independent of vendor, into the namespace of the
> #including file. It makes logical sense to me that this be named
> x86intrin.h, though there is very little logic among the existing file
Agreed. <x86intrin.h> can include <immintrin.h>.
> Does this description make sense? If so, why do you want to break existing
> practice here? If not, what can I do to make this any more clear?
<immtrin.h> is used by icc.