It's clearer and additionally this gets rid of the usage of `DefmID`,
which doesn't really correspond to anything in the language (it was just
used in the name of this parsing function which parsed a `MultiClassID`
and returned that multiclass's record).
This area of the code still needs a lot of work.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171938 91177308-0d34-0410-b5e6-96231b3b80d8
It's not just def's but actually a limited subset of Object's that are
allowed inside a multiclass.
Spotted by Joel Jones.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171935 91177308-0d34-0410-b5e6-96231b3b80d8
missed in the first pass because the script didn't yet handle include
guards.
Note that the script is now able to handle all of these headers without
manual edits. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169224 91177308-0d34-0410-b5e6-96231b3b80d8
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169131 91177308-0d34-0410-b5e6-96231b3b80d8
Most places can use PrintFatalError as the unwinding mechanism was not
used for anything other than printing the error. The single exception
was CodeGenDAGPatterns.cpp, where intermediate errors during type
resolution were ignored to simplify incremental platform development.
This use is replaced by an error flag in TreePattern and bailout earlier
in various places if it is set.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166712 91177308-0d34-0410-b5e6-96231b3b80d8
Some of these dyn_cast<>'s would be better phrased as isa<> or cast<>.
That will happen in a future patch.
There are also two dyn_cast_or_null<>'s slipped in instead of
dyn_cast<>'s, since they were causing crashes with just dyn_cast<>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165646 91177308-0d34-0410-b5e6-96231b3b80d8
Use isa<> or cast<> when semantically that is what is happening. Also
some trivial "style" cleanups at fix sites.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165292 91177308-0d34-0410-b5e6-96231b3b80d8
This is a mechanical change of dynamic_cast<> to dyn_cast<>. A number of
these uses are actually more like isa<> or cast<>, and will be changed
to the semanticaly appropriate one in a future patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165291 91177308-0d34-0410-b5e6-96231b3b80d8
In order to avoid rev-lock with Clang when moving to the new API, also
preserve the current API temporarily and insert a shim to implement the
new API in terms of the old.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165165 91177308-0d34-0410-b5e6-96231b3b80d8
Two deeply nested if's obscured that the sense of the conditions was
mixed up. Amazingly, TableGen's output is exactly the same even with the
sense of the tests fixed; it seems that all of TableGen's conversions
are symmetric so that the inverted sense was nonetheless correct "by
accident". As such, I couldn't come up with a test case.
If there does in fact exist a non-symmetric conversion in TableGen's
type system, then a test case should be prepared.
Despite the symmetry, both if's are left in place for robustness in the
face of future changes.
Review by Jakob.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164195 91177308-0d34-0410-b5e6-96231b3b80d8
- This patch is inspired by the failure of the following code snippet
which is used to convert enumerable values into encoding bits to
improve the readability of td files.
class S<int s> {
bits<2> V = !if(!eq(s, 8), {0, 0},
!if(!eq(s, 16), {0, 1},
!if(!eq(s, 32), {1, 0},
!if(!eq(s, 64), {1, 1}, {?, ?}))));
}
Later, PR8330 is found to report not exactly the same bug relevant
issue to bit/bits values.
- Instead of resolving bit/bits values separately through
resolveBitReference(), this patch adds getBit() for all Inits and
resolves bit value by resolving plus getting the specified bit. This
unifies the resolving of bit with other values and removes redundant
logic for resolving bit only. In addition,
BitsInit::resolveReferences() is optimized to take advantage of this
origanization by resolving VarBitInit's variable reference first and
then getting bits from it.
- The type interference in '!if' operator is revised to support possible
combinations of int and bits/bit in MHS and RHS.
- As there may be illegal assignments from integer value to bit, says
assign 2 to a bit, but we only check this during instantiation in some
cases, e.g.
bit V = !if(!eq(x, 17), 0, 2);
Verbose diagnostic message is generated when invalid value is
resolveed to help locating the error.
- PR8330 is fixed as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163360 91177308-0d34-0410-b5e6-96231b3b80d8
Keep track of the set/unset state of these bits along with their
true/false values, but treat '?' as '0' for now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162461 91177308-0d34-0410-b5e6-96231b3b80d8
When reporting an error for a defm, we would previously only report the
location of the outer defm, which is not always where the error is.
Now we also print the location of the expanded multiclass defs:
lib/Target/X86/X86InstrSSE.td:2902:12: error: foo
defm ADD : basic_sse12_fp_binop_s<0x58, "add", fadd, SSE_ALU_ITINS_S>,
^
lib/Target/X86/X86InstrSSE.td:2801:11: note: instantiated from multiclass
defm PD : sse12_fp_packed<opc, !strconcat(OpcodeStr, "pd"), OpNode, VR128,
^
lib/Target/X86/X86InstrSSE.td:194:5: note: instantiated from multiclass
def rm : PI<opc, MRMSrcMem, (outs RC:$dst), (ins RC:$src1, x86memop:$src2),
^
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162409 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, def NAME values were only populated, and references to NAME
resolved, when NAME was referenced in the 'def' entry of the multiclass
sub-entry. e.g.,
multiclass foo<...> {
def prefix_#NAME : ...
}
It's useful, however, to be able to reference NAME even when the default
def name is used. For example, when a multiclass has 'def : Pat<...>'
or 'def : InstAlias<...>' entries which refer to earlier instruction
definitions in the same multiclass. e.g.,
multiclass myMulti<RegisterClass rc> {
def _r : myI<(outs rc:$d), (ins rc:$r), "r $d, $r", []>;
def : InstAlias<\"wilma $r\", (!cast<Instruction>(NAME#\"_r\") rc:$r, rc:$r)>;
}
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161198 91177308-0d34-0410-b5e6-96231b3b80d8
def Pat<...>;
Results in 'record name is not a string!' diagnostic. Not the best,
but the lack of location information moves it from not very helpful
into completely useless. We're in the Record class when throwing the
error, so just add the location info directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@160098 91177308-0d34-0410-b5e6-96231b3b80d8
The TableGenBackend base class doesn't do much, and will be removed
completely soon.
Patch by Sean Silva!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158311 91177308-0d34-0410-b5e6-96231b3b80d8
There should be no difference in the resulting binary, given a sufficiently
smart compiler. However we already had compiler timeouts on the generated
code in Intrinsics.gen, this hopefully makes the lives of slow buildbots a
little easier.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157161 91177308-0d34-0410-b5e6-96231b3b80d8
hashing infrastructure. I wonder why we don't just use StringMap here,
and I may revisit the issue if I have time, but for now I'm just trying
to consolidate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152023 91177308-0d34-0410-b5e6-96231b3b80d8
Add some data structures to represent for loops. These will be
referenced during object processing to do any needed iteration and
instantiation.
Add foreach keyword support to the lexer.
Add a mode to indicate that we're parsing a foreach loop. This allows
the value parser to early-out when processing the foreach value list.
Add a routine to parse foreach iteration declarations. This is
separate from ParseDeclaration because the type of the named value
(the iterator) doesn't match the type of the initializer value (the
value list). It also needs to add two values to the foreach record:
the iterator and the value list.
Add parsing support for foreach.
Add the code to process foreach loops and create defs based
on iterator values.
Allow foreach loops to be matched at the top level.
When parsing an IDValue check if it is a foreach loop iterator for one
of the active loops. If so, return a VarInit for it.
Add Emacs keyword support for foreach.
Add VIM keyword support for foreach.
Add tests to check foreach operation.
Add TableGen documentation for foreach.
Support foreach with multiple objects.
Support non-braced foreach body with one object.
Do not require types for the foreach declaration. Assume the iterator
type from the iteration list element type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151164 91177308-0d34-0410-b5e6-96231b3b80d8
Providing a template argment to a non-templatized class was crashing
tblgen. Add a diagnostic.
For example,
$ cat bug.td
class A;
def B : A<0> {
}
$ llvm-tblgen bug.td
bug.td:3:11: error: template argument provided to non-template class
def B : A<0> {
^
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148565 91177308-0d34-0410-b5e6-96231b3b80d8
(This time I believe I've checked all the -Wreturn-type warnings from GCC & added the couple of llvm_unreachables necessary to silence them. If I've missed any, I'll happily fix them as soon as I know about them)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148262 91177308-0d34-0410-b5e6-96231b3b80d8
The code type was always identical to a string anyway. Now it is simply
a synonym. The code literal syntax [{...}] is still valid.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148092 91177308-0d34-0410-b5e6-96231b3b80d8
It's ignored by the assembler when present, but is legal syntax. Other
instructions have something similar, but for some mnemonics it's
only sometimes not significant, so this quick check in the parser will
need refactored into something more robust soon-ish. This gets some
basics working in the meantime.
Partial for rdar://10435264
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144422 91177308-0d34-0410-b5e6-96231b3b80d8
Add a paste operator '#' to take two identifier-like strings and joint
them. Internally paste gets represented as a !strconcat() with any
necessary casts to string added.
This will be used to implement basic for loop functionality as in:
for i = [0, 1, 2, 3, 4, 5, 6, 7] {
def R#i : Register<...>
}
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142525 91177308-0d34-0410-b5e6-96231b3b80d8
During multiclass def instantiation, replace NAME in any expressions
with the value of the def or defm ID.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142524 91177308-0d34-0410-b5e6-96231b3b80d8
Parse and process a defm prefix as an Init expression. This allows
paste operations to create defm prefixes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142523 91177308-0d34-0410-b5e6-96231b3b80d8
Stop parsing a value if we are in name parsing mode and we see a left
brace. A left brace indicates the start of an object body when we are
parsing a name.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142521 91177308-0d34-0410-b5e6-96231b3b80d8
Augment the value parser to respect the parse mode and not error if an
ID doesn't map to an object and we are in name parsing mode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142520 91177308-0d34-0410-b5e6-96231b3b80d8
Add a mode control to value and ID parsers. The two modes are:
- Parse a value. Expect the parsed ID to map to an existing object.
- Parse a name. Expect the parsed ID to not map to any existing object.
The first is used when parsing an identifier to be looked up, for
example a record field or template argument. The second is used for
parsing declarations. Paste functionality implies that declarations
can contain arbitrary expressions so we need to be able to call into
the general value parser to parse declarations with paste operators.
So we need a way to parse a value-like thing without expecting that
the result will map to some existing object. This parse mode provides
that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142519 91177308-0d34-0410-b5e6-96231b3b80d8
Add a Value named "NAME" to each Record. This will be set to the def or defm
name when instantiating multiclasses. This will replace the #NAME# processing
hack once paste functionality is in place.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142518 91177308-0d34-0410-b5e6-96231b3b80d8
Use lookahead to determine whether a number is really a number or is
part of something forming an identifier. This won't come into play
until the paste operator is recognized as a unique token.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142513 91177308-0d34-0410-b5e6-96231b3b80d8
Add a peek function to let the Lexer look at a character arbitrarily
far ahead in the stream without consuming anything. We need this to
disambiguate numbers and operands of a paste operation. For example:
def foo#8i
Without lookahead the lexer will treat '8' as a number rather than as
part of a string to be pasted to form an identifier.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142512 91177308-0d34-0410-b5e6-96231b3b80d8
When resolving Record values, be sure to update the Record name as it
may contain references to the value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142511 91177308-0d34-0410-b5e6-96231b3b80d8
Add Record names to be changed even on Records that aren't yet
registered. We need to be able to do this for paste functionality
because we do not want to register def names before they are unique
and that can only happen once all paste operations are done. This
change lets us update Record names formed by paste operations and
register the result later.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142510 91177308-0d34-0410-b5e6-96231b3b80d8
Allow template arg names to be Inits. This is further work to
implement paste as it allows template names to participate in paste
operations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142500 91177308-0d34-0410-b5e6-96231b3b80d8
Convert SetValue to take the value name as an Init. This allows us to
set values for variables whose names are not yet fully resolved.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142499 91177308-0d34-0410-b5e6-96231b3b80d8
Add a couple of utility functions to take a variable name and qualify
it with the namespace of the enclosing class and/or multiclass. This
is inpreparation for making template arg names first-class Inits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142498 91177308-0d34-0410-b5e6-96231b3b80d8
Make the VarInit name an Init itself. We need this to implement paste
functionality so we can reference variables whose names are not yet
completely resolved.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142497 91177308-0d34-0410-b5e6-96231b3b80d8
Add accessors to get Record values by Init name. This lets us look up
Record values whose names are not yet fully resolved. More work
toward paste.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142496 91177308-0d34-0410-b5e6-96231b3b80d8
Multidefs are a bit unwieldy and incomplete. Remove them in favor of
another mechanism, probably for loops.
Revert "Make Test More Thorough"
Revert "Fix a typo."
Revert "Vim Support for Multidefs"
Revert "Emacs Support for Multidefs"
Revert "Document Multidefs"
Revert "Add a Multidef Test"
Revert "Update Test for Multidefs"
Revert "Process Multidefs"
Revert "Parser Multidef Support"
Revert "Lexer Support for Multidefs"
Revert "Add Multidef Data Structures"
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141378 91177308-0d34-0410-b5e6-96231b3b80d8
Fix VarListElementInit::resolveListElementReference to return a
partially resolved VarListElementInint in the case where full
resolution is not possible. This allows TableGen to make forward
progress resolving certain complex list expressions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141315 91177308-0d34-0410-b5e6-96231b3b80d8
For consistency, prefix multiclass template arg names with the
multiclass name followed by "::" to avoid name clashes among
multiclass arguments and other entities in the multiclass.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141239 91177308-0d34-0410-b5e6-96231b3b80d8
Process each multidef declared in a multiclass. Iterate through the
list and instantiate a def in the multiclass for each item, resolving
the list item to the temporary iterator (possibly) used in the
multidef ObjectBody. We then process each generated def in the normal
way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141233 91177308-0d34-0410-b5e6-96231b3b80d8
Add parser support to recognize multidefs. No processing on the
multidef is done at this point. The grammar is:
MultiDef = MULTIDEF ObjectName < Value, Declaration, Value > ObjectBody
The first Value must be resolveable to a list and the second Value
must be resolveable to an integer. The Declaration is a temporary
value used as an iterator to refer to list items during processing.
It may be passed into the ObjectBody where it will be substituted with
the list value used to instantiate each def.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141232 91177308-0d34-0410-b5e6-96231b3b80d8
Move the code to instantiate a multiclass def, bind its arguments and
resolve its members into three helper functions. These will be reused
to support a new kind of multiclass def: a multidef.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141229 91177308-0d34-0410-b5e6-96231b3b80d8
When resolving an operator list element reference, resolve all
operator operands and try to fold the operator first. This allows the
operator to collapse to a list which may then be indexed.
Before, it was not possible to do this:
class D<int a, int b> { ... }
class C<list<int> A> : D<A[0], A[1]>;
class B<list<int> b> : C<!foreach(...,b)>;
Now it is.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141101 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds a preprocessor that can expand nested for-loops for
saving some copy-n-paste in *.td files.
The preprocessor is not yet integrated with TGParser, and so it has
no direct effect on *.td inputs. However, you may preprocess an td
input (and only preprocess it).
To test the proprecessor, type:
tblgen -E -o $@ $<
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141079 91177308-0d34-0410-b5e6-96231b3b80d8
