Re: PATCH: x86/x86-64: Support Intel MNI intrinsics

[Ian Lance Taylor <iant at google dot com>]

"H. J. Lu" <hjl@lucon.org> writes:

> On Wed, Jul 05, 2006 at 11:30:55AM -0700, H. J. Lu wrote:
> > On Mon, Jul 03, 2006 at 09:09:34PM -0700, Ian Lance Taylor wrote:
> > > 
> > > This patch looks generally OK to me, although I haven't read anything
> > > about how the instructions work..  However, I am concerned about the
> > > name Merom and the acronym MNI.  I'd rather get this right from the
> > > start.  I did a few searches on the Intel web site.  I found this:
> > >     http://www.intel.com/cd/ids/developer/asmo-na/eng/newsletter/286721.htm
> > > which says "Get the much-awaited support for Intel Coreâ2 Duo
> > > (formerly code named Merom) new instructions in processors with
> > > Eclipse for Itanium 2 processor support and Cluster OpenMP*."  So
> > > Merom is a code name, and we know that Intel doesn't keep those code
> > > names going forward.  Do we really want to look in this option name?
> > > 
> > > Searching around in general, I see that some people are calling these
> > > instructions SSE4.  E.g.,
> > >     http://en.wikipedia.org/wiki/SSE4
> > > 
> > > Would it be possible to pin down the option name now so that we don't
> > > have to change it in the future, and so that we don't have a backward
> > > compatibilty problem?
> > 
> > I haven't seen the offficial name for MNI. We can add it when it comes
> > out.

In general this patch looks pretty much OK (one comment below).  But
I'm still uncomfortable with the "MNI" which appears all over the
patch, including the option name, the preprocessor macro, and the
documentation.  If we have to change the name MNI later--which to me
seems very likely--we are going to give ourselves a backward
compatibility problem.

So, frankly, my inclination is to postpone the patch until we know the
right name, to reduce end user confusion.  But I understand that
others may disagree, and prefer to see this support in gcc 4.2.0 even
if the names must change later.  (I don't know when the hardware will
be available--for all I know it is available now.)

I've CC'ed Mark to see if he has any comments as release manager.


> > > Also, why are _mm_alignr_epi8 and _mm_alignr_pi8 implemented as macros
> > > rather than inline functions?
> > 
> > The 3rd arg has to be constant. Inline functions won't work with
> > -O0.

This is gcc specific code and is permitted to use gcc extensions.  So,
what if you use __attribute__ ((always_inline))?

Ian