Added a test case for handling physreg aliases during pre-RA-sched.

llvm-svn: 133063

llvm-svn: 133057

Enable the simplification of truncating-store after fixing the usage of
GetDemandBits (which must operate on the vector element type).

Fix the a usage of getZeroExtendInReg which must also be done on scalar types.

llvm-svn: 133052

converted to add x,x if x is a undef.  add undef, undef does not guarantee
that the resulting low order bit is zero.
Fixes <rdar://problem/9453156> and <rdar://problem/9487392>.

llvm-svn: 133022

Add a testcase for checking the integer-promotion of many different vector
types (with power of two types such as 8,16,32 .. 512).

Fix a bug in the integer promotion of bitcast nodes. Enable integer expanding
only if the target of the conversion is an integer (when the type action is
scalarize).

Add handling to the legalization of vector load/store in cases where the saved
vector is integer-promoted.

llvm-svn: 132985

llvm-svn: 132984

or instruction cache access. Update the targets to match it and also teach
autoupgrade.

llvm-svn: 132976

only if the number of packed elements is a power of two.
Bug found in Duncan's testcase.

llvm-svn: 132923

types such as i33 were rounded to i32. Originated from Duncan's testcase.

llvm-svn: 132893

Instead of scalarizing, and doing an element-by-element truncat, use vector
truncate.
Add support for scalarization of vectors:  i8 -> <1 x i1> (from Duncan's
testcase).

llvm-svn: 132892

llvm-svn: 132872

llvm-svn: 132871

llvm-svn: 132863

Change this DAGCombine to build AND of SHR instead of SHR of AND; this matches the ordering we prefer in instcombine.  Part of rdar://9562809.

The potential DAGCombine which enforces this more generally messes up some other very fragile patterns, so I'm leaving that alone, at least for now.

llvm-svn: 132809

No functional change.

Part of PR6965

llvm-svn: 132763

llvm-svn: 132751

I've been sitting on this long enough trying to find a test case. I
think the fix should go in now, but I'll keep working on the test case.

llvm-svn: 132701

legalize SDNodes such as BUILD_VECTOR, EXTRACT_VECTOR_ELT, etc.

llvm-svn: 132689

llvm-svn: 132681

llvm-svn: 132676

TypeLegalizer: Add support for passing of vector-promoted types in registers (copyFromParts/copyToParts).

llvm-svn: 132649

(only happens when using the -promote-elements option).

The correct legalization order is to first try to promote element. Next, we try
to widen vectors.

llvm-svn: 132648

llvm-svn: 132559

Part of rdar://9119939

llvm-svn: 132510

llvm-svn: 132479

No functional change.

llvm-svn: 132455

llvm-svn: 132424

types if the vector type is legal.

Fixes rdar://9306086

llvm-svn: 132420

the TargetLowering enum.

llvm-svn: 132418

rdar://problem/5660695

llvm-svn: 132411

llvm-svn: 132396

This patch is another step in the direction of adding vector select. In this
patch we add a flag to enable a new type legalization decision - to promote
integer elements in vectors. Currently, the rest of the codegen does not support
this kind of legalization.  This flag will be removed when the transition is
complete.

llvm-svn: 132394

Refactor the type legalizer. Switch TargetLowering to a new enum - LegalizeTypeAction.
This patch does not change the behavior of the type legalizer. The codegen
produces the same code.
This infrastructural change is needed in order to enable complex decisions
for vector types (needed by the vector-select patch).

llvm-svn: 132263

code in one place. Re-apply 131534 and fix the multi-step promotion of integers.

llvm-svn: 132217

Rewrite fast-isel integer cast handling to handle more cases, and to be simpler and more consistent.

The practical effects here are that x86-64 fast-isel can now handle trunc from i8 to i1, and ARM fast-isel can handle many more constructs involving integers narrower than 32 bits (including loads, stores, and many integer casts).

rdar://9437928 .

llvm-svn: 132099

llvm-svn: 132087

llvm-svn: 131974

  non-zero.
- Teach X86 cmov optimization to eliminate the cmov from ctlz, cttz extension
  when the source of X86ISD::BSR / X86ISD::BSF is proven to be non-zero.

rdar://9490949

llvm-svn: 131948

llvm-svn: 131926

Patch by Micah Villmow

llvm-svn: 131908