llvm dev - May 2018 - [tablegen] anonymous def not fully instantiated

The following is an extraction from the Operand class hierarchy of Target.td. I
am trying to define a parameterized version of AsmOperandClass with a passed-in
bit size.

// from Target.td
class AsmOperandClass {
   string Name;
}

class Operand {
   AsmOperandClass ParserMatchClass;
}

// A parameterized AsmOperandClass
class myAsmOperandClass<int n> : AsmOperandClass {
  string Name = "Class" # n;
}

// A concrete instance
def myImm5Class: myAsmOperandClass<5>;

// Assign ParserMatchClass from the concrete instance: OK
def myImm5 : Operand {
  let ParserMatchClass = myImm5Class;
}

// Now try to abstract the above by parameterizing the size
class myImmClass<int n>: Operand {
  let ParserMatchClass = myAsmOperandClass<n>;
}

// Fails
def myImm6 : myImmClass<6>;

On the real .td file from which this was taken, tablegen complains that the Name
field of myImm6's ParserMatchClass is not a string. The reason is revealed
by looking at the raw output from tablegen:

------------- Defs -----------------
def myImm5Class {       // AsmOperandClass myAsmOperandClass
  string Name = "Class5";
}
def myImm5 {    // Operand
  AsmOperandClass ParserMatchClass = myImm5Class;
}
def anonymous_0 {       // AsmOperandClass myAsmOperandClass
  string Name = !strconcat("Class",
!cast<string>(myImmClass:n));
}
def myImm6 {    // Operand myImmClass
  AsmOperandClass ParserMatchClass = anonymous_0;
}

In the myImm5Class def used by myImm5, the !strconcat operation has been applied
to compute the Name as "Class5". But in the anonymous def used by
myImm6, the !strconcat operation has not been applied. Why not? How is the
anonymous definition any different than the explicit one?

Is this a known 'feature'/deficiency? Or am I the first to
'discover' it (seems unlikely).

-Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180515/bc91418b/attachment.html>

On 15.05.2018 21:01, Davis, Alan via llvm-dev wrote:
> The following is an extraction from the Operand class hierarchy of 
> Target.td. I am trying to define a parameterized version of 
> AsmOperandClass with a passed-in bit size.
> 
> // from Target.td
> 
> class AsmOperandClass {
> 
>     string Name;
> 
> }
> 
> class Operand {
> 
>     AsmOperandClass ParserMatchClass;
> 
> }
> 
> // A parameterized AsmOperandClass
> 
> class myAsmOperandClass<int n> : AsmOperandClass {
> 
>    string Name = "Class" # n;
> 
> }
> 
> // A concrete instance
> 
> def myImm5Class: myAsmOperandClass<5>;
> 
> // Assign ParserMatchClass from the concrete instance: OK
> 
> def myImm5 : Operand {
> 
>    let ParserMatchClass = myImm5Class;
> 
> }
> 
> // Now try to abstract the above by parameterizing the size
> 
> class myImmClass<int n>: Operand {
> 
>    let ParserMatchClass = myAsmOperandClass<n>;
> 
> }
> 
> // Fails
> 
> def myImm6 : myImmClass<6>;
> 
> On the real .td file from which this was taken, tablegen complains that 
> the Name field of myImm6’s ParserMatchClass is not a string. The reason 
> is revealed by looking at the raw output from tablegen:
> 
> ------------- Defs -----------------
> 
> def myImm5Class {       // AsmOperandClass myAsmOperandClass
> 
>    string Name = "Class5";
> 
> }
> 
> def myImm5 {    // Operand
> 
>    AsmOperandClass ParserMatchClass = myImm5Class;
> 
> }
> 
> def anonymous_0 {       // AsmOperandClass myAsmOperandClass
> 
>    string Name = !strconcat("Class",
!cast<string>(myImmClass:n));
> 
> }
> 
> def myImm6 {    // Operand myImmClass
> 
>    AsmOperandClass ParserMatchClass = anonymous_0;
> 
> }
> 
> In the myImm5Class def used by myImm5, the !strconcat operation has been 
> applied to compute the Name as “Class5”. But in the anonymous def used 
> by myImm6, the !strconcat operation has not been applied. Why not? How 
> is the anonymous definition any different than the explicit one?
> 
> Is this a known ‘feature’/deficiency? Or am I the first to ‘discover’ it 
> (seems unlikely).
You should update to the latest trunk. I've done a lot of cleanups and 
fixes in the TableGen frontend about two months ago, including a major 
rework of how anonymous instantiation works. The output for the example 
you showed above looks different (and correct) now.

Cheers,
Nicolai



> 
> -Alan
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 

-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.