[LLVMdev] RFC: AVX Pattern Specification [LONG]

[David Greene]

On Friday 01 May 2009 13:46, Chris Lattner wrote:

> Right, a lot of these problems can be solved by some nice refactoring
> stuff.  I'm also hoping that some of the complexity in defining
> shuffle matching code can be helped by making the definition of the
> shuffle patterns more declarative within the td file.  It would be
> really nice to say that "this shuffle does a  "1,0,3,2 shuffle and has
> cost 42" and have tblgen generate all the required matching code.

That would be nice.  Any ideas how this would work?


> I agree, I think it is unfortunate that AVX decided to do this at an
> architectural level :).

I'm not sure what else would be done.

> > So what I've done is a little experiment to see if I can unify all
> > SSE and AVX
> > SIMD instructions under one framework.  I'll leave MMX and 3dNow
> > alone since
> > they're oddballs and hardly anyone uses them.
>
> Ok.  I agree that the similarity being factored here is across SSE1/2/
> AVX.

And SSE3/4.


> > I have a Perl script that auto-generates the necessary mutliclass
> > combinations
> > as well as the needed base classes depending on what's in the top-
> > level .td
> > file.  For now, I've named that top-level file X86InstrSIMD.td.
> >
> > The Perl script would only be need to run as X86InstrSIMD.td
> > changes.  Thus
> > its use would be similar to how we use autoconf today.  We only run
> > autoconf /
> > automake when we update the .ac files, not as part of the build
> > process.
>
> While I agree that we want to refactor this, I really don't think that
> we should autogenerate .td files from perl.  This has a number of
> significant logistical problems.  What is it that perl gives you that
> we can't enhance tblgen to do directly?

Well, mainly it's because we don't have whatever tblgen enhancements we need.
I'll have to think on this some and see if I can come up with some tblgen
features that could help.

I was writing a lot of these base classes by hand at first, but there are a 
lot of them (they tend to be very small) and writing them is very mechanical.  
So we probably can enhance tblgen somehow.  I'm just not sure what that looks
like right now.

> > Initially, X86InstrSIMD.td would define only AVX instructions so it
> > would not
> > impact existing SSE clients.  My intent is that X86InstrSIMD.td
> > essentially
> > become the canonical description of all SSE and AVX instructions and
> > X86InstrSSE.td would go away completely.
>
> Instead of slowly building it up and then cutting over, I'd prefer to
> incrementally move patterns into it, removing them from the other .td
> files at the same time.  This should be a nice clean and continuous
> refactoring that makes the code monotonically better (smaller).

Ok, that sounds like a pretty good idea.

> > The cons:
> > * Transition from X86InstrSSE.td
> > * A more complex class hierarchy
>
> I'm not worried about these.

Ok.

> > * A class-generating tool / indirection
>
> I really don't like this :).  If there is something higher level that
> you need, I think it would be very interesting to carefully consider
> what the root problem is and whether there is a good solution that we
> can directly implement in tblgen.  It is pretty clear that we can
> *improve* the current situation with no tblgen enhancements, but I
> agree that AVX is a nice forcing function that will greatly benefit
> from a *much improved* target description.

Your point is well taken.  Let me think on this a bit.

                             -Dave