Prior to this change, it was legal to do something like
bits<2> opc = { 0, 1 };
bits<2> opc2 = { 1, 0 };
bits<2> a = { opc, opc2 };
This involved silently dropping bits from opc and opc2 which is very hard to debug.
Now the above test would be an error. Having tested with an assert, none of LLVM/clang was relying on this behaviour.
Thanks to Adam Nemet for the above test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215083 91177308-0d34-0410-b5e6-96231b3b80d8
Instead allow the variable to be declared, but don't attach an initializer. This allows more than a single error to be emitted before we exit.
Test case to follow soon in another patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214375 91177308-0d34-0410-b5e6-96231b3b80d8
This is currently for assigning from one bit init to another. It can easily be extended to other types.
Test to follow soon in another patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214374 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213277 91177308-0d34-0410-b5e6-96231b3b80d8
Use 0 for the invalid buffer instead of -1/~0 and switch to unsigned
representation to enable more idiomatic usage.
Also introduce a trivial SourceMgr::getMainFileID() instead of hard-coding 0/1
to identify the main file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212398 91177308-0d34-0410-b5e6-96231b3b80d8
string_ostream is a safe and efficient string builder that combines opaque
stack storage with a built-in ostream interface.
small_string_ostream<bytes> additionally permits an explicit stack storage size
other than the default 128 bytes to be provided. Beyond that, storage is
transferred to the heap.
This convenient class can be used in most places an
std::string+raw_string_ostream pair or SmallString<>+raw_svector_ostream pair
would previously have been used, in order to guarantee consistent access
without byte truncation.
The patch also converts much of LLVM to use the new facility. These changes
include several probable bug fixes for truncated output, a programming error
that's no longer possible with the new interface.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211749 91177308-0d34-0410-b5e6-96231b3b80d8
This is a minimal change to remove the header. I will remove the occurrences
of "using std::error_code" in a followup patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210803 91177308-0d34-0410-b5e6-96231b3b80d8
Also removed an inaccurate comment that stated that a DenseMap was used as
storage for the ListInit*'s. It's currently using a FoldingSet.
I expect there's a better way to fix this but I haven't found it yet. FoldingSet
is incompatible with the Pool template and I'm not sure if FoldingSet can be
safely replaced with a DenseMap of computed FoldingSetID's to ListInit*'s.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208293 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
It concatenates two or more lists. In addition to the !strconcat semantics
the lists must have the same element type.
My overall aim is to make it easy to append to Instruction.Predicates
rather than override it. This can be done by concatenating lists passed as
arguments, or by concatenating lists passed in additional fields.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: hfinkel, llvm-commits
Differential Revision: http://reviews.llvm.org/D3506
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208183 91177308-0d34-0410-b5e6-96231b3b80d8
This compiles with no changes to clang/lld/lldb with MSVC and includes
overloads to various functions which are used by those projects and llvm
which have OwningPtr's as parameters. This should allow out of tree
projects some time to move. There are also no changes to libs/Target,
which should help out of tree targets have time to move, if necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203083 91177308-0d34-0410-b5e6-96231b3b80d8
After this I will set the default back to F_None. The advantage is that
before this patch forgetting to set F_Binary would corrupt a file on windows.
Forgetting to set F_Text produces one that cannot be read in notepad, which
is a better failure mode :-)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202052 91177308-0d34-0410-b5e6-96231b3b80d8
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
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
Backends like OptParserEmitter assume that record names can be used as valid
identifiers.
The period '.' in generated anonymous names broke that assumption, causing a
build-time error and in practice forcing all records to be named.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197869 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM's coding standards recommend raw_ostream and MemoryBuffer for
reading and writing text.
This has the side effect of allowing clang to compile more of Support
and TableGen in the Microsoft C++ ABI.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187826 91177308-0d34-0410-b5e6-96231b3b80d8
DAG arguments can optionally be named:
(dag node, node:$name)
With this change, the node is also optional:
(dag node, node:$name, $name)
The missing node is treated as an UnsetInit, so the above is equivalent
to:
(dag node, node:$name, ?:$name)
This syntax is useful in output patterns where we currently require the
types of variables to be repeated:
def : Pat<(subc i32:$b, i32:$c), (SUBCCrr i32:$b, i32:$c)>;
This is preferable:
def : Pat<(subc i32:$b, i32:$c), (SUBCCrr $b, $c)>;
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177843 91177308-0d34-0410-b5e6-96231b3b80d8
This makes it possible to report multiple errors in one invocation.
There are already calls to PrintError in CodeGenDAGPatterns.cpp which
previously would not cause TableGen to fail.
<rdar://problem/13463339>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177573 91177308-0d34-0410-b5e6-96231b3b80d8
A double inclusion will pretty much always be an error in TableGen, so
there's no point going on just to die with "def already defined" or
whatnot.
I'm not too thrilled about the "public: ... private: ..." to expose the
DependenciesMapTy, but I really didn't see a better way to keep that
type centralized. It's a smell that indicates that some refactoring is
needed to make this code more loosely coupled.
This should avoid all bugs of the same nature as PR15189.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174582 91177308-0d34-0410-b5e6-96231b3b80d8
When the first parameter (‘Desc’) is more than 80 characters long, it will result the header line that contains the description to be more
Than (4GB!) long. Not only it takes forever to produce, the output file cannot be open, since its ginormous.
Patch by Elior Malul.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173672 91177308-0d34-0410-b5e6-96231b3b80d8
This adds an !add(a, b) operator to tablegen; this will be used
to cleanup the PPC register definitions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173445 91177308-0d34-0410-b5e6-96231b3b80d8
def foo : bar;
~~~
This allows us to produce more precise diagnostics about a certain
superclass, and even provide fixits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172085 91177308-0d34-0410-b5e6-96231b3b80d8
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
