Manage Inits in a FoldingSet. This provides several benefits:
- Memory for Inits is properly managed
- Duplicate Inits are folded into Flyweights, saving memory
- It enforces const-correctness, protecting against certain classes
of bugs
The above benefits allow Inits to be used in more contexts, which in
turn provides more dynamism to TableGen. This enhanced capability
will be used by the AVX code generator to a fold common patterns
together.
llvm-svn: 134907
value constraints on them (when defined as ImmLeaf's). This is particularly important
for X86-64, where almost all reg/imm instructions take a i64immSExt32 immediate operand,
which has a value constraint. Before this patch we ended up iseling the examples into
such amazing code as:
movabsq $7, %rax
imulq %rax, %rdi
movq %rdi, %rax
ret
now we produce:
imulq $7, %rdi, %rax
ret
This dramatically shrinks the generated code at -O0 on x86-64.
llvm-svn: 129691
kind of predicate: one that is specific to imm nodes. The predicate function
specified here just checks an int64_t directly instead of messing around with
SDNode's. The virtue of this is that it means that fastisel and other things
can reason about these predicates.
llvm-svn: 129675
structure and fix some fixmes. We now have a TreePredicateFn class
that handles all of the decoding of these things. This is an internal
cleanup that has no impact on the code generated by tblgen.
llvm-svn: 129670
This will be used to check patterns referencing a forthcoming
INSERT_SUBVECTOR SDNode. INSERT_SUBVECTOR in turn is very useful for
matching to VINSERTF128 instructions and complements the already
existing EXTRACT_SUBVECTOR SDNode.
llvm-svn: 124145
to maintain a list of types (one for each result of
the node) instead of a single type. There are liberal
hacks added to emulate the old behavior in various
situations, but they can start disolving now.
llvm-svn: 98999
record* -> instrinfo instead of std::string -> instrinfo.
This speeds up tblgen on cellcpu from 7.28 -> 5.98s with a debug
build (20%).
llvm-svn: 98916
like this:
def : Pat<(add ...),
(FOOINST)>;
When fooinst only has a single implicit def (e.g. to R1). This will be handled
as if written as (set R1, (FOOINST ...))
llvm-svn: 98897
changing the primary datastructure from being a
"std::vector<unsigned char>" to being a new TypeSet class
that actually has (gasp) invariants!
This changes more things than I remember, but one major
innovation here is that it enforces that named input
values agree in type with their output values.
This also eliminates code that transparently assumes (in
some cases) that SDNodeXForm input/output types are the
same, because this is wrong in many case.
This also eliminates a bug which caused a lot of ambiguous
patterns to go undetected, where a register class would
sometimes pick the first possible type, causing an
ambiguous pattern to get arbitrary results.
With all the recent target changes, this causes no
functionality change!
llvm-svn: 98534
ordered correctly. Previously it would get in trouble when
two patterns were too similar and give them nondet ordering.
We force this by using the record ID order as a fallback.
The testsuite diff is due to alpha patterns being ordered
slightly differently, the change is a semantic noop afaict:
< lda $0,-100($16)
---
> subq $16,100,$0
llvm-svn: 97509
node is always guaranteed to have a particular type
instead of hacking in ISD::STORE explicitly. This allows
us to use implied types for a broad range of nodes, even
target specific ones.
llvm-svn: 97355
inferencing. As far as I can tell, these are equivalent to the existing
MVT::fAny, iAny and vAny types, and having both of them makes it harder
to reason about and modify the type inferencing code.
The specific problem in PR4795 occurs when updating a vAny type to be fAny
or iAny, or vice versa. Both iAny and fAny include vector types -- they
intersect with the set of types represented by vAny. When merging them,
choose fAny/iAny to represent the intersection. This is not perfect, since
fAny/iAny also include scalar types, but it is good enough for TableGen's
type inferencing.
llvm-svn: 80423
- This manifested as non-determinism in the .inc output in rare cases (when two
distinct patterns ended up being equivalent, which is rather rare). That
meant the pattern matching was non-deterministic, which could eventually mean
the code generator selected different instructions based on the arch.
- It's probably worth making the DAGISel ensure a total ordering (or force the
user to), but the simple fix here is to totally order the Record* maps based
on a unique ID.
- PR4672, PR4711.
Yay:
--
ddunbar@giles:~$ cat ~/llvm.obj.64/lib/Target/*/*.inc | shasum
d1099ff34b21459a5a3e7021c225c080e6017ece -
ddunbar@giles:~$ cat ~/llvm.obj.ppc/lib/Target/*/*.inc | shasum
d1099ff34b21459a5a3e7021c225c080e6017ece -
--
llvm-svn: 79846
There have been a few times where I've wanted this but ended up leaving the
operand type unconstrained. It is easy to add this now and should help
catch errors in the future.
llvm-svn: 78849
PR2957
ISD::VECTOR_SHUFFLE now stores an array of integers representing the shuffle
mask internal to the node, rather than taking a BUILD_VECTOR of ConstantSDNodes
as the shuffle mask. A value of -1 represents UNDEF.
In addition to eliminating the creation of illegal BUILD_VECTORS just to
represent shuffle masks, we are better about canonicalizing the shuffle mask,
resulting in substantially better code for some classes of shuffles.
llvm-svn: 70225
ISD::VECTOR_SHUFFLE now stores an array of integers representing the shuffle
mask internal to the node, rather than taking a BUILD_VECTOR of ConstantSDNodes
as the shuffle mask. A value of -1 represents UNDEF.
In addition to eliminating the creation of illegal BUILD_VECTORS just to
represent shuffle masks, we are better about canonicalizing the shuffle mask,
resulting in substantially better code for some classes of shuffles.
A clean up of x86 shuffle code, and some canonicalizing in DAGCombiner is next.
llvm-svn: 69952
