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

llvm-svn: 68112

llvm-svn: 67758

in selectiondag patterns.  This is required for the upcoming shuffle_vector rewrite,
and as it turns out, cleans up a hack in the Alpha instruction info.

llvm-svn: 67286

errors when thrown.  This gets us nice errors like this from tblgen:

CMOVL32rr: 	(set GR32:i32:$dst, (X86cmov GR32:$src1, GR32:$src2))
/Users/sabre/llvm/Debug/bin/tblgen: error:
Included from X86.td:116:
Parsing X86InstrInfo.td:922: In CMOVL32rr: X86cmov node requires exactly 4 operands!
def CMOVL32rr : I<0x4C, MRMSrcReg,       // if <s, GR32 = GR32
^

instead of just:

CMOVL32rr: 	(set GR32:i32:$dst, (X86cmov GR32:$src1, GR32:$src2))
/Users/sabre/llvm/Debug/bin/tblgen: In CMOVL32rr: X86cmov node requires exactly 4 operands!

This is all I plan to do with this, but it should be easy enough to improve if anyone 
cares (e.g. keeping more loc info in "dag" expr records in tblgen.

llvm-svn: 66898

llvm-svn: 63812

and llvm-gcc.

llvm-svn: 63786

target directories themselves.  This also means that VMCore no longer
needs to know about every target's list of intrinsics.  Future work
will include converting the PowerPC target to this interface as an
example implementation.

llvm-svn: 63765

crashes or wrong code with codegen of large integers:
eliminate the legacy getIntegerVTBitMask and
getIntegerVTSignBit methods, which returned their
value as a uint64_t, so couldn't handle huge types.

llvm-svn: 63494

llvm-svn: 61713

llvm-svn: 61702

foldMemoryOperand how to "fold" them, by converting them into constant-pool
loads. When they aren't folded, they use xorps/cmpeqd, but for example when
register pressure is high, they may now be folded as memory operands, which
reduces register pressure.

Also, mark V_SET0 isAsCheapAsAMove so that two-address-elimination will
remat it instead of copying zeros around (V_SETALLONES was already marked).

llvm-svn: 60461