[LLVMdev] TableGen question

[Mohamed Shafi]

Tom,

Comment in CodeEmitterGen.cpp suggests what you have mentioned:

  // If the operand matches by name, reference according to that
  // operand number. Non-matching operands are assumed to be in
  // order.
  unsigned OpIdx;
  if (CGI.Operands.hasOperandNamed(VarName, OpIdx)) {

But in 3.5 version (for me anyway) the behavior is like what McKay mentioned:

it is based on the order of the declarations of the
variables in the class, and the order they are listed in the TableGen file.

I say this because for a class that i have mentioned in my first mail
if i match two definition like the following:

def ins_a -> (ins bb:$BD, GPR:$BIBO, GPR:$CR)

def ins_b -> (ins bb:$CR, GPR:$BD, GPR:$BIBO)

i get completely wrong encoding for 'ins_b' (if it is the one defined
after 'ins_a' in td file).
So i had to either write a subclass to override the instruction fields
with the appropriate operand or had to write a new class to match
instruction 'ins_b'

Is this expected?

Regards,
Shafi

On 25 June 2015 at 23:51, Tom Stellard <tom at stellard.net> wrote:
> On Thu, Jun 25, 2015 at 10:13:21PM +1200, Dylan McKay wrote:
>> As you suggested, it is based on the order of the declarations of the
>> variables in the class, and the order they are listed in the TableGen file.
>>
>> See Writing an LLVM Backend/Instruction operand mapping
>> <http://llvm.org/docs/WritingAnLLVMBackend.html#instruction-operand-mapping>
>> .
>>
>> Operands are assigned to unbound fields in the instruction in the order
>> they are defined. Fields are bound when they are assigned a value.
>>
>
> Tablegen will try to match operand names with field names first, before
> it falls back to matching on the oreder of the fields.  So in the
> example if the instruction is defined like this:
>
> (ins bb:$BD, GPR:$BIBO, GPR:$CR)
>
> The PPCGenMCCodeEmitter.inc will look something similar to this:
>
>
>        // op: BIBO
>        op = getMachineOpValue(MI, MI.getOperand(1), Fixups, STI);
>        // op: CR
>        op = getMachineOpValue(MI, MI.getOperand(2), Fixups, STI);
>        // op: BD
>        op = getCondBrEncoding(MI, 0, Fixups, STI);
>
> -Tom
>
>>
>>
>> On Thu, Jun 25, 2015 at 5:28 PM, Mohamed Shafi <shafitvm at gmail.com> wrote:
>>
>> > Hi,
>> >
>> > In tablegen file inside class we have variables declared inside a
>> > class. Say in PPC there is this
>> >
>> > class BForm<bits<6> opcode, bit aa, bit lk, dag OOL, dag IOL, string
>> > asmstr>
>> >   : I<opcode, OOL, IOL, asmstr, IIC_BrB> {
>> >   bits<7> BIBO;  // 2 bits of BI and 5 bits of BO.
>> >   bits<3>  CR;
>> >   bits<14> BD;
>> >
>> >
>> > How does the generator match each variable against an operand?
>> >
>> > For the corresponding PPCGenMCCodeEmitter.inc for this the entry is
>> >
>> >       // op: BIBO
>> >       op = getMachineOpValue(MI, MI.getOperand(0), Fixups, STI);
>> >       // op: CR
>> >       op = getMachineOpValue(MI, MI.getOperand(1), Fixups, STI);
>> >       // op: BD
>> >       op = getCondBrEncoding(MI, 2, Fixups, STI);
>> >
>> >
>> > How does the generator know that BIBO is op0 and CR is op1 and so on?
>> > Is it based on the order of the declarations of the variables in the class?
>> >
>> > Regards,
>> > Shafi
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> >
>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>