llvm-svn: 98918

to a vector that CGT stores instead of synthesizing it on every 
call.

llvm-svn: 98910

llvm-svn: 98906

llvm-svn: 98904

llvm-svn: 98900

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

shouldn't change this.

llvm-svn: 98872

Add checking that the input/output operand list in spelled right.

llvm-svn: 98865

now enforces that input/output named values have hte same type.

llvm-svn: 98535

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

needs to be majorly refactored, but this spot bugfix allows
things like:

 def vmrghw_shuffle : PatFrag<(ops node:$lhs, node:$rhs),
                             (vector_shuffle (v4i32 node:$lhs), node:$rhs), [{
...

llvm-svn: 97952

(set GPR, somecomplexpattern)

if somecomplexpattern doesn't declare what it can match.

llvm-svn: 97513

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

respects -debug-only=something-else.

llvm-svn: 97307

input/output patterns have the same type.  It turns out that 
this triggers all the time because we don't infer types 
between these boundaries.  Until we do, don't turn this on.

llvm-svn: 96905

of a pattern and where the uses have different types.

llvm-svn: 96904

this is tidier and can find bugs.

llvm-svn: 96900

but not in the input.  Previously, this would trigger an abort
late in the isel logic.

llvm-svn: 96898

llvm-svn: 96896

llvm-svn: 96891

llvm-svn: 96889

llvm-svn: 96466

llvm-svn: 96199

on TreePatternNode to be methods on TreePatternNode.

llvm-svn: 96197

llvm-svn: 96186

llvm-svn: 92155

Do not infer the target type for COPY_TO_REGCLASS from dest regclass, this won't work if it can contain several types. Require explicit result type for the node for now. This fixes PR5364.

PS: It seems that blackfin usage of copy_to_regclass is completely bogus!
llvm-svn: 85766

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

llvm-svn: 79821

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

arguments that are vectors of any size and element type.

llvm-svn: 78631

llvm-svn: 78610

llvm-svn: 77503

 - Sorry, I can't help myself.

 - No intended functionality change.

llvm-svn: 74742

llvm-svn: 74276

llvm-svn: 73602