Commit Graph

10 Commits

Author SHA1 Message Date
Nicolai Haehnle
26db53e38e TableGen: Streamline the semantics of NAME
Summary:
The new rules are straightforward. The main rules to keep in mind
are:

1. NAME is an implicit template argument of class and multiclass,
   and will be substituted by the name of the instantiating def/defm.

2. The name of a def/defm in a multiclass must contain a reference
   to NAME. If such a reference is not present, it is automatically
   prepended.

And for some additional subtleties, consider these:

3. defm with no name generates a unique name but has no special
   behavior otherwise.

4. def with no name generates an anonymous record, whose name is
   unique but undefined. In particular, the name won't contain a
   reference to NAME.

Keeping rules 1&2 in mind should allow a predictable behavior of
name resolution that is simple to follow.

The old "rules" were rather surprising: sometimes (but not always),
NAME would correspond to the name of the toplevel defm. They were
also plain bonkers when you pushed them to their limits, as the old
version of the TableGen test case shows.

Having NAME correspond to the name of the toplevel defm introduces
"spooky action at a distance" and breaks composability:
refactoring the upper layers of a hierarchy of nested multiclass
instantiations can cause unexpected breakage by changing the value
of NAME at a lower level of the hierarchy. The new rules don't
suffer from this problem.

Some existing .td files have to be adjusted because they ended up
depending on the details of the old implementation.

Change-Id: I694095231565b30f563e6fd0417b41ee01a12589

Reviewers: tra, simon_tatham, craig.topper, MartinO, arsenm, javed.absar

Subscribers: wdng, llvm-commits

Differential Revision: https://reviews.llvm.org/D47430

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@333900 91177308-0d34-0410-b5e6-96231b3b80d8
2018-06-04 14:26:05 +00:00
Hal Finkel
80bb2d981d [TableGen] Resolve complex def names inside multiclasses
We had not been trying hard enough to resolve def names inside multiclasses
that had complex concatenations, etc. Now we'll try harder.

Patch by Amaury Sechet!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237877 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-21 04:32:56 +00:00
Hal Finkel
0a3368cde5 [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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198348 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-02 20:47:09 +00:00
Hal Finkel
2370e55a53 [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).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198340 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-02 19:35:33 +00:00
NAKAMURA Takumi
a22657f457 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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194353 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-10 14:26:08 +00:00
Bill Wendling
b4be7f6b04 FileCheckize some tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189060 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-22 20:46:05 +00:00
NAKAMURA Takumi
f38833c7ad llvm/test/TableGen: Remove XFAIL:vg_leak in dozen of tests, according to llvm-x86_64-linux-vg_leak.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169862 91177308-0d34-0410-b5e6-96231b3b80d8
2012-12-11 13:14:16 +00:00
Peter Collingbourne
5d5c0624d0 s/tblgen/llvm-tblgen/g in a few missed places, including the tests
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141294 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-06 13:39:59 +00:00
Jeffrey Yasskin
32989deb96 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.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99103 91177308-0d34-0410-b5e6-96231b3b80d8
2010-03-20 23:08:45 +00:00
David Greene
065f259ff5 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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70979 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-05 16:28:25 +00:00