[LLVMdev] Multi-Instruction Patterns

David Greene greened at obbligato.org
Tue Sep 23 19:17:53 PDT 2008


Chris Lattner wrote:
> On Sep 23, 2008, at 11:26 AM, David Greene wrote:
> 
>> Are there any examples of using tablegen to generate multiple machine
>> instructions from a single pattern?  Or do these cases always have  
>> to be
>> manually expanded?
> 
> PPC has a bunch of examples, for example:
> 
> // Arbitrary immediate support.  Implement in terms of LIS/ORI.
> def : Pat<(i32 imm:$imm),
>            (ORI (LIS (HI16 imm:$imm)), (LO16 imm:$imm))>;

Yep, I actually found some x86 ones buried in the .td files.  :)

So now I have a couple of other questions.

I wrote a pattern that looks something like the above in form, but how
do I tell the selection DAG to prefer my pattern over another that
already exists.  I can't easily just disable that other pattern because
it generates Machine Instruction opcode enums that are assumed to be
available in other parts of the x86 codegen.

So given two patterns that match the same thing, what's the tiebreaker?
I thought it was order in the .td file but that doesn't appear to be the
case.  I put my pattern first and it isn't selected.  I change the other 
pattern slightly so it won't match anything and then my pattern gets
used (so I know my pattern is valid).

Also, I really wanted to express this pattern as transforming from one
DAG to another, not down to machine instructions.  I saw this in
x86InstSSE.td:

// FIXME: may not be able to eliminate this movss with coalescing the 
src and
// dest register classes are different. We really want to write this pattern
// like this:
// def : Pat<(f32 (vector_extract (v4f32 VR128:$src), (iPTR 0))),
//           (f32 FR32:$src)>;

(this is actually a very useful and important pattern, I wish it was
available!)

I had actually written my pattern in a similar style before I found
this.  When I tried to build, tblgen complained about the pattern being
of an unknown type (didn't match Instruction or SDNodeXForm).

I'm assuming there's some missing tblgen support here and that's why
this pattern is commented out.  Is that right?  Are there plans to add
tblgen support for these kinds of patterns?

                                 -Dave



More information about the llvm-dev mailing list