[LLVMdev] Instruction Encodings in TableGen

Justin Holewinski justin.holewinski at gmail.com
Wed Jul 25 04:51:28 PDT 2012


On Tue, Jul 24, 2012 at 8:46 PM, Jim Grosbach <grosbach at apple.com> wrote:

>
> On Jul 24, 2012, at 3:52 PM, Justin Holewinski <
> justin.holewinski at gmail.com> wrote:
>
> On Tue, Jul 24, 2012 at 3:59 PM, Tom Stellard <thomas.stellard at amd.com>wrote:
>
>> On Tue, Jul 24, 2012 at 03:25:14PM -0400, Justin Holewinski wrote:
>> > I'm starting to look into binary instruction encodings in TableGen, and
>> I'm
>> > a bit confused on how the instruction fields are populated.  Perhaps I'm
>> > just being dense, but I cannot see how SDAG operands are translated into
>> > the encoding fields.  Can someone please explain the following snippet
>> from
>> > the PPC back-end.
>> >
>> > The AND instruction in PPC is defined as:
>> >
>> > 1011 def AND  : XForm_6<31,  28, (outs GPRC:$rA), (ins GPRC:$rS,
>> GPRC:$rB),
>> > 1012                    "and $rA, $rS, $rB", IntSimple,
>> > 1013                    [(set GPRC:$rA, (and GPRC:$rS, GPRC:$rB))]>;
>> >
>> > Okay, so rA, rS, and rB are register operands.
>> >
>> > The TableGen classes are defined as:
>> >
>> > 315 class XForm_base_r3xo_swapped
>> > 316         <bits<6> opcode, bits<10> xo, dag OOL, dag IOL, string
>> asmstr,
>> > 317         InstrItinClass itin>
>> > 318   : I<opcode, OOL, IOL, asmstr, itin> {
>> > 319   bits<5> A;
>> > 320   bits<5> RST;
>> > 321   bits<5> B;
>> > 322
>> > 323   bit RC = 0;    // set by isDOT
>> >
>> > 324
>> > 325   let Inst{6-10}  = RST;
>> > 326   let Inst{11-15} = A;
>> > 327   let Inst{16-20} = B;
>> > 328   let Inst{21-30} = xo;
>> > 329   let Inst{31}    = RC;
>> > 330 }
>> >
>> > 337 class XForm_6<bits<6> opcode, bits<10> xo, dag OOL, dag IOL, string
>> > asmstr,
>> > 338               InstrItinClass itin, list<dag> pattern>
>> > 339   : XForm_base_r3xo_swapped<opcode, xo, OOL, IOL, asmstr, itin> {
>> > 340   let Pattern = pattern;
>> > 341 }
>> >
>> > Okay, so A, RST, and B are the operand fields in the instruction
>> encoding
>> > (I assume).  But where are A, RST, and B given values?  When the
>> > instruction is encoded (and the physical registers are known), where do
>> > these values come from?  A grep for RST doesn't come up with anything
>> > useful.  Is there C++ code somewhere that scans the operands of all
>> > instructions and performs the actual encoding?
>> >
>>
>> The getMachineOpValue() function does the encoding for the non-MC code
>> emitter.  The MC code emitter might be different though.
>>
>
> Yeah, I see the calls to getMachineOpValue() in the generated code, but it
> seems like it just processes the fields of the TableGen class in the order
> that they appear, e.g. A, RST, B in the PPC example, which seems very
> fragile.  This makes me believe I'm missing something here.
>
>
>
> If the bitfields are named the same as the operands in the (ins) and
> (outs) lists, TableGen will match them that way rather than positionally.
> ARM makes extensive use of that, for example.
>

Awesome!  I was hoping for something like that.  Thanks!


>
> -Jim
>
>
>
>> -Tom
>>
>> > --
>> >
>> > Thanks,
>> >
>> > Justin Holewinski
>>
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>>
>
>
> --
>
> Thanks,
>
> Justin Holewinski
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>


-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120725/7e829b88/attachment.html>


More information about the llvm-dev mailing list