Re: [PATCH] A new meta intrinsic header file for current and future x86 instrinsics.

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Tue, Nov 25, 2008 at 9:08 PM, Chris Lattner <clattner@apple.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
> names.

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.

-- 
H.J.