llvm-6502/test/TableGen/ClassInstanceValue.td

20 lines
324 B
TableGen
Raw Permalink Normal View History

[TableGen] Fully resolve class-instance values before defs in multiclasses By class-instance values I mean 'Class<Arg>' in 'Class<Arg>.Field' or in 'Other<Class<Arg>>' (syntactically s SimpleValue). This is to differentiate from unnamed/anonymous record definitions (syntactically an ObjectBody) which are not affected by this change. Consider the testcase: class Struct<int i> { int I = !shl(i, 1); int J = !shl(I, 1); } class Class<Struct s> { int Class_J = s.J; } multiclass MultiClass<int i> { def Def : Class<Struct<i>>; } defm Defm : MultiClass<2>; Before this fix, DefmDef.Class_J yields !shl(I, 1) instead of 8. This is the sequence of events. We start with this: multiclass MultiClass<int i> { def Def : Class<Struct<i>>; } During ParseDef the anonymous object for the class-instance value is created: multiclass Multiclass<int i> { def anonymous_0 : Struct<i>; def Def : Class<NAME#anonymous_0>; } Then class Struct<i> is added to anonymous_0. Also Class<NAME#anonymous_0> is added to Def: multiclass Multiclass<int i> { def anonymous_0 { int I = !shl(i, 1); int J = !shl(I, 1); } def Def { int Class_J = NAME#anonymous_0.J; } } So far so good but then we move on to instantiating this in the defm by substituting the template arg 'i'. This is how the anonymous prototype looks after fully instantiating. defm Defm = { def Defmanonymous_0 { int I = 4; int J = !shl(I, 1); } Note that we only resolved the reference to the template arg. The non-template-arg reference in 'J' has not been resolved yet. Then we go on to instantiating the Def prototype: def DefmDef { int Class_J = NAME#anonymous_0.J; } Which is resolved to Defmanonymous_0.J and then to !shl(I, 1). When we fully resolve each record in a defm, Defmanonymous_0.J does get set to 8 but that's too late for its use. The patch adds a new attribute to the Record class that indicates that this def is actually a class-instance value that may be *used* by other defs in a multiclass. (This is unlike regular defs which don't reference each other and thus can be resolved indepedently.) They are then fully resolved before the other defs while the multiclass is instantiated. I added vg_leak to the new test. I am not sure if this is necessary but I don't think I have a way to test it. I can also check in without the XFAIL and let the bots test this part. Also tested that X86.td.expanded and AAarch64.td.expanded were unchange before and after this change. (This issue triggering this problem is a WIP patch.) Part of <rdar://problem/17688758> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217886 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-16 17:14:13 +00:00
// RUN: llvm-tblgen %s | FileCheck %s
// XFAIL: vg_leak
class Struct<int i> {
int I = !shl(i, 1);
int J = !shl(I, 1);
}
class Class<Struct s> {
int Class_J = s.J;
}
multiclass MultiClass<int i> {
def Def : Class<Struct<i>>;
// CHECK: Class_J = 8
// CHECK-NOT: Class_J = !shl(I, 1)
}
defm Defm : MultiClass<2>;