test/Codegen/ARM/reg_sequence.ll but it doesn't affect the generated code
because the coalescer cleans it up.  Radar 7998853.

llvm-svn: 104185

llvm-svn: 104173

Code refactoring: pull SchedPreference enum from TargetLowering.h to TargetMachine.h and put it in its own namespace.

llvm-svn: 104147

need to be promoted.  The BUILD_VECTOR and EXTRACT_VECTOR_ELT nodes generated
here already allow the promoted type to be used without further changes, so
just do the promotion.  This fixes part of pr7167.

llvm-svn: 104141

Intrinsics which do a vector compare (results are all zero or all ones) are modeled as icmp / fcmp + sext. This is turned into a vsetcc by dag combine (yes, not a good long term solution). The targets can then isel the vsetcc to the appropriate instruction.

The trouble arises when the result of a vector cmp + sext is then and'ed with all ones. Instcombine will turn it into a vector cmp + zext, dag combiner will miss turning it into a vsetcc and hell breaks loose after that.

Teach dag combine to turn a vector cpm + zest into a vsetcc + and 1. This fixes rdar://7923010.

llvm-svn: 104094

Sink dag combine's post index load / store code that swap base ptr and index into the target hook. Only the target knows whether the swap is safe. In Thumb2 mode, the offset must be an immediate. rdar://7998649

llvm-svn: 104060

Continuously refine the register class of REG_SEQUENCE def with all the source registers and sub-register indices.

llvm-svn: 104051

Fix PR7162: Use source register classes and sub-indices to determine the correct register class of the definitions of REG_SEQUENCE.

llvm-svn: 104050

FIX PR7158. SimplifyVBinOp was asserting when it fails to constant fold (op (build_vector), (build_vector)). 

llvm-svn: 104004

- Change the logic DisableFramePointerElim() to check for the
  -disable-non-leaf-fp-elim before -disable-fp-elim.

llvm-svn: 103990

The implementation in LegalizeIntegerTypes to handle this as 
sint64->float + appropriate power of 2 is subject to double rounding,
considered incorrect by numerics people.  Use this implementation only
when it is safe.  This leads to using library calls in some cases
that produced inline code before, but it's correct now.
(EVTToAPFloatSemantics belongs somewhere else, any suggestions?)

Add a correctly rounding (though not particularly fast) conversion
that uses X87 80-bit computations for x86-32.

7885399, 5901940.  This shows up in gcc.c-torture/execute/ieee/rbug.c
in the gcc testsuite on some platforms.

llvm-svn: 103883

llvm-svn: 103882

setting kill flags.

llvm-svn: 103832

llvm-svn: 103827

the variable actually tracks.

N.B., several back-ends are using "HasCalls" as being synonymous for something
that adjusts the stack. This isn't 100% correct and should be looked into.

llvm-svn: 103802

one was subject to double rounding in extreme cases.

llvm-svn: 103744

basic block.

llvm-svn: 103725

llvm-svn: 103529

create separate virtual registers for CopyFromReg values, so uses of
them don't necessarily kill the value.

llvm-svn: 103519

to LLVM_LIBRARY_VISIBILITY and introduce LLVM_GLOBAL_VISIBILITY, which is
the opposite, for future use by dragonegg.

llvm-svn: 103495

llvm-svn: 103489

Move EmitTargetCodeForMemcpy, EmitTargetCodeForMemset, and
EmitTargetCodeForMemmove out of TargetLowering and into
SelectionDAGInfo to exercise this.

llvm-svn: 103481

llvm-svn: 103457

llvm-svn: 103441

Be careful with operand promotion. For a binary operation, the source operands may be the same. PR7018. rdar://7939869.

llvm-svn: 103419

Based on a patch by Javier Martinez.

llvm-svn: 103391

and not the real problem itself, by dropping debug info for i128 values.
rdar://7958162.

llvm-svn: 103310

llvm-svn: 103305

getConstantFP to accept the two supported long double
target types.  This was not the original intent, but
there are other places that assume this works and it's
easy enough to do.

llvm-svn: 103299

lowered copies.

llvm-svn: 103228

llvm-svn: 103227

doesn't have to guess.

llvm-svn: 103194

llvm-svn: 103139

support a new bottom-up mode.

llvm-svn: 103138

llvm-svn: 103126

Instruction selection optimizations may have moved the def of a function argument out of the entry block. rdar://7937489

llvm-svn: 102993

llvm-svn: 102984

llvm-svn: 102981

in registers into a separate function to de-couple it from the
top-down-specific logic in getRegForValue.

llvm-svn: 102975

when needed. This fixes PR7001

llvm-svn: 102838