Summary:
Only instantiate anonymous records once all variable references in template
arguments have been resolved. This allows patterns like the new test case,
which in practice can appear in expressions like:
class IntrinsicTypeProfile<list<LLVMType> ty, int shift> {
list<LLVMType> types =
!listconcat(ty, [llvm_any_ty, LLVMMatchType<shift>]);
}
class FooIntrinsic<IntrinsicTypeProfile P, ...>
: Intrinsic<..., P.types, ...>;
Without this change, the anonymous LLVMMatchType instantiation would
never get resolved.
Another consequence of this change is that anonymous inline
instantiations are uniqued via the folding set of the newly introduced
VarDefInit.
Change-Id: I7a7041a20e297cf98c9109b28d85e64e176c932a
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43756
llvm-svn: 326788
Summary:
So that we will be able to generate new anonymous names more easily
outside the parser as well.
Change-Id: I28f396a7bdbc3ff0c665d466abbd3d31376e21b4
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43755
llvm-svn: 326787
Summary:
There are various places where resolving and constant folds can
get stuck, especially around casts. We don't always signal an
error for those, because in many cases they can legitimately
occur without being an error in the "untaken branch" of an !if.
Change-Id: I3befc0e4234c8e6cc61190504702918c9f29ce5c
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43754
llvm-svn: 326786
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
Summary:
No functional change intended. The removed code has a loop for
recursive resolving, which is superseded by the recursive
resolving done by the Resolver implementations.
Add a test case which was broken by an earlier version of this
change.
Change-Id: Ib208d037b77a8bbb725977f1388601fc984723d8
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43655
llvm-svn: 326784
Summary:
Allow RecordRecTy to represent the type "subclass of N superclasses",
where N may be zero. Furthermore, generate RecordRecTy instances only
with actual classes in the list.
Keeping track of multiple superclasses is required to resolve the type
of a list correctly in some cases. The old code relied on the incorrect
behavior of typeIsConvertibleTo, and an earlier version of this change
relied on a modified ordering of superclasses (it was committed in
r325884 and then reverted because unfortunately some of clang-tblgen's
backends depend on the ordering).
Previously, the DefInit for each Record would have a RecordRecTy of
that Record as its type. Now, all defs with the same superclasses will
share the same type.
This allows us to be more consistent about type checks involving records:
- typeIsConvertibleTo actually requires the LHS to be a subtype of the
RHS
- resolveTypes will return the least supertype of given record types in
all cases
- different record types in the two branches of an !if are handled
correctly
Add a test that used to be accepted without flagging the obvious type
error.
Change-Id: Ib366db1a4e6a079f1a0851e469b402cddae76714
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43680
llvm-svn: 326783
Summary:
Use the new resolver interface more explicitly, and avoid traversing
all the initializers multiple times.
Add a test case for a pattern that was broken by an earlier version
of this change.
An additional change is that we now remove *all* template arguments
after resolving them.
Change-Id: I86c828c8cc84c18b052dfe0f64c0d5cbf3c4e13c
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43652
llvm-svn: 326706
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
Summary:
The intention is to allow us to more easily restructure how resolving is
done, e.g. resolving multiple variables simultaneously, or using the
resolving mechanism to implement !foreach.
Change-Id: I4b976b54a32e240ad4f562f7eb86a4d663a20ea8
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43564
llvm-svn: 326704
It is redundant with the implementation in TypedInit.
Change-Id: I8ab1fb5c77e4923f7eb3ffae5889f0f8af6093b4
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43678
llvm-svn: 326061
Summary:
FieldInit will just rely on the standardized resolving mechanism to give
us DefInits for folding, thus simplifying the code.
Unlike the removal of resolveListElementReference, this shouldn't have
performance implications, because DefInits do not recurse inside their
record.
Change-Id: Id4544c774c9d9ee92f293615af6ecff706453f21
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43563
llvm-svn: 326060
Summary:
Resolving a VarListElementInit should just resolve the list and then
take its element. This eliminates a lot of duplicated logic and
simplifies the next steps of refactoring resolveReferences.
This does potentially cause sub-elements of the entire list to be
resolved resulting in more work, but I didn't notice a measurable
change in performance, and a later patch adds a caching mechanism that
covers at least the common case of `var[i]` in a more generic way.
Change-Id: I7b59185b855c7368585c329c31e5be38c5749dac
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43562
llvm-svn: 326059
This reverts r325884.
Clang's TableGen has dependencies on the exact ordering of superclasses.
Revert this change fully for now to fix the build.
Change-Id: Ib297f5571cc7809f00838702ad7ab53d47335b26
llvm-svn: 325891
Summary:
Only check whether the left-hand side type is a subclass (or equal to)
the right-hand side type.
This requires a further fix in handling !if expressions and in type
resolution.
Furthermore, reverse the order of superclasses so that resolveTypes will
find a least common ancestor at least in simple cases.
Add a test that used to be accepted without flagging the obvious type
error.
Change-Id: Ib366db1a4e6a079f1a0851e469b402cddae76714
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43559
llvm-svn: 325884
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
Summary:
Both of these errors should have been caught by type-checking during
parsing.
Change-Id: I891087936fd1a91d21bcda57c256e3edbe12b94d
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43558
llvm-svn: 325800
Summary:
Perhaps the distinction between the two should be removed entirely
in the long term, and the [{ ... }] syntax should just be a convenient
way of writing multi-line strings.
In the meantime, a lot of existing .td files are quite relaxed about
string vs. code, and this change allows switching on more consistent
type checks without breaking those.
Change-Id: If85e3e04469e41b58e2703b62ac0032d2711713c
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43557
llvm-svn: 325799
Summary:
There are no new test cases, but a subsequent patch will introduce
assertions that would be triggered by existing test cases without this
fix.
Change-Id: I6a82d4b311b012aff3932978ae86f6a2dcfbf725
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43556
llvm-svn: 325798
* !foreach on lists didn't evaluate operands of the RHS operator.
This made nested operators silently fail.
* A typo in the code could result in a wrong value substituted
for an operation which produced a false '!foreach requires an operator' error.
* Keep recursion over the DAG within ForeachHelper. This simplifies
things a bit as we no longer need to pass the Type around in order
to prevent recursion.
Differential Revision: https://reviews.llvm.org/D43083
llvm-svn: 324758
Summary:
Add LLVM_FORCE_ENABLE_DUMP cmake option, and use it along with
LLVM_ENABLE_ASSERTIONS to set LLVM_ENABLE_DUMP.
Remove NDEBUG and only use LLVM_ENABLE_DUMP to enable dump methods.
Move definition of LLVM_ENABLE_DUMP from config.h to llvm-config.h so
it'll be picked up by public headers.
Differential Revision: https://reviews.llvm.org/D38406
llvm-svn: 315590
They weren't used often enough to justify having two different interfaces. Push the responsiblity of creating a StringInit up to the caller.
llvm-svn: 304388
Internally both these methods just return the result of getValue on either a StringInit or a CodeInit object. In both cases this returns a StringRef pointing to a string allocated in the BumpPtrAllocator so its not going anywhere. So we can just pass that StringRef along.
This is a fairly naive patch that targets just the build failures caused by this change. There's additional work that can be done to avoid creating std::string at call sites that still think getValueAsString returns a std::string. I'll try to clean those up in future patches.
Differential Revision: https://reviews.llvm.org/D33710
llvm-svn: 304325
DagInits are allocated in a BumpPtrAllocator so they are never destructed. This means the destructor for the SmallVector never runs.
To fix this we now allocate the vectors in the BumpPtrAllocator too using TrailingObjects.
llvm-svn: 304077
These used to hold std::unique_ptrs that managed the allocation for the various *Init object so that they would be deleted on exit. Everything is allocated in a BumpPtrAllocator name so there is no reason for these to still exist.
llvm-svn: 304066
We had various variants of defining dump() functions in LLVM. Normalize
them (this should just consistently implement the things discussed in
http://lists.llvm.org/pipermail/cfe-dev/2014-January/034323.html
For reference:
- Public headers should just declare the dump() method but not use
LLVM_DUMP_METHOD or #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
- The definition of a dump method should look like this:
#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
LLVM_DUMP_METHOD void MyClass::dump() {
// print stuff to dbgs()...
}
#endif
llvm-svn: 293359
This forces the code to call StringInit::get on the string early and
avoids storing duplicates in std::string and sometimes allows pointer
comparisons instead of string comparisons.
llvm-svn: 288642
Introduce new constructor for STRCONCAT binop with a shortcut that
immediately concatenates if the two arguments are StringInits.
Makes the QualifyName code more readable and tablegen 2-3% faster.
llvm-svn: 288639
This avoid an extra construction of a std::string (and a heap
allocation) when the caller only has a StringRef but no std::string at
hand.
llvm-svn: 288610
As suggested by clang-tidy's performance-unnecessary-copy-initialization.
This can easily hit lifetime issues, so I audited every change and ran the
tests under asan, which came back clean.
llvm-svn: 272126
This is to fix an incorrect error when trying to initialize
DwarfNumbers with a !cast<int> of a bits initializer.
getValuesAsListOfInts("DwarfNumbers") would not see an IntInit
and instead the cast, so would give up.
It seems likely that this could be generalized to attempt
the convertInitializerTo for any type. I'm not really sure
why the existing code seems to special case the string cast cases
when convertInitializerTo seems like it should generally handle this
sort of thing.
llvm-svn: 243722
typeIsConvertibleTo was just calling baseClassOf(this) on the argument passed to it, but there weren't different signatures for baseClassOf so passing 'this' didn't really do anything interesting. typeIsConvertibleTo could have just been a non-virtual method in RecTy. But since that would be kind of a silly method, I instead re-distributed the logic from baseClassOf into typeIsConvertibleTo.
llvm-svn: 238648
Found by ubsan. This was taking a bool and left shifting by 32 - the
result is 64 bit, so we should really do the math in a type it fits
in.
llvm-svn: 237345
The outer if had 3 separate conditions ORed together and then the inner ifs detected which of the three conditions it was by using only a portion of the specific condition. Just put the whole condition in each inner if and remove the outer if.
llvm-svn: 237343
Nicolai Haehnle