[LLVMdev] Pattern matching questions

[Evan Cheng]

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