Commit Graph

299 Commits

Author SHA1 Message Date
Simon Tatham 301ed1cb49 [TableGen] Include schedule model name in diagnostic.
If you have more than one schedule model in your TableGen target
definitions, then the diagnostic "No schedule information for
instruction 'foo'" is rather unhelpful, because it doesn't tell you
_which_ schedule model is missing the necessary information (or, as it
might be, missing the UnsupportedFeatures definition that would stop
it thinking it needed it).

Extended the message to include the name of the schedule model that
it's complaining about.

Reviewers: nhaehnle, hfinkel, javedabsar, efriedma, javed.absar

Reviewed By: javed.absar

Subscribers: javed.absar, llvm-commits

Tags: #llvm

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

llvm-svn: 358389
2019-04-15 10:06:26 +00:00
Roman Lebedev 5d9f656bb7 [TableGen] Introduce !listsplat 'binary' operator
Summary:
```
``!listsplat(a, size)``
    A list value that contains the value ``a`` ``size`` times.
    Example: ``!listsplat(0, 2)`` results in ``[0, 0]``.
```

I plan to use this in X86ScheduleBdVer2.td for LoadRes handling.

This is a little bit controversial because unlike every other binary operator
the types aren't identical.

Reviewers: stoklund, javed.absar, nhaehnle, craig.topper

Reviewed By: javed.absar

Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 358117
2019-04-10 18:26:36 +00:00
Javed Absar c85cb2fb5d [TableGen] Let list elements have a trailing comma
Let lists have an trailing comma to allow cleaner diffs e.g:
  def : Features<[FeatureA,
                  FeatureB,
                 ]>;
Reviewed By: hfinkel
Differential Revision: https://reviews.llvm.org/D59247

llvm-svn: 356986
2019-03-26 11:16:01 +00:00
Javed Absar 33888ff66b [TableGen] Give meaningful msg for def use in multiclass
When one mistakenly specifies 'def' instead of using 'defm',
the error message is quite misleading: 'Couldn't find class..'
Instead, it should recommend using defm if the multiclass of
same name exists.

Reviewed By: hfinkel

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

llvm-svn: 356985
2019-03-26 10:49:09 +00:00
Tim Renouf c4e128e221 [CodeGen] Defined MVTs v3i32, v3f32, v5i32, v5f32
AMDGPU would like to use these MVTs.

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

Change-Id: I6125fea810d7cc62a4b4de3d9904255a1233ae4e
llvm-svn: 356351
2019-03-17 22:56:38 +00:00
Simon Tatham cdb7c31f0a [TableGen] Allow 2^63-1 and 2^63-2 as int literals.
These two values correspond to the 'Empty' and 'Tombstone' special
keys defined by DenseMapInfo<int64_t>, which means that neither one
can be used as a key in DenseMap<int64_t, anything>. Hence, if you try
to use either of those values as an int literal, IntInit::get() fails
an assertion when it tries to insert them into its static cache of
int-literal objects.

Fixed by replacing the DenseMap with a std::map, which doesn't intrude
on the space of legal values of the key type.

Reviewers: nhaehnle, hfinkel, javedabsar, efriedma

Reviewed By: efriedma

