Tidy up VSETCC lowering code a bit more by adding an llvm_unreachable and putting an a couple if conditions in a better order.

llvm-svn: 161746

llvm-svn: 161745

llvm-svn: 161743

Remove the LowerMMXCONCAT_VECTORS function. It could never execute because there are no legal 64-bit vector types that could be used as inputs to a 128-bit concat_vectors. Remove a target specific SDNode and its patterns that become unused as a result.

llvm-svn: 161742

llvm-svn: 161738

Remove unnecessary call to setOperationAction for SETCC of v2i64 under SSE42. It was already called for the same under SSE2.

llvm-svn: 161737

architecture

It broke MultiSource/Applications/JM/ldecod/ldecod on armv7 thumb O0 g and armv7
thumb O3.

llvm-svn: 161736

llvm-svn: 161735

llvm-svn: 161734

Use MVT.isXBitVector instead of EVT.isXBitVector when setting up operation actions. Compiles to smaller code.

llvm-svn: 161733

- FCMOV only supports a subset of X86 conditions. Skip boolean
  simplification if X86 condition is not valid for FCMOV.
- add a minimal test case for PR13577.

llvm-svn: 161732

Move setOperationAction for CONCAT_VECTORS for 256-bit vectors into loop since all 256-bit types are supported.

llvm-svn: 161730

llvm-svn: 161727

llvm-svn: 161726

Add a couple default: llvm_unreachable() to some switch statements. Fix a bad message in an existing llvm_unreachable.

llvm-svn: 161725

FeatureFastUAMem for Nehalem, Westmere and Sandy Bridge.

FeatureFastUAMem is already on if we pass in nehalem or westmere as a command
argument.

rdar: 7252306
llvm-svn: 161717

This change is to be enabled in clang.

rdar://9877866
PR://13350

llvm-svn: 161693

- if a boolean test (X86ISD::CMP or X86ISD:SUB) checks a boolean value
  generated from X86ISD::SETCC, try to simplify the boolean value
  generation and checking by reusing the original EFLAGS with proper
  condition code
- add hooks to X86 specific SETCC/BRCOND/CMOV, the major 3 places
  consuming EFLAGS

part of patches fixing PR12312

llvm-svn: 161687

llvm-svn: 161664

llvm-svn: 161657

the register info for getEncodingValue. This builds on the
small patch of yesterday to set HWEncoding in the register
file.

One (deprecated) use was turned into a hard number to avoid
needing register info in the old JIT.

llvm-svn: 161628

llvm-svn: 161626

This new API will be used by clang to parse ms-style inline asms.

One goal of this project is to use this style of inline asm for targets other
then x86.  Therefore, this API needs to be implemented for non-x86 targets at
some point in the future.

llvm-svn: 161624

The fields in the td definition were switched.

llvm-svn: 161607

This patch corrects the definition of umlal/smlal instructions and adds support
for matching them to the ARM dag combiner.

Bug 12213

Patch by Yin Ma!

llvm-svn: 161581

llvm-svn: 161564

This way of using getNextOperandForReg() was unlikely to work as
intended. We don't give any guarantees about the order of operands in
the use-def chains, so looking only at operands following a given
operand in the chain doesn't make sense.

llvm-svn: 161542

This replaces an existing subtarget hook on ARM and allows standard
CodeGen passes to potentially use the property.

llvm-svn: 161471

llvm-svn: 161469

We perform the following:
1> Use SUB instead of CMP for i8,i16,i32 and i64 in ISel lowering.
2> Modify MachineCSE to correctly handle implicit defs.
3> Convert SUB back to CMP if possible at peephole.

Removed pattern matching of (a>b) ? (a-b):0 and like, since they are handled
by peephole now.

rdar://11873276

llvm-svn: 161462

We can't rematerialize a PIC base after register allocation anyway, and
scanning physreg use-def chains is very expensive in a function with
many calls.

<rdar://problem/12047515>

llvm-svn: 161461

do so when the high bits are known zero. This caused a subtle miscompilation.

rdar://12027825 

llvm-svn: 161451

Thanks to Alex Rosenberg for the suggestion.

llvm-svn: 161428

--- Reverse-merging r161371 into '.':
U    include/llvm/Target/TargetData.h
U    lib/Target/TargetData.cpp

llvm-svn: 161394

initialize fields of the class that it used.

The result was nonsense code.

Before:
0000000000000000 <foo>:
   0:    00441100     0x441100
   4:    03e00008     jr    ra
   8:    00000000     nop

After:
0000000000000000 <foo>:
   0:    00041000     sll    v0,a0,0x0
   4:    03e00008     jr    ra
   8:    00000000     nop 

llvm-svn: 161377

llvm-svn: 161371

This allows codegen passes to query properties like
InstrItins->SchedModel->IssueWidth. It also ensure's that
computeOperandLatency returns the X86 defaults for loads and "high
latency ops". This should have no significant impact on existing
schedulers because X86 defaults happen to be the same as global
defaults.

llvm-svn: 161370

I hit this in a very large program (spirit.cpp), but 
have not figured out how to make a small make check
test for it.

llvm-svn: 161366

were using a class defined for 32 bit instructions and 
thus the instruction was for addiu instead of daddiu.

This was corrected by adding the instruction opcode as a 
field in the  base class to be filled in by the defs.

llvm-svn: 161359

These 2 relocations gain access to the 
highest and the second highest 16 bits
of a 64 bit object.

R_MIPS_HIGHER %higher(A+S)
The %higher(x) function is [ (((long long) x + 0x80008000LL) >> 32) & 0xffff ]. 

R_MIPS_HIGHEST %highest(A+S)
The %highest(x) function is [ (((long long) x + 0x800080008000LL) >> 48) & 0xffff ]. 

llvm-svn: 161348