1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-26 12:43:36 +01:00
Commit Graph

70 Commits

Author SHA1 Message Date
Kazuaki Ishizaki
09203c3fb4 [llvm] NFC: fix trivial typos in documents
Reviewers: hans, Jim

Reviewed By: Jim

Subscribers: jvesely, nhaehnle, mgorny, arphaman, bmahjour, kerbowa, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D73017
2020-01-22 11:32:51 +08:00
Simon Tatham
951525e0a5 [TableGen] Introduce an if/then/else statement.
Summary:
This allows you to make some of the defs in a multiclass or `foreach`
conditional on an expression computed from the parameters or iteration
variables.

It was already possible to simulate an if statement using a `foreach`
with a dummy iteration variable and a list constructed using `!if` so
that it had length 0 or 1 depending on the condition, e.g.

  foreach unusedIterationVar = !if(condition, [1], []<int>) in { ... }

But this syntax is nicer to read, and also more convenient because it
allows an else clause.

To avoid upheaval in the implementation, I've implemented `if` as pure
syntactic sugar on the `foreach` implementation: internally, `ParseIf`
actually does construct exactly the kind of foreach shown above (and
another reversed one for the else clause if present).

Reviewers: nhaehnle, hfinkel

Reviewed By: hfinkel

Subscribers: hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D71474
2020-01-14 10:19:53 +00:00
Simon Tatham
923de4e7fe [TableGen] Introduce a defvar statement.
Summary:
This allows you to define a global or local variable to an arbitrary
value, and refer to it in subsequent definitions.

