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

[Chris Lattner <clattner at apple dot com>]

On Nov 21, 2008, at 11:51 PM, H.J. Lu wrote:

> On Fri, Nov 21, 2008 at 9:34 PM, Chris Lattner <clattner@apple.com>  
> wrote:
> > On Nov 21, 2008, at 5:54 PM, H.J. Lu wrote:
> > > > > Let me clarify a few things:
> > > > >
> > > > > 1. We didn't add a new file. We just renamed gmmintrin.h to
> > > > > immintrin.h.
> > > > > 2. Including <immintrin.h> itself doesn't enable any ISA  
> > > > > extensions.
> > > > > 3. You need to use -mXXX to get the XXX extension from
> > > > > <immintrin.h>. It applies to -mmmx, -msse, ... -mavx.
> > > >
> > > > Sounds good.
> > > >
> > > > > 4. We will add future new ISA intrinics to a new header file
> > > > > and include it from <immintrin.h>.
> > > >
> > > > Sounds bad.  Why not just add everything to mmxintrin.h?  How is  
> > > > this
> > > > morally different?
> > >
> > > Please follow
> > >
> > > http://gcc.gnu.org/ml/gcc/2008-11/msg00031.html
> >
> > Followed.  What is the point?  Can you please answer my question?   
> > Thank
> > you,
>
> There is no mmxintrin.h.

Sorry, I meant mmintrin.h.

> Did you mean "add everything to immintrin.h diirectly"?
> The consensus is put AVX intrinsics into a separate file and include  
> it in
> immintrin.h. The same applies to future extensions.

Either I am not being clear here, or you are intentionally avoiding  
the question.  I will rephrase, because the most likely possibility is  
that I'm not communicating well.

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.

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.

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?

-Chris