Commit Graph

8 Commits

Author SHA1 Message Date
Hal Finkel a8c1f46767 [TableGen] Correctly generate implicit anonymous prototype defs in multiclasses
Even within a multiclass, we had been generating concrete implicit anonymous
defs when parsing values (generally in value lists). This behavior was
incorrect, and led to errors when multiclass parameters were used in the
parameter list of the implicit anonymous def.

If we had some multiclass:

multiclass mc<string n> {

 ... : SomeClass<SomeOtherClass<n> >

The capture of the multiclass parameter 'n' would not work correctly, and
depending on how the implicit SomeOtherClass was used, either TableGen would
ignore something it shouldn't, or would crash.

To fix this problem, when inside a multiclass, we generate prototype anonymous
defs for implicit anonymous defs (just as we do for explicit anonymous defs).
Within the multiclass, the current record prototype is populated with a node
that is essentially: !cast<SomeOtherClass>(!strconcat(NAME, anon_value_name)).
This is then resolved to the correct concrete anonymous def, in the usual way,
when NAME is resolved during multiclass instantiation.

llvm-svn: 198348
2014-01-02 20:47:09 +00:00
Hal Finkel f2a0b2b340 [TableGen] Use the same anonymous name as the prefix on all multiclass defs
TableGen had been generating a different name for an anonymous multiclass's
NAME for every def in the multiclass. This had an unfortunate side effect: it
was impossible to reference one def within the multiclass from another (in the
parameter list, for example). By making sure we only generate an anonymous name
once per multiclass (which, as it turns out, requires only changing the name
parameter to reference type), we can now concatenate NAME within the multiclass
with a def name in order to generate a reference to that def.

This does not matter so much, in and of itself, but is necessary for a
follow-up commit that will fix variable capturing in implicit anonymous
multiclass defs (and that is important).

llvm-svn: 198340
2014-01-02 19:35:33 +00:00
NAKAMURA Takumi 5c0be2f67a Mark 36 tests as XFAIL:vg_leak in llvm/test/TableGen.
In historical reason, tblgen is not strictly required to be free from memory leaks.
For now, I mark them as XFAIL, they could be fixed, though.

llvm-svn: 194353
2013-11-10 14:26:08 +00:00
Bill Wendling 7c20aab621 FileCheckize some tests.
llvm-svn: 189060
2013-08-22 20:46:05 +00:00
NAKAMURA Takumi e55382ea55 llvm/test/TableGen: Remove XFAIL:vg_leak in dozen of tests, according to llvm-x86_64-linux-vg_leak.
llvm-svn: 169862
2012-12-11 13:14:16 +00:00
Peter Collingbourne 7f7f2e9b76 s/tblgen/llvm-tblgen/g in a few missed places, including the tests
llvm-svn: 141294
2011-10-06 13:39:59 +00:00
Jeffrey Yasskin 2f87b54f1a Add support for XFAILing valgrind runs with memory leak checking independently
of runs without leak checking.  We add -vg to the triple for non-checked runs,
or -vg_leak for checked runs.  Also use this to XFAIL the TableGen tests, since
tablegen leaks like a sieve.  This includes some valgrindArgs refactoring.

llvm-svn: 99103
2010-03-20 23:08:45 +00:00
David Greene 44f9d7a8f0 Allow multiclass def names to contain "#NAME"" where TableGen replaces
#NAME# with the name of the defm instantiating the multiclass.  This is
useful for AVX instruction naming where a "V" prefix is standard
throughout the ISA.  For example:

multiclass SSE_AVX_Inst<...> {
   def SS : Instr<...>;
   def SD : Instr<...>;
   def PS : Instr<...>;
   def PD : Instr<...>;

   def V#NAME#SS : Instr<...>;
   def V#NAME#SD : Instr<...>;
   def V#NAME#PS : Instr<...>;
   def V#NAME#PD : Instr<...>;
}

defm ADD : SSE_AVX_Inst<...>;

Results in 

ADDSS
ADDSD
ADDPS
ADDPD

VADDSS
VADDSD
VADDPS
VADDPD

llvm-svn: 70979
2009-05-05 16:28:25 +00:00