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. =]
llvm-svn: 169131
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.
llvm-svn: 166712
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<>.
llvm-svn: 165646
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.
llvm-svn: 165291
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.
llvm-svn: 164195
- 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.
llvm-svn: 163360
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.
llvm-svn: 160098
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.
llvm-svn: 152023
(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)
llvm-svn: 148262
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
llvm-svn: 144422
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.
llvm-svn: 142518
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.
llvm-svn: 142510
Allow template arg names to be Inits. This is further work to
implement paste as it allows template names to participate in paste
operations.
llvm-svn: 142500
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.
llvm-svn: 142498
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.
llvm-svn: 142497
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.
llvm-svn: 142496
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.
llvm-svn: 141315
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.
llvm-svn: 141101
