On Tue, 9 Jan 2007, Evan Cheng wrote:>> - How does one deal with multiple instruction sequences in a pattern? >> To load a constant is a two instruction sequence, but both >> instructions only take two operands (assume that r3 is a 32-bit >> register): >> >> ilhu $3, 45 # r3 = (45 << 16) >> iohl $3, 5 # r3 |= 5 >> >> I tried: >> >> def : Pat<(i32 imm:$imm), >> (IOHL (ILHU (HI16 imm:$imm)), (LO16 imm:$imm))>; > > It is possible to write multi-instruction pattern, e.g. > X86InstrSSE.td line 1911. But how are you defining HI16 and LO16? > Sounds like you want to define them as SDNodeXform that returns upper > and lower 16 bits respectively. Take a look at PSxLDQ_imm in > X86InstrSSE.td as an example.Another good example is the PPC backend, which has the exact same issue for integer constants.>> - The return instruction for Cell SPU is "bi $lr". How do I jam that >> into the instruction info w/o tblgen bitching up a storm about the >> "$" or the extra "bi" operands? > > I am not sure. Does "bi \$lr" works? Or "bi $$lr"? Or even something > like > !strconcat("bi ", !strconcat("$", "lr")).Yep, $$ should work.>> - Immediates in a pattern: To move one register to another involves >> using the 3-operand OR instruction, but how do I encode an immediate >> w/o a type inference contradiction? >> >> def : Pat<(set R32C:$rDest, R32C:$rSrc), >> (ORIr32 R32C:$rSrc, 0)>;You current cannot specify move patterns in the .td file. You specify them with XXXRegisterInfo::copyRegToReg and XXXInstrInfo::isMoveInstr. See the PPC or Sparc backend for some simple examples. -Chris -- http://nondot.org/sabre/ http://llvm.org/
Chris Lattner wrote:>>It is possible to write multi-instruction pattern, e.g. >>X86InstrSSE.td line 1911. But how are you defining HI16 and LO16? >>Sounds like you want to define them as SDNodeXform that returns upper >>and lower 16 bits respectively. Take a look at PSxLDQ_imm in >>X86InstrSSE.td as an example. > > > Another good example is the PPC backend, which has the exact same issue > for integer constants.Actually, for SPU, not quite the same: def ILHU : RI16Form<0b010000010, (ops GPRC:$rT, u16imm:$val), "ilhu $rT, $val", LoadNOP, [(set GPRC:$rT, immZExt16:$val)]>; def IOHL : RI16Form<0b100000110, (ops GPRC:$rT, u16imm:$val), "iohl $rT, $val", LoadNOP, [(set GPRC:$rT, immZExt16:$val)]>; Thus, you can't really do as the PPC does, viz: (ORI (LIS (HI16 imm:$imm)), (LO16 imm:$imm)) vs. (IOHL (ILHU (HI16 imm:$imm)), (LO16 imm:$imm)) because there's only one operand to IOHL. PPC ORI is a two operand, one result instruction. (I'm sure I'm bashing the vernacular badly.) My question is how to link IOHL and ILHU together. Sequentially.>>>- The return instruction for Cell SPU is "bi $lr". How do I jam that >>> into the instruction info w/o tblgen bitching up a storm about the >>> "$" or the extra "bi" operands? >> >>I am not sure. Does "bi \$lr" works? Or "bi $$lr"? Or even something >>like >>!strconcat("bi ", !strconcat("$", "lr")). > > > Yep, $$ should work.It doesn't. Here's the pattern: let isTerminator = 1, isBarrier = 1, noResults = 1 in { let isReturn = 1 in { def RET: BRForm<0b00010101100, (ops), "bi $$lr", BranchResolv, [(retflag)]>; } } Output from make: llvm[0]: Building SPU.td code emitter with tblgen tblgen: /work/scottm/llvm/utils/TableGen/CodeGenInstruction.h:118: std::pair<unsigned int, unsigned int> llvm::CodeGenInstruction::getSubOperandNumber(unsigned int) const: Assertion `i < OperandList.size() && "Invalid flat operand #"' failed. make: *** [/work/scottm/llvm/obj/i686-unknown-linux-gnu/lib/Target/IBMCellSPU/Debug/SPUGenCodeEmitter.inc.tmp] Aborted Whiskey Tango... Foxtrot?
On Jan 9, 2007, at 5:23 PM, Scott Michel wrote:> Chris Lattner wrote: >>> It is possible to write multi-instruction pattern, e.g. >>> X86InstrSSE.td line 1911. But how are you defining HI16 and LO16? >>> Sounds like you want to define them as SDNodeXform that returns >>> upper >>> and lower 16 bits respectively. Take a look at PSxLDQ_imm in >>> X86InstrSSE.td as an example. >> >> >> Another good example is the PPC backend, which has the exact same >> issue >> for integer constants. > > Actually, for SPU, not quite the same: > > def ILHU : RI16Form<0b010000010, (ops GPRC:$rT, u16imm:$val), > "ilhu $rT, $val", LoadNOP, > [(set GPRC:$rT, immZExt16:$val)]>; > > def IOHL : RI16Form<0b100000110, (ops GPRC:$rT, u16imm:$val), > "iohl $rT, $val", LoadNOP, > [(set GPRC:$rT, immZExt16:$val)]>; > > Thus, you can't really do as the PPC does, viz: > > (ORI (LIS (HI16 imm:$imm)), (LO16 imm:$imm)) > > vs. > > (IOHL (ILHU (HI16 imm:$imm)), (LO16 imm:$imm)) > > because there's only one operand to IOHL. PPC ORI is a two operand, > one > result instruction. (I'm sure I'm bashing the vernacular badly.) My > question is how to link IOHL and ILHU together. Sequentially.I am guessing IOHL would modify the lower 16-bits of the register while preserving the upper 16-bit? If so, you want to make it into a two-address opcode using operand constraints. Something like def IOHL : RI16Form<0b100000110, (ops GPRC:$rT, GPRC:$rS, u16imm:$val), "iohl $rT, $val", "$rS = $rT" ... Then you can have the result of ILHU as a source operand as IOHL.> >>>> - The return instruction for Cell SPU is "bi $lr". How do I jam >>>> that >>>> into the instruction info w/o tblgen bitching up a storm about the >>>> "$" or the extra "bi" operands? >>> >>> I am not sure. Does "bi \$lr" works? Or "bi $$lr"? Or even something >>> like >>> !strconcat("bi ", !strconcat("$", "lr")). >> >> >> Yep, $$ should work. > > It doesn't. Here's the pattern: > > let isTerminator = 1, isBarrier = 1, noResults = 1 in { > let isReturn = 1 in { > def RET: BRForm<0b00010101100, (ops), > "bi $$lr", > BranchResolv, > [(retflag)]>; > } > } > > Output from make: > > llvm[0]: Building SPU.td code emitter with tblgen > tblgen: /work/scottm/llvm/utils/TableGen/CodeGenInstruction.h:118: > std::pair<unsigned int, unsigned int> > llvm::CodeGenInstruction::getSubOperandNumber(unsigned int) const: > Assertion `i < OperandList.size() && "Invalid flat operand #"' failed. > make: *** > [/work/scottm/llvm/obj/i686-unknown-linux-gnu/lib/Target/IBMCellSPU/ > Debug/SPUGenCodeEmitter.inc.tmp] > Aborted > > Whiskey Tango... Foxtrot?Please file a bug with a reduced test case for it. Evan> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev