llvm-svn: 75142

instructions, which implies that there is an explicit memory operand.  There is
(however) no explicit memory operand; although this is a store, the only memory
operand is implicit, indicated by DS:EDI.  This causes the table-generation code
for the disassembler to report an error."

Patch by Sean Callanan!

llvm-svn: 73989

nodes for vectors with an i16 element type.  Add an optimization for 
building a vector which is all zeros/undef except for the bottom 
element, where the bottom element is an i8 or i16.

llvm-svn: 72988

llvm-svn: 72985

llvm-svn: 72817

llvm-svn: 72808

the Intel manual (screenshot) says it should be 0b11110110 (f6).  The existing
encoding causes a disassembly conflict with MMX_PAVGBrm, which really should be
0f e0."

Patch by Sean Callanan!

llvm-svn: 72508

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: 65313

Added support for TRUNC v8i16 to v8i8 for X86 (MMX)

llvm-svn: 60916

llvm-svn: 60499

llvm-svn: 60487

llvm-svn: 58752

SSE2 registers as well as the MMX registers.

llvm-svn: 55436

llvm-svn: 55318

instructions on having SSE2.

llvm-svn: 55317

Is there way to avoid explicit target check?

llvm-svn: 55238

llvm-svn: 54026

load,store,call,return,bitcast.  This is enough to
make call and return work.

llvm-svn: 52691

llvm-svn: 51667

Note, some of the code will be moved into target independent part of DAG combiner in a subsequent patch.

llvm-svn: 50918

Handle vector move / load which zero the destination register top bits (i.e. movd, movq, movss (addr), movsd (addr)) with X86 specific dag combine.

llvm-svn: 50838

Add separate intrinsics for MMX / SSE shifts with i32 integer operands. This allow us to simplify the horribly complicated matching code.

llvm-svn: 50601

llvm-svn: 50291

llvm-svn: 50289

llvm-svn: 50278

llvm-svn: 50053

to 64-bit GPR registers on x86-64.

llvm-svn: 49757

llvm-svn: 48627

llvm-svn: 48569

Replace all target specific implicit def instructions with a target independent one: TargetInstrInfo::IMPLICIT_DEF.

llvm-svn: 48380

X86 lowering normalize vector 0 to v4i32. However DAGCombine can fold (sub x, x) -> 0 after legalization. It can create a zero vector of a type that's not expected (e.g. v8i16). We don't want to disable the optimization since leaving a (sub x, x) is really bad. Add isel patterns for other types of vector 0 to ensure correctness. It's highly unlikely to happen other than in bugpoint reduced test cases.

llvm-svn: 48279

llvm-svn: 47740

- When DAG combiner is folding a bit convert into a BUILD_VECTOR, it should check if it's essentially a SCALAR_TO_VECTOR. Avoid turning (v8i16) <10, u, u, u> to <10, 0, u, u, u, u, u, u>. Instead, simply convert it to a SCALAR_TO_VECTOR of the proper type.
- X86 now normalize SCALAR_TO_VECTOR to (BIT_CONVERT (v4i32 SCALAR_TO_VECTOR)). Get rid of X86ISD::S2VEC.

llvm-svn: 47290

x86 backend where instructions were not marked maystore/mayload, and perf issues where
instructions were not marked neverHasSideEffects.  It would be really nice if we could
write patterns for copy instructions.

I have audited all the x86 instructions down to MOVDQAmr.  The flags on others and on
other targets are probably not right in all cases, but no clients currently use this
info that are enabled by default.

llvm-svn: 45829

inferred from the instr patterns.

llvm-svn: 45824

llvm-svn: 45667

llvm-svn: 45418