(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

computation that isn't used. Please correct this if it's wrong!

llvm-svn: 73139

Revert 73074 and 73099 because Windows doesn't have POSIX
regular expressions.  We will add an OpenBSD implementation
and re-apply ASAP.

llvm-svn: 73138

Add a !patsubst operator.  Use on string types.

llvm-svn: 73099

Make IntInits and ListInits typed.  This helps deduce types of !if and
other operators.  For the rare cases where a list type cannot be
deduced, provide a []<type> syntax, where <type> is the list element
type.

llvm-svn: 73078

llvm-svn: 72712

ADDC/ADDE use MVT::i1 (later, whatever it gets legalized to)
instead of MVT::Flag.  Remove CARRY_FALSE in favor of 0; adjust
all target-independent code to use this format.

Most targets will still produce a Flag-setting target-dependent
version when selection is done.  X86 is converted to use i32
instead, which means TableGen needs to produce different code
in xxxGenDAGISel.inc.  This keys off the new supportsHasI1 bit
in xxxInstrInfo, currently set only for X86; in principle this
is temporary and should go away when all other targets have
been converted.  All relevant X86 instruction patterns are
modified to represent setting and using EFLAGS explicitly.  The
same can be done on other targets.

The immediate behavior change is that an ADC/ADD pair are no
longer tightly coupled in the X86 scheduler; they can be
separated by instructions that don't clobber the flags (MOV).
I will soon add some peephole optimizations based on using
other instructions that set the flags to feed into ADC.

llvm-svn: 72707

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

it accordingly. Thanks to Jakob Stoklund Olesen for pointing
out how this might be useful.

llvm-svn: 68986

This will be used to replace things like X86's MOV32to32_.

Enhance ScheduleDAGSDNodesEmit to be more flexible and robust
in the presense of subregister superclasses and subclasses. It
can now cope with the definition of a virtual register being in
a subclass of a use.

Re-introduce the code for recording register superreg classes and
subreg classes. This is needed because when subreg extracts and
inserts get coalesced away, the virtual registers are left in
the correct subclass.

llvm-svn: 68961