[LLVMdev] RFC: More AVX Experience

[David Greene]

> plus the rest of the sse1 "xs rm" classes, the mr encodings, all the binary 
> operations, all the sse2 classes (which look like the sse1 classes except they 
> use "xd", all the vector classes, all the AVX classes, LRBni, etc.  We still 
> have a combinatorial explosion problem.
> 
> Of course, we only have to define the ones we actually use and that cuts
> down significantly on the numbers, but it's still large.
> 
> So I'm still looking for a complete solution.  Ideas welcome.

Ah, what early '30's jazz can do to spur the creative juices.

So I'm driving through south Minneapolis listening to some Fletcher
Henderson (try it sometime!) and it dawns on me that all we need to
handle customer patterns is some way to override the default behavior of
the "default" pattern.  I think we can do that with some of the new
operations I added.

I'm thinking we could have an optional final argument that contains a
list of key:value pairs that specify which defaults to override.  For
example:

def PATTERN : Key;

// Scalar
defm FsANDN : sse1_sse2_avx_binary_scalar_xs_xd_node_rm_rrm<
               0x55,
               "andn",
               nop,      // Or some dummy dag operator
   [[PATTERN [[(set DSTREGCLASS:$dst, 

      (INTTYPE (and (not (INTTYPE (bitconvert (TYPE SRCREGCLASS:$src1)))),
                    (INTTYPE (MEMOP ADDRCLASS:$src2)))))]]]]>;

Now we pass a list of one pair: [PATTERN <our-custom-pattern>].  This
assumes that lists can be heterogeneous.  I don't know if that's true
but I'll try it out.  Alternatively, we could define a new 'tuple' type
to handle this.  Actually, since we have to declare a list with only one
element type, I'm pretty sure we will have to do this, unless it's
possible to declare a list of typeless objects.  Which would be
preferable?

Hmm...as I go through this it seems that even with tuples, we can't get
a list of heterogeneous tuples so maybe we have to resort to multiple
extra arguments.  That would be too bad because if we wanted to override
one default we might have to specify the other defaults that come before
it.  Unless we do named parameters, which I don't want to worry about if
we don't have to (I was trying to address it with key:value pairs).

Down in the guts of the class hierarchy we'd have something like this:

class SomeBaseClass<Opcode opc, string asmop, SDNode dagoperator,
                     list<dag> CustomPattern = []> :
    Inst<opc, <some-asm-string>, !if(!null(CustomPattern),
                                     <default-pattern>, CustomPattern)>;

Hmm, I think that will even work.

Now there's an additional problem if we need different patterns for
various encodings (rr, rm, etc.).  I'm hoping we can write generic
enough patterns that we can avoid problems most of the time and for the
rest of the cases we may have to write special classes.

By getting rid of the default/custom pattern classes we'll reduce the
class space quite a bit.  Maybe even to something tractable.  I'll
play around with this idea and see where it goes.

Does anything look really wrong with this approach?

                                  -Dave