llvm-svn: 121196

llvm-svn: 101881

llvm-svn: 101880

comment in the generated table.

llvm-svn: 99794

where an incorrect number of operands is provided to an sdnode instead
of just a few cases.

llvm-svn: 99761

by rotating it.

llvm-svn: 99746

in some more places.

llvm-svn: 99366

llvm-svn: 99354

ApplyTypeConstraint) and make it handle multiple result nodes.

llvm-svn: 99003

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

we don't blow the smallvector as often.  No functionality change.

llvm-svn: 98968

llvm-svn: 98933

llvm-svn: 98918

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

llvm-svn: 96896

Nothing real here yet.

llvm-svn: 96575

(isprofitable|islegal)tofold checks.

llvm-svn: 96331

llvm-svn: 96199

on TreePatternNode to be methods on TreePatternNode.

llvm-svn: 96197

llvm-svn: 96187

llvm-svn: 90934

llvm-svn: 84193

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

llvm-svn: 79850

 - 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

the latter is capable of representing either a primitive or an extended type.

llvm-svn: 78713

llvm-svn: 78610

 - Sorry, I can't help myself.

 - No intended functionality change.

llvm-svn: 74742

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

llvm-svn: 69967

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

llvm-svn: 68111

llvm-svn: 67758

llvm-svn: 64111

llvm-svn: 63812