Subscribers: fhahn, efriedma, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 355900
2019-03-12 09:28:19 +00:00
Javed Absar 34d3b80dba TableGen: Allow lists to be concatenated through '#'
Currently one can concatenate strings using hash(#),
but not lists, although that would be a natural thing to do. 

This patch allows one to write something like:
def : A<!listconcat([1,2], [3,4])>;
simply as :
def : A<[1,2] # [3,4]>;

This was missing feature was highlighted by Nicolai
at FOSDEM talk.

Reviewed by: nhaehnle, hfinkel

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

llvm-svn: 355414
2019-03-05 17:16:07 +00:00
Nicola Zaghen a896756955 [Tablegen] Add support for the !mul operator.
This is a small addition to arithmetic operations that improves
expressiveness of the language.

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

llvm-svn: 355187
2019-03-01 09:46:29 +00:00
Tom Stellard 9ad714f7d1 Add support for pointer types in patterns
Summary:
This adds support for defining patterns for global isel using pointer
types, for example:

def : Pat<(load GPR32:$src),
          (p1 (LOAD GPR32:$src))>;

DAGISelEmitter will ignore the pointer information and treat these
types as integers with the same bit-width as the pointer type.

Reviewers: dsanders, rtereshin, arsenm

Reviewed By: arsenm

Subscribers: Petar.Avramovic, wdng, rovka, kristof.beyls, jfb, volkan, llvm-commits

Tags: #llvm

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

llvm-svn: 354510
2019-02-20 19:43:47 +00:00
Jessica Paquette 1ed1dd6d95 [GlobalISel] Skip patterns that define complex suboperands twice instead of dying
If we run into a pattern that looks like this:

add
  (complex $x, $y)
  (complex $x, $z)

We should skip the pattern instead of asserting/doing something unpredictable.

This makes us return an Error in that case, and adds a testcase for skipped
patterns.

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

llvm-svn: 353586
2019-02-09 00:29:13 +00:00
Javed Absar a3e3d85286 [TblGen] Extend !if semantics through new feature !cond
This patch extends TableGen language with !cond operator.
Instead of embedding !if inside !if which can get cumbersome,
one can now use !cond.
Below is an example to convert an integer 'x' into a string:

    !cond(!lt(x,0) : "Negative",
          !eq(x,0) : "Zero",
          !eq(x,1) : "One,
          1        : "MoreThanOne")

Reviewed By: hfinkel, simon_tatham, greened
Differential Revision: https://reviews.llvm.org/D55758

llvm-svn: 352185
2019-01-25 10:25:25 +00:00
Daniel Sanders 157c43f823 [tblgen][disasm] Emit record names again when decoder conflicts occur.
And add a test for it.

llvm-svn: 350277
2019-01-03 00:14:33 +00:00
Craig Topper bd199f8d41 [TableGen] Preserve order of output operands in DAGISelMatcherGen
Summary:
This fixes support in DAGISelMatcher backend for DAG nodes with multiple
result values. Previously the order of results in selected DAG nodes always
matched the order of results in ISel patterns. After the change the order of
results matches the order of operands in OutOperandList instead.

For example, given this definition from the attached test case:

  def INSTR : Instruction {
    let OutOperandList = (outs GPR:$r1, GPR:$r0);
    let InOperandList = (ins GPR:$t0, GPR:$t1);
    let Pattern = [(set i32:$r0, i32:$r1, (udivrem i32:$t0, i32:$t1))];
  }

the DAGISelMatcher backend currently produces a matcher that creates INSTR
nodes with the first result `$r0` and the second result `$r1`, contrary to the
order in the OutOperandList. The order of operands in OutOperandList does not
matter at all, which is unexpected (and unfortunate) because the order of
results of a DAG node does matters, perhaps a lot.

With this change, if the order in OutOperandList does not match the order in
Pattern, DAGISelMatcherGen emits CompleteMatch opcodes with the order of
results taken from OutOperandList. Backend writers can use it to express
result reorderings in TableGen.

If the order in OutOperandList matches the order in Pattern, the result of
DAGISelMatcherGen is unaffected.

Patch by Eugene Sharygin

Reviewers: andreadb, bjope, hfinkel, RKSimon, craig.topper

Reviewed By: craig.topper

Subscribers: nhaehnle, craig.topper, llvm-commits

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

llvm-svn: 348326
2018-12-05 00:47:59 +00:00
Krzysztof Parzyszek a26a848da3 [TableGen] Examine entire subreg compositions to detect ambiguity
When tablegen detects that there exist two subregister compositions that
result in the same value for some register, it will emit a warning. This
kind of an overlap in compositions should only happen when it is caused
by a user-defined composition. It can happen, however, that the user-
defined composition is not identically equal to another one, but it does
produce the same value for one or more registers. In such cases suppress
the warning.
This patch is to silence the warning when building the System Z backend
after D50725.

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

llvm-svn: 347894
2018-11-29 18:20:08 +00:00
Simon Tatham 34860550f2 [TableGen] Better error checking for TIED_TO constraints.
There are quite strong constraints on how you can use the TIED_TO
constraint between MC operands, many of which are currently not
checked until compiler run time.

MachineVerifier enforces that operands can only be tied together in
pairs (no three-way ties), and MachineInstr::tieOperands enforces that
one of the tied operands must be an output operand (def) and the other
must be an input operand (use).

Now we check these at TableGen time, so that if you violate any of
them in a new instruction definition, you find out immediately,
instead of having to wait until you compile something that makes code
generation hit one of those assertions.

Also in this commit, all the error reports in ParseConstraint now
include the name and source location of the def where the problem
happened, so that if you do trigger any of these errors, it's easier
to find the part of your TableGen input where you made the mistake.

The trunk sources already build successfully with this additional
error check, so I think no in-tree target has any of these problems.

Reviewers: fhahn, lhames, nhaehnle, MatzeB

Reviewed By: MatzeB

Subscribers: llvm-commits

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

llvm-svn: 347743
2018-11-28 11:43:49 +00:00
Vyacheslav Zakharin f7d079e93e [TableGen] Preprocessing support
Differential Revision: https://reviews.llvm.org/D54926

llvm-svn: 347686
2018-11-27 18:57:43 +00:00
Vyacheslav Zakharin 6a5d5ac4bd Reverted r347092 due to the following build fails:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/8662
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/26263

llvm-svn: 347129
2018-11-17 02:26:34 +00:00
Vyacheslav Zakharin dd0a1fdf56 Preprocessing support in tablegen.
Differential Revision: https://reviews.llvm.org/D53840

llvm-svn: 347092
2018-11-16 20:57:29 +00:00
Valery Pykhtin 52391ea0b3 [TableGen] fix assert in !cast when used out of definition in a multiclass
Differential Revision: https://reviews.llvm.org/D53068

llvm-svn: 344134
2018-10-10 10:52:57 +00:00
Daniel Sanders 06f4ff1952 [globalisel][tblgen] Table optimization should consider the C++ code in C++ predicates
This fixes PR39045

llvm-svn: 342997
2018-09-25 17:59:02 +00:00
Stella Stamenova cc2404c01d [lit, python] Always add quotes around the python path in lit
Summary:
The issue with the python path is that the path to python on Windows can contain spaces. To make the tests always work, the path to python needs to be surrounded by quotes.

This change updates several configuration files which specify the path to python as a substitution and also remove quotes from existing tests.

Reviewers: asmith, zturner, alexshap, jakehehrlich

Reviewed By: zturner, alexshap, jakehehrlich

Subscribers: mehdi_amini, nemanjai, eraman, kbarton, jakehehrlich, steven_wu, dexonsmith, stella.stamenova, delcypher, llvm-commits

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

llvm-svn: 339073
2018-08-06 22:37:44 +00:00
Aditya Nandakumar e07b3b737b [GISel]: Add Opcodes for CTLZ/CTTZ/CTPOP
https://reviews.llvm.org/D48600

Added IRTranslator support to translate these known intrinsics into GISel opcodes.

llvm-svn: 338944
2018-08-04 01:22:12 +00:00
Stella Stamenova 02695fa8a7 [json, test] Fix the json.td test - the path to python could contain spaces
Summary: The path to the python executable can contain spaces, so it should be specified with quotes.

Reviewers: asmith, simon_tatham

Reviewed By: simon_tatham

Subscribers: llvm-commits

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

llvm-svn: 337006
2018-07-13 15:10:53 +00:00
Simon Tatham 6a8c6cadf1 [TableGen] Add a general-purpose JSON backend.
The aim of this backend is to output everything TableGen knows about
the record set, similarly to the default -print-records backend. But
where -print-records produces output in TableGen's input syntax
(convenient for humans to read), this backend produces it as
structured JSON data, which is convenient for loading into standard
scripting languages such as Python, in order to extract information
from the data set in an automated way.

The output data contains a JSON representation of the variable
definitions in output 'def' records, and a few pieces of metadata such
as which of those definitions are tagged with the 'field' prefix and
which defs are derived from which classes. It doesn't dump out
absolutely every piece of knowledge it _could_ produce, such as type
information and complicated arithmetic operator nodes in abstract
superclasses; the main aim is to allow consumers of this JSON dump to
essentially act as new backends, and backends don't generally need to
depend on that kind of data.

The new backend is implemented as an EmitJSON() function similar to
all of llvm-tblgen's other EmitFoo functions, except that it lives in
lib/TableGen instead of utils/TableGen on the basis that I'm expecting
to add it to clang-tblgen too in a future patch.

To test it, I've written a Python script that loads the JSON output
and tests properties of it based on comments in the .td source - more
or less like FileCheck, except that the CHECK: lines have Python
expressions after them instead of textual pattern matches.

Reviewers: nhaehnle

Reviewed By: nhaehnle

Subscribers: arichardson, labath, mgorny, llvm-commits

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

llvm-svn: 336771
2018-07-11 08:40:19 +00:00
Sander de Smalen 13f9425e3a [TableGen] Increase the number of supported decoder fix-ups.
The vast number of added instructions for SVE causes TableGen to fail with an assertion:

  Assertion `Delta < 65536U && "disassembler decoding table too large!"'

This patch increases the number of supported decoder fix-ups.

Reviewers: dmgreen, stoklund, petpav01

Reviewed By: dmgreen

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

llvm-svn: 336334
2018-07-05 10:39:15 +00:00
Reid Kleckner f5890e4e43 [IR] Split Intrinsics.inc into enums and implementations
Implements PR34259

Intrinsics.h is a very popular header. Most LLVM TUs care about things
like dbg_value, but they don't care how they are implemented. After I
split these out, IntrinsicImpl.inc is 1.7 MB, so this saves each LLVM TU
from scanning 1.7 MB of source that gets pre-processed away.

It also means we can modify intrinsic properties without triggering a
full rebuild, but that's probably less of a win.

I think the next best thing to do would be to split out the target
intrinsics into their own header. Very, very few TUs care about
target-specific intrinsics. It's very hard to split up the target
independent intrinsics like llvm.expect, assume, and dbg.value, though.

llvm-svn: 335407
2018-06-23 02:02:38 +00:00
Nicolai Haehnle 0ea4d06e47 TableGen/SearchableTables: Support more generic enums and tables
Summary:
This is essentially a rewrite of the backend which introduces TableGen
base classes GenericEnum, GenericTable, and SearchIndex. They allow
generating custom enums and tables with lookup functions using
separately defined records as the underlying database.

Also added as part of this change:

- Lookup functions may use indices composed of multiple fields.

- Instruction fields are supported similar to Intrinsic fields.

- When the lookup key has contiguous numeric values, the lookup
  function will directly index into the table instead of using a binary
  search.

The existing SearchableTable functionality is internally mapped to the
new primitives.

Change-Id: I444f3490fa1dbfb262d7286a1660a2c4308e9932

Reviewers: arsenm, tra, t.p.northover

Subscribers: wdng, llvm-commits

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

llvm-svn: 335225
2018-06-21 13:36:22 +00:00
Nicolai Haehnle 7d69e0f37d TableGen: Allow foreach in multiclass to depend on template args
Summary:
This also allows inner foreach loops to have a list that depends on
the iteration variable of an outer foreach loop. The test cases show
some very simple examples of how this can be used.

This was perhaps the last remaining major non-orthogonality in the
TableGen frontend.

Change-Id: I79b92d41a5c0e7c03cc8af4000c5e1bda5ef464d

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

Subscribers: wdng, llvm-commits

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

llvm-svn: 335221
2018-06-21 13:35:44 +00:00
Daniel Sanders 8ead1290e6 [globalisel][tablegen] Add support for C++ predicates on PatFrags and use it to support BFC on ARM.
So far, we've only handled special cases of PatFrag like ImmLeaf. This patch
adds support for the remaining cases using similar mechanisms.

Like most C++ code from SelectionDAG, GISel and DAGISel expect to operate on
different types and representations and as such the code is not compatible
between the two. It's therefore necessary to add an alternative implementation
in the GISelPredicateCode field.

The target test for this feature could easily be done with IntImmLeaf and this
would save on a little boilerplate. The reason I've chosen to implement this
using PatFrag.GISelPredicateCode and not IntImmLeaf is because I was unable to
find a rule that was blocked solely by lack of support for PatFrag predicates. I
found that the ones I investigated as being likely candidates for the test
were further blocked by other things.

llvm-svn: 334871
2018-06-15 23:13:43 +00:00
Nicolai Haehnle 01d261f18d 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
2018-06-04 14:26:05 +00:00
Roman Tereshin 5f5e55008f [GlobalISel][InstructionSelect] Moving Reg Bank Checks forward, perf patch 9
This patch continues a series of patches started by r332907 (reapplied
as r332917).

In this commit we move register bank checks back from epilogue of
every rule matcher to a position locally close to the rest of the
checks for a particular (nested) instruction.

This increases the number of common conditions within 2nd level
groups.

This is expected to decrease time GlobalISel spends in its
InstructionSelect pass by about 2% for an -O0 build as measured on
sqlite3-amalgamation (http://sqlite.org/download.html) targeting
AArch64 (cross-compile on x86).

Reviewers: qcolombet, dsanders, bogner, aemerson, javed.absar

Reviewed By: qcolombet

Subscribers: rovka, llvm-commits, kristof.beyls

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

llvm-svn: 333144
2018-05-23 23:58:10 +00:00
Roman Tereshin 152fc1605e [GlobalISel][InstructionSelect] Maximizing # of Group's common conditions, perf patch 8
This patch continues a series of patches started by r332907 (reapplied
as r332917).

In this commit we greedily stuff 2nd level GroupMatcher's common
conditions with as many predicates as possible. This is purely
post-processing and it doesn't change which rules are put into the
groups in the first place: that decision is made by looking at the
first common predicate only.

The compile time improvements are minor and well within error margin,
however, it's highly improbable that this transformation could
pessimize performance, thus I'm still committing it for potential
gains for targets not implementing GlobalISel yet and out of tree
targets.

Reviewers: qcolombet, dsanders, bogner, aemerson, javed.absar

Reviewed By: qcolombet

Subscribers: rovka, llvm-commits, kristof.beyls

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

llvm-svn: 333139
2018-05-23 22:50:53 +00:00
Roman Tereshin b1ba127aa8 [GlobalISel][InstructionSelect] Moving type checks forward, perf patch 6
This patch continues a series of patches started by r332907 (reapplied
as r332917)

In this commit we sort type checks towards the beginning of every rule
within the MatchTable as they fail often and it's best to fail early.

This is expected to decrease time GlobalISel spends in its
InstructionSelect pass by roughly 7% for an -O0 build as measured on
sqlite3-amalgamation (http://sqlite.org/download.html) targeting
AArch64. The amalgamation is a large single-file C-source that makes
compiler backend performance improvements to stand out from frontend.
It's also a part of CTMark.

Reviewers: qcolombet, dsanders, bogner, aemerson, javed.absar

Reviewed By: qcolombet

Subscribers: rovka, llvm-commits, kristof.beyls

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

llvm-svn: 333114
2018-05-23 19:16:59 +00:00
Roman Tereshin fedae33efa [GlobalISel][InstructionSelect] MatchTable second level grouping, perf patch 5
This patch continues a series of patches started by r332907 (reapplied
as r332917)

In this commit we start grouping rules with common first condition on
the second level of the table.

This is expected to decrease time GlobalISel spends in its
InstructionSelect pass by roughly 13% for an -O0 build as measured on
sqlite3-amalgamation (http://sqlite.org/download.html) targeting
AArch64.

Reviewers: qcolombet, dsanders, bogner, aemerson, javed.absar

Reviewed By: qcolombet

Subscribers: rovka, llvm-commits, kristof.beyls

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

llvm-svn: 333053
2018-05-23 02:04:19 +00:00
Roman Tereshin 0ee082f3b9 [GlobalISel][InstructionSelect] Switching MatchTable over opcodes, perf patch 4
This patch continues a series of patches started by r332907 (reapplied
as r332917)

In this commit we introduce a new matching opcode GIM_SwitchOpcode
that implements a jump table over opcodes and start emitting them for
root instructions.

This is expected to decrease time GlobalISel spends in its
InstructionSelect pass by roughly 20% for an -O0 build as measured on
sqlite3-amalgamation (http://sqlite.org/download.html) targeting
AArch64.

To some degree, we assume here that the opcodes form a dense set,
which is true at the moment for all upstream targets given the
limitations of our rule importing mechanism.

It might not be true for out of tree targets, specifically due to
pseudo's. If so, we might noticeably increase the size of the
MatchTable with this patch due to padding zeros. This will be
addressed later.

Reviewers: qcolombet, dsanders, bogner, aemerson, javed.absar

Reviewed By: qcolombet

Subscribers: rovka, llvm-commits, kristof.beyls

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

llvm-svn: 333017
2018-05-22 19:37:59 +00:00
Simon Dardis 13de555737 [FastISel] Permit instructions to be skipped for FastISel generation.
Some ISA's such as microMIPS32(R6) have instructions which are near identical
for code generation purposes, e.g. xor and xor16. These instructions take the
same value types for operands and return values, have the same
instruction predicates and map to the same ISD opcode. (These instructions do
differ by register classes.)

In such cases, the FastISel generator rejects the instruction definition.

This patch borrows the 'FastIselShouldIgnore' bit from rL129692 and enables
applying it to an instruction definition.

Reviewers: mcrosier

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

llvm-svn: 332983
2018-05-22 14:36:58 +00:00
Roman Tereshin 19da667599 [GlobalISel][InstructionSelect] Removing redundant num operands and nested def operands checks, perf patch 2
This patch continues a series of patches that decrease time spent by
GlobalISel in its InstructionSelect pass by roughly 60% for -O0 builds
for large inputs as measured on sqlite3-amalgamation
(http://sqlite.org/download.html) targeting AArch64.

This commit specifically removes number of operands checks that are
redundant if the instruction's opcode already guarantees that number
of operands (or more), and also avoids any kind of checks on a def
operand of a nested instruction as everything about it was already
checked at its use.

The expected performance implication is about 3% off InstructionSelect
comparing to the baseline (before the series of patches)

This patch also contains a bit of NFC changes required for further
patches in the series.

Every commit planned shares the same Phabricator Review.

Reviewers: qcolombet, dsanders, bogner, aemerson, javed.absar

Reviewed By: qcolombet

Subscribers: rovka, llvm-commits, kristof.beyls

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

llvm-svn: 332945
2018-05-22 04:31:50 +00:00
Roman Tereshin f1aa348b31 Reapply r332907 "[GlobalISel] Improving InstructionSelect's performance by reducing MatchTable..."
Apparently the compile time problem was caused by the fact that not
all compilers / STL implementations can automatically convert
std::unique_ptr<Derived> to std::unique_ptr<Base>. Fixed (hopefully)
by making sure it's std::unique_ptr<Derived>&& (rvalue ref) to
std::unique_ptr<Base> conversion instead.

llvm-svn: 332917
2018-05-21 23:28:51 +00:00
Roman Tereshin 8bdf7be5bb Revert r332907 "[GlobalISel] Improving InstructionSelect's performance by reducing MatchTable..."
There is a compile time error I didn't see locally, investigating now.

llvm-svn: 332912
2018-05-21 22:21:24 +00:00
Roman Tereshin f0dc9fa934 [GlobalISel] Improving InstructionSelect's performance by reducing MatchTable, mostly NFC, perf patch 1
This patch starts a series of patches that decrease time spent by
GlobalISel in its InstructionSelect pass by roughly 60% for -O0 builds
for large inputs as measured on sqlite3-amalgamation
(http://sqlite.org/download.html) targeting AArch64.

The performance improvements are achieved solely by reducing the
number of matching GIM_* opcodes executed by the MatchTable's
interpreter during the selection by approx. a factor of 30, which also
brings contribution of this particular part of the selection process
to the overall runtime of InstructionSelect pass down from approx.
60-70% to 5-7%, thus making further improvements in this particular
direction not very profitable.

The improvements described above are expected for any target that
doesn't have many complex patterns. The targets that do should
strictly benefit from the changes, but by how much exactly is hard to
estimate beforehand. It's also likely that such target WILL benefit
from further improvements to MatchTable, most likely the ones that
bring it closer to a perfect decision tree.

This commit specifically is rather large mostly NFC commit that does
necessary preparation work and refactoring, there will be a following
series of small patches introducing a specific optimization each
shortly after.

This commit specifically is expected to cause a small compile time
regression (around 2.5% of InstructionSelect pass time), which should
be fixed by the next commit of the series.

Every commit planned shares the same Phabricator Review.

Reviewers: qcolombet, dsanders, bogner, aemerson, javed.absar

Reviewed By: qcolombet

Subscribers: rovka, llvm-commits, kristof.beyls

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

llvm-svn: 332907
2018-05-21 22:04:39 +00:00
Daniel Sanders f84bc3793e [globalisel] Update GlobalISel emitter to match new representation of extending loads
Summary:
Previously, a extending load was represented at (G_*EXT (G_LOAD x)).
This had a few drawbacks:
* G_LOAD had to be legal for all sizes you could extend from, even if
  registers didn't naturally hold those sizes.
* All sizes you could extend from had to be allocatable just in case the
  extend went missing (e.g. by optimization).
* At minimum, G_*EXT and G_TRUNC had to be legal for these sizes. As we
  improve optimization of extends and truncates, this legality requirement
  would spread without considerable care w.r.t when certain combines were
  permitted.
* The SelectionDAG importer required some ugly and fragile pattern
  rewriting to translate patterns into this style.

This patch changes the representation to:
* (G_[SZ]EXTLOAD x)
* (G_LOAD x) any-extends when MMO.getSize() * 8 < ResultTy.getSizeInBits()
which resolves these issues by allowing targets to work entirely in their
native register sizes, and by having a more direct translation from
SelectionDAG patterns.

Each extending load can be lowered by the legalizer into separate extends
and loads, however a target that supports s1 will need the any-extending
load to extend to at least s8 since LLVM does not represent memory accesses
smaller than 8 bit. The legalizer can widenScalar G_LOAD into an
any-extending load but sign/zero-extending loads need help from something
else like a combiner pass. A follow-up patch that adds combiner helpers for
for this will follow.

The new representation requires that the MMO correctly reflect the memory
access so this has been corrected in a couple tests. I've also moved the
extending loads to their own tests since they are (mostly) separate opcodes
now. Additionally, the re-write appears to have invalidated two tests from
select-with-no-legality-check.mir since the matcher table no longer contains
loads that result in s1's and they aren't legal in AArch64 anymore.

Depends on D45540

Reviewers: ab, aditya_nandakumar, bogner, rtereshin, volkan, rovka, javed.absar

Reviewed By: rtereshin

Subscribers: javed.absar, llvm-commits, kristof.beyls

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

llvm-svn: 331601
2018-05-05 20:53:24 +00:00
Roman Tereshin 2df4c22915 [GlobalISel][InstructionSelect] Refactoring out a getMatchTable virtual method + other small NFC's
The main goal is to share getMatchTable between the Instruction
Selector and the Testgen.

The commit also contains some NFC only loosely related to refactoring
out the getMatchTable, but strongly related to the initial Testgen
patch (see https://reviews.llvm.org/D43962)

Reviewers: dsanders, aemerson

Reviewed By: dsanders

Subscribers: rovka, kristof.beyls, llvm-commits, dsanders

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

llvm-svn: 331395
2018-05-02 20:07:15 +00:00
Simon Tatham 6a02604ee4 [TableGen] Don't quote variable name when printing !foreach.
An input !foreach expression such as !foreach(a, lst, !add(a, 1))
would be re-emitted by llvm-tblgen -print-records with the first
argument in quotes, giving !foreach("a", lst, !add(a, 1)), which isn't
valid TableGen input syntax.

Reviewers: nhaehnle

Reviewed By: nhaehnle

Subscribers: llvm-commits

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

llvm-svn: 331351
2018-05-02 13:17:26 +00:00
Nicolai Haehnle 398c0b6701 TableGen: Support Intrinsic values in SearchableTable
Summary:
We will use this in the AMDGPU backend in a subsequent patch
in the stack to lookup target-specific per-intrinsic information.

The generic CodeGenIntrinsic machinery is used to ensure that,
even though we don't calculate actual enum values here, we do
get the intrinsics in the right order for the binary search
index.

Change-Id: If61cd5587963a4c5a1cc53df1e59c5e4dec1f9dc

Reviewers: arsenm, rampitec, b-sumner

Subscribers: wdng, tpr, llvm-commits

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

llvm-svn: 328937
2018-04-01 17:08:58 +00:00
Nicolai Haehnle 420e28c78c TableGen: Streamline how defs are instantiated
Summary:
Instantiating def's and defm's needs to perform the following steps:

- for defm's, clone multiclass def prototypes and subsitute template args
- for def's and defm's, add subclass definitions, substituting template
  args
- clone the record based on foreach loops and substitute loop iteration
  variables
- override record variables based on the global 'let' stack
- resolve the record name (this should be simple, but unfortunately it's
  not due to existing .td files relying on rather silly implementation
  details)
- for def(m)s in multiclasses, add the unresolved record as a multiclass
  prototype
- for top-level def(m)s, resolve all internal variable references and add
  them to the record keeper and any active defsets

This change streamlines how we go through these steps, by having both
def's and defm's feed into a single addDef() method that handles foreach,
final resolve, and routing the record to the right place.

This happens to make foreach inside of multiclasses work, as the new
test case demonstrates. Previously, foreach inside multiclasses was not
forbidden by the parser, but it was de facto broken.

Another side effect is that the order of "instantiated from" notes in error
messages is reversed, as the modified test case shows. This is arguably
clearer, since the initial error message ends up pointing directly to
whatever triggered the error, and subsequent notes will point to increasingly
outer layers of multiclasses. This is consistent with how C++ compilers
report nested #includes and nested template instantiations.

Change-Id: Ica146d0db2bc133dd7ed88054371becf24320447

Reviewers: arsenm, craig.topper, tra, MartinO

Subscribers: wdng, llvm-commits

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

llvm-svn: 328117
2018-03-21 17:12:53 +00:00
Nicolai Haehnle 2ad19016c0 TableGen: Explicitly forbid self-references to field members
Summary:
Otherwise, patterns like in the test case produce cryptic error
messages about fields being resolved incompletely.

Change-Id: I713c0191f00fe140ad698675803ab1f8823dc5bd

Reviewers: arsenm, craig.topper, tra, MartinO

Subscribers: wdng, llvm-commits

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

llvm-svn: 327850
2018-03-19 14:14:28 +00:00
Nicolai Haehnle 4186cc7c08 TableGen: Check the dynamic type of !cast<Rec>(string)
Summary:
The docs already claim that this happens, but so far it hasn't. As a
consequence, existing TableGen files get this wrong a lot, but luckily
the fixes are all reasonably straightforward.

To make this work with all the existing forms of self-references (since
the true type of a record is only built up over time), the lookup of
self-references in !cast is delayed until the final resolving step.

Change-Id: If5923a72a252ba2fbc81a889d59775df0ef31164

Reviewers: arsenm, craig.topper, tra, MartinO

Subscribers: wdng, javed.absar, llvm-commits

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

llvm-svn: 327849
2018-03-19 14:14:20 +00:00
Nicolai Haehnle 18f1998a00 TableGen: Explicitly test some cases of self-references and !cast errors
Summary:
These are cases of self-references that exist today in practice. Let's
add tests for them to avoid regressions.

The self-references in PPCInstrInfo.td can be expressed in a simpler
way. Allowing this type of self-reference while at the same time
consistently doing late-resolve even for self-references is problematic
because there are references to fields that aren't in any class. Since
there's no need for this type of self-reference anyway, let's just
remove it.

Change-Id: I914e0b3e1ae7adae33855fac409b536879bc3f62

Reviewers: arsenm, craig.topper, tra, MartinO

Subscribers: nemanjai, wdng, kbarton, llvm-commits

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

llvm-svn: 327848
2018-03-19 14:14:10 +00:00
Nicolai Haehnle c47fe129cb TableGen: Remove the cast-from-string-to-variable-reference feature
Summary:
Cast-from-string for records isn't going away, but cast-from-string for
variables is a pretty dodgy feature to have, especially when referencing
template arguments. It's doubtful that this ever worked in a reliable
way, and nobody seems to be using it, so let's get rid of it and get
some related cleanups.

Change-Id: I395ac8a43fef4cf98e611f2f552300d21e99b66a

Reviewers: arsenm, craig.topper, tra, MartinO

Subscribers: wdng, llvm-commits

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

llvm-svn: 327844
2018-03-19 14:13:37 +00:00
Nicolai Haehnle aa9ca691cd TableGen: Add !ne, !le, !lt, !ge, and !gt comparisons
Change-Id: I8e2ece677268972d578a787467f7ef52a1f33a71

Differential revision: https://reviews.llvm.org/D44114

llvm-svn: 327496
2018-03-14 11:00:57 +00:00