The main use I anticipate for this is if you have to compute some
difficult function of the parameters of a multiclass, and then use it
many times. For example:

  multiclass Foo<int i, string s> {
    defvar op = !cast<BaseClass>("whatnot_" # s # "_" # i);
    def myRecord {
      dag a = (op this, (op that, the other), (op x, y, z));
      int b = op.subfield;
    }
    def myOtherRecord<"template params including", op>;
  }

There are a couple of ways to do this already, but they're not really
satisfactory. You can replace `defvar x = y` with a loop over a
singleton list, `foreach x = [y] in { ... }` - but that's unintuitive
to someone who hasn't seen that workaround idiom before, and requires
an extra pair of braces that you often didn't really want. Or you can
define a nested pair of multiclasses, with the inner one taking `x` as
a template parameter, and the outer one instantiating it just once
with the desired value of `x` computed from its other parameters - but
that makes it awkward to sequentially compute each value based on the
previous ones. I think `defvar` makes things considerably easier.

You can also use `defvar` at the top level, where it inserts globals
into the same map used by `defset`. That allows you to define global
constants without having to make a dummy record for them to live in:

  defvar MAX_BUFSIZE = 512;

  // previously:
  // def Dummy { int MAX_BUFSIZE = 512; }
  // and then refer to Dummy.MAX_BUFSIZE everywhere

Reviewers: nhaehnle, hfinkel

Reviewed By: hfinkel

Subscribers: hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D71407
2020-01-14 10:19:53 +00:00
Florian Hahn
f4d0b20ca5 [Docs] Fix sphinx build errors. 2019-12-23 21:53:30 +01:00
Simon Tatham
4855f53b1d [TableGen] Add bang-operators !getop and !setop.
Summary:
These allow you to get and set the operator of a dag node, without
affecting its list of arguments.

`!getop` is slightly fiddly because in many contexts you need its
return value to have a static type more specific than 'any record'. It
works to say `!cast<BaseClass>(!getop(...))`, but it's cumbersome, so
I made `!getop` take an optional type suffix itself, so that can be
written as the shorter `!getop<BaseClass>(...)`.

Reviewers: hfinkel, nhaehnle

Reviewed By: nhaehnle

Subscribers: hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D71191
2019-12-11 12:05:22 +00:00
Jordan Rupprecht
0929e30282 [docs] Fix TableGen/LangRef typos
This fixes:
 - `Pred` -> `Prep`
 - `IfDef` -> `Ifdef` (rst is case sensitive here)

llvm-svn: 363294
2019-06-13 18:42:30 +00:00
Roman Lebedev
daceaa0714 [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
Nicola Zaghen
5e75ff9541 [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
Javed Absar
84a3b263c4 [TblGen][NFC] Fix documentation formatting
llvm-svn: 352212
2019-01-25 16:17:57 +00:00
Javed Absar
173ca6da08 [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
Vyacheslav Zakharin
98b988d93a [TableGen] Preprocessing support
Differential Revision: https://reviews.llvm.org/D54926

llvm-svn: 347686
2018-11-27 18:57:43 +00:00
Vyacheslav Zakharin
4b91cb3095 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
58dae40bd6 Preprocessing support in tablegen.
Differential Revision: https://reviews.llvm.org/D53840

llvm-svn: 347092
2018-11-16 20:57:29 +00:00
Simon Tatham
7aeb5f145e [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
Nicolai Haehnle
f2f87b751f 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
f62a6ed017 TableGen: some LangRef doc fixes
Summary: Change-Id: I1442e2daa09cab727a01d8c31893b50e644a5cd3

Reviewers: tra, simon_tatham, craig.topper

Subscribers: llvm-commits

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

Change-Id: I397655dd18b7ff978c1affa3174740d9c1a82594
llvm-svn: 333901
2018-06-04 14:26:12 +00:00
Nicolai Haehnle
9a21ccd3ad 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
Simon Tatham
d6b1d9a9cf Fix BNF nits in TableGen language reference.
Summary:
In the course of writing an experimental ANTLR grammar based on this
document, I found three errors in the documented BNF:

SimpleValues of dag type are allowed to have no operands at all after
the initial DagArg specifying the operator. For example, the value
(outs) is extremely common in backends; an example in the test suite
is test/TableGen/AsmVariant.td line 30. But the BNF doesn't allow
DagArgList to expand to the empty string (it must contain at least one
DagArg), and therefore the DagArgList specifying the operands in the
dag-shaped production for SimpleValue should be optional.

In the production for BodyItem with a 'let' and an optional RangeList,
the RangeList should have braces around it if it's present, matching
code such as "let E{7-0} = ..." on test/TableGen/BitsInit.td line 42.
Those braces aren't included in the RangeList nonterminal itself, so
instead they need to be part of the optional segment of the BodyItem
production.

Finally, the identifier after 'defm' should be optional. Again, this
is very common in the real back end .td files; an example in the test
suite is in test/TableGen/defmclass.td line 49.

Reviewers: rengolin, nhaehnle, stoklund

Reviewed By: nhaehnle

Subscribers: llvm-commits

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

llvm-svn: 330570
2018-04-23 09:15:47 +00:00
Simon Tatham
74cb5781ea Test commit access.
Should be a harmless trimming of trailing whitespace from a
documentation file.

(There are other instances of trailing whitespace in this file alone.
I've only fixed one of them, on the basis that that way the rest are
still available for other people's commit-access tests :-)

llvm-svn: 330567
2018-04-23 08:41:53 +00:00
Nicolai Haehnle
ddd47aadb0 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
2079f988a9 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
Nicolai Haehnle
5962b8bbf7 TableGen: Type-check BinOps
Additionally, allow more than two operands to !con, !add, !and, !or
in the same way as is already allowed for !listconcat and !strconcat.

Change-Id: I9659411f554201b90cd8ed7c7e004d381a66fa93

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

llvm-svn: 327494
2018-03-14 11:00:43 +00:00
Nicolai Haehnle
bf9d16116d TableGen: Allow ? in lists
This makes using !dag more convenient in some cases.

Change-Id: I0a8c35e15ccd1ecec778fd1c8d64eee38d74517c

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

llvm-svn: 327493
2018-03-14 11:00:33 +00:00
Nicolai Haehnle
fb41efa751 TableGen: Add !dag function for construction
This allows constructing DAG nodes with programmatically determined
names, and can simplify constructing DAG nodes in other cases as
well.

Also, add documentation and some very simple tests for the already
existing !con.

Change-Id: Ida61cd82e99752548d7109ce8da34d29da56a5f7

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

llvm-svn: 327492
2018-03-14 11:00:26 +00:00
Nicolai Haehnle
33d8a7c561 TableGen: Add a defset statement
Allows capturing a list of concrete instantiated defs.

This can be combined with foreach to create parallel sets of def
instantiations with less repetition in the source. This purpose is
largely also served by multiclasses, but in some cases multiclasses
can't be used.

The motivating example for this change is having a large set of
intrinsics, which are generated from the IntrinsicsBackend.td file
included by Intrinsics.td, and a corresponding set of instruction
selection patterns, which are generated via the backend's .td files.

Multiclasses cannot be used to eliminate the redundancy in this case,
because a multiclass cannot span both LLVM's common .td files and
the backend .td files at the same time.

Change-Id: I879e35042dceea542a5e6776fad23c5e0e69e76b

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

llvm-svn: 327121
2018-03-09 12:24:42 +00:00
Nicolai Haehnle
1ebb6681e2 TableGen: Allow arbitrary list values as ranges of foreach
The changes to FieldInit are required to make field references (Def.field)
work inside a ForeachDeclaration: previously, Def.field wasn't resolved
immediately when Def was already a fully resolved DefInit.

Change-Id: I9875baec2fc5aac8c2b249e45b9cf18c65ae699b
llvm-svn: 327120
2018-03-09 12:24:30 +00:00
Nicolai Haehnle
f6565225c2 TableGen: add !isa operation
Change-Id: Iddb724c3ae706d82933a2d82c91d07e0e36b30e3

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

llvm-svn: 327117
2018-03-09 12:24:06 +00:00
Nicolai Haehnle
89d4955b62 TableGen: Add !foldl operation
Change-Id: I63d67bf6e0b315e2d3360e47e3b62c9517f38987
llvm-svn: 326790
2018-03-06 13:49:16 +00:00
Nicolai Haehnle
f579c9339d TableGen: Allow !cast of records, cleanup conversion machinery
Summary:
Distinguish two relationships between types: is-a and convertible-to.
For example, a bit is not an int or vice versa, but they can be
converted into each other (with range checks that you can think of
as "dynamic": unlike other type checks, those range checks do not
happen during parsing, but only once the final values have been
established).

Actually converting initializers between types is subtle: even
when values of type A can be converted to type B (e.g. int into
string), it may not be possible to do so with a concrete initializer
(e.g., a VarInit that refers to a variable of type int cannot
be immediately converted to a string).

For this reason, distinguish between getCastTo and convertInitializerTo:
the latter implements the actual conversion when appropriate, while
the former will first try to do the actual conversion and fall back
to introducing a !cast operation so that the conversion will be
delayed until variable references have been resolved.

To make the approach of adding !cast operations to work, !cast needs
to fallback to convertInitializerTo when the special string <-> record
logic does not apply.

This enables casting records to a subclass, although that new
functionality is only truly useful together with !isa, which will be
added in a later change.

The test is removed because it uses !srl on a bit sequence,
which cannot really be supported consistently, but luckily
isn't used anywhere either.

Change-Id: I98168bf52649176654ed2ec61a29bdb29970cfe7

Reviewers: arsenm, craig.topper, tra, MartinO

Subscribers: wdng, llvm-commits

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

llvm-svn: 326785
2018-03-06 13:48:39 +00:00
Nicolai Haehnle
44c4846682 TableGen: Reimplement !foreach using the resolving mechanism
Summary:
This changes the syntax of !foreach so that the first "parameter" is
a new syntactic variable: !foreach(x, lst, expr) will define the
variable x within the scope of expr, and evaluation of the !foreach
will substitute elements of the given list (or dag) for x in expr.

Aside from leading to a nicer syntax, this allows more complex
expressions where x is deeply nested, or even constant expressions
in which x does not occur at all.

!foreach is currently not actually used anywhere in trunk, but I
plan to use it in the AMDGPU backend. If out-of-tree targets are
using it, they can adjust to the new syntax very easily.

Change-Id: Ib966694d8ab6542279d6bc358b6f4d767945a805

Reviewers: arsenm, craig.topper, tra, MartinO

Subscribers: wdng, llvm-commits, tpr

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

llvm-svn: 326705
2018-03-05 15:21:04 +00:00
Nicolai Haehnle
fd97bfd063 TableGen: Add !size operation
Summary:
Returns the size of a list. I have found this to be rather useful in some
development for the AMDGPU backend where we could simplify our .td files
by concatenating list<LLVMType> for complex intrinsics. Doing so requires
us to compute the position argument for LLVMMatchType.

Basically, the usage is in a pattern that looks somewhat like this:

    list<LLVMType> argtypes =
        !listconcat(base,
                    [llvm_any_ty, LLVMMatchType<!size(base)>]);

Change-Id: I360a0b000fd488d18bea412228230fd93722bd2c

Reviewers: arsenm, craig.topper, tra, MartinO

Subscribers: wdng, llvm-commits, tpr

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

llvm-svn: 325883
2018-02-23 10:46:07 +00:00
Alex Bradbury
f467dc969c Improvements to TableGen/LangIntro.rst
Document the 'code' data type, and that value{15-17} is different to 
value{17-15}.

Patch by @chenwj (Wei-Ren Chen).

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

llvm-svn: 301920
2017-05-02 13:47:10 +00:00
Ayman Musa
144efa4313 [X86][AVX512] Adding new LLVM TableGen backend which generates the EVEX2VEX compressing tables.
X86EvexToVex machine instruction pass compresses EVEX encoded instructions by replacing them with their identical VEX encoded instructions when possible.
It uses manually supported 2 large tables that map the EVEX instructions to their VEX ideticals.
This TableGen backend replaces the tables by automatically generating them.

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

llvm-svn: 297127
2017-03-07 08:11:19 +00:00
Craig Topper
565ac04cd8 [Docs][TableGen] Remove reference to tablegen supporting octal integers. It doesn't and hasn't for at least 9 years.
llvm-svn: 287299
2016-11-18 02:28:50 +00:00
Matt Arsenault
21352a084a TableGen: Add operator !or
llvm-svn: 286936
2016-11-15 06:49:28 +00:00
Renato Golin
dfb328c437 [docs] Fixing Sphinx warnings to unclog the buildbot
Lots of blocks had "llvm" or "nasm" syntax types but either weren't following
the syntax, or the syntax has changed (and sphinx hasn't keep up) or the type
doesn't even exist (nasm?).

Other documents had :options: what were invalid. I only removed those that had
warnings, and left the ones that didn't, in order to follow the principle of
least surprise.

This is like this for ages, but the buildbot is now failing on errors. It may
take a while to upgrade the buildbot's sphinx, if that's even possible, but
that shouldn't stop us from getting docs updates (which seem down for quite
a while).

Also, we're not losing any syntax highlight, since when it doesn't parse, it
doesn't colour. Ie. those blocks are not being highlighted anyway.

I'm trying to get all docs in one go, so that it's easy to revert later if we
do fix, or at least easy to know what's to fix.

llvm-svn: 276109
2016-07-20 12:16:38 +00:00
Yunzhong Gao
ceb53a60fa Fixing a few places in this doc which look like obvious typos.
llvm-svn: 276070
2016-07-20 00:40:54 +00:00
Sylvestre Ledru
29d94cf96e fix some various typos in the doc
llvm-svn: 274449
2016-07-02 19:28:40 +00:00
Tanya Lattner
a72d000c61 Rename all references to old mailing lists to new lists.llvm.org address.
llvm-svn: 243999
2015-08-05 03:51:17 +00:00
Craig Topper
007d26c863 [TableGen] Correct the documentation for 'foreach' in the Language Intro.
llvm-svn: 239204
2015-06-06 00:44:42 +00:00
Craig Topper
886524ee76 Remove neverHasSideEffects support from TableGen CodeGenInstruction. Everyone should use hasSideEffects now.
llvm-svn: 222809
2014-11-26 04:11:14 +00:00
Jonathan Roelofs
e04abe6476 Fix typo in TableGen documentation
llvm-svn: 219018
2014-10-03 20:46:05 +00:00
Joerg Sonnenberger
eb6731f053 Document !and. Fix !shl and friends -- they provide binary operations.
llvm-svn: 217034
2014-09-03 13:17:03 +00:00
Eric Christopher
2f6f860aaa Reinstate "Nuke the old JIT."
Approved by Jim Grosbach, Lang Hames, Rafael Espindola.

This reinstates commits r215111, 215115, 215116, 215117, 215136.

llvm-svn: 216982
2014-09-02 22:28:02 +00:00
Eric Christopher
378bc328f0 Temporarily Revert "Nuke the old JIT." as it's not quite ready to
be deleted. This will be reapplied as soon as possible and before
the 3.6 branch date at any rate.

Approved by Jim Grosbach, Lang Hames, Rafael Espindola.

This reverts commits r215111, 215115, 215116, 215117, 215136.

llvm-svn: 215154
2014-08-07 22:02:54 +00:00
Rafael Espindola
e9ebbe5559 Nuke the old JIT.
I am sure we will be finding bits and pieces of dead code for years to
come, but this is a good start.

Thanks to Lang Hames for making MCJIT a good replacement!

llvm-svn: 215111
2014-08-07 14:21:18 +00:00
Pete Cooper
5e1b7f85dc Update Tablegen documents given that binary literals are now sized
llvm-svn: 215088
2014-08-07 05:47:13 +00:00
JF Bastien
314c089ba3 Fix typos in comments and doc
Committing http://reviews.llvm.org/D4798 for Robin Morisset (morisset@google.com)

llvm-svn: 214934
2014-08-05 23:27:34 +00:00
Dan Liew
4370c8b300 Fix Sphinx warnings.
llvm-svn: 213559
2014-07-21 16:39:00 +00:00
Adam Nemet
3bb0a6b076 [TableGen] Allow shift operators to take bits<n>
Convert the operand to int if possible, i.e. if the value is properly
initialized.  (I suppose there is further room for improvement here to also
peform the shift if the uninitialized bits are shifted out.)

With this little change we can now compute the scaling factor for compressed
displacement with pure tablegen code in the X86 backend.  This is useful
because both the X86-disassembler-specific part of tablegen and the assembler
need this and TD is the natural sharing place.

The patch also adds the missing documentation for the shift and add operator.

llvm-svn: 213277
2014-07-17 17:04:27 +00:00