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?
-Dave
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))>; // ADD an arbitrary immediate. def : Pat<(add GPRC:$in, imm:$imm), (ADDIS (ADDI GPRC:$in, (LO16 imm:$imm)), (HA16 imm:$imm))>; // OR an arbitrary immediate. def : Pat<(or GPRC:$in, imm:$imm), (ORIS (ORI GPRC:$in, (LO16 imm:$imm)), (HI16 imm:$imm))>; // XOR an arbitrary immediate. def : Pat<(xor GPRC:$in, imm:$imm), (XORIS (XORI GPRC:$in, (LO16 imm:$imm)), (HI16 imm:$imm))>; -Chris
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