[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