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 w

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

llvm-svn: 333900

show more ...

[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.

Patc

[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!

llvm-svn: 237877

show more ...

[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 va

[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

show more ...

[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

[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

show more ...

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.

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

show more ...

FileCheckize some tests.

llvm-svn: 189060

llvm/test/TableGen: Remove XFAIL:vg_leak in dozen of tests, according to llvm-x86_64-linux-vg_leak.

llvm-svn: 169862

s/tblgen/llvm-tblgen/g in a few missed places, including the tests

llvm-svn: 141294

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 t

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

show more ...

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

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

show more ...