LSR always tries to make the ICmp in the loop latch use the incremented
induction variable. This allows the induction variable to be kept in a
single register.

When the induction variable limit is equal to the stride,
SimplifySetCC() would break LSR's hard work by transforming:

   (icmp (add iv, stride), stride) --> (cmp iv, 0)

This forced us to use lea for the IC update, preventing the simpler
incl+cmp.

<rdar://problem/7643606>
<rdar://problem/11184260>

llvm-svn: 154119

testcase slightly less trivial. This fixes rdar://11171718.

llvm-svn: 154118

Treat f16 the same as f80/f128 for the purposes of generating constants during instruction selection.

llvm-svn: 154113

Added support for unpredictable ADC/SBC instructions on ARM, and also fixed some corner cases involving the PC register as an operand for these instructions.

llvm-svn: 154101

llvm-svn: 154100

  modify it.

llvm-svn: 154098

  of the BBVectorizePass without using command line option. As pointed out
  by Hal, we can ask the TargetLoweringInfo for the architecture specific
  VectorizeConfig to perform vectorizing with architecture specific
  information.

llvm-svn: 154096

 BasicBlock in other passes, e.g. we can call vectorizeBasicBlock in the
 loop unroll pass right after the loop is unrolled.

llvm-svn: 154089

rdar://11189467

llvm-svn: 154087

the caller requested a null-terminated one.

When mapping the file there could be a racing issue that resulted in the file being larger
than the FileSize passed by the caller. We already have an assertion
for this in MemoryBuffer::init() but have a runtime guarantee that
the buffer will be null-terminated, so do a copy that adds a null-terminator.

Protects against crash of rdar://11161822.

llvm-svn: 154082

Plain 'cpsr' is an alias for 'cpsr_fc'.

rdar://11153753

llvm-svn: 154080

LSR can fold three addressing modes into its ICmpZero node:

  ICmpZero BaseReg + Offset      => ICmp BaseReg, -Offset
  ICmpZero -1*ScaleReg + Offset  => ICmp ScaleReg, Offset
  ICmpZero BaseReg + -1*ScaleReg => ICmp BaseReg, ScaleReg

The first two cases are only used if TLI->isLegalICmpImmediate() likes
the offset.

Make sure the right Offset sign is passed to this method in the second
case. The ARM version is not symmetric.

<rdar://problem/11184260>

llvm-svn: 154079

llvm-svn: 154062

llvm-svn: 154054

REG_SEQUENCE expansion to COPY instructions wasn't taking account of sub register indices on the source registers.  No simple test case

llvm-svn: 154051

Still not fixed in the standard ;)

llvm-svn: 154044

llvm-svn: 154039

types for N32 ABI. Add new test case and update existing ones.

llvm-svn: 154038

types for N32 ABI. Test case will be updated after the patch that fixes
TargetLowering::getPICJumpTableRelocBase is checked in.

llvm-svn: 154036

types for N32 ABI and update test case.

llvm-svn: 154034

A MOVCCr instruction can be commuted by inverting the condition. This
can help reduce register pressure and remove unnecessary copies in some
cases.

<rdar://problem/11182914>

llvm-svn: 154033

llvm-svn: 154032

types for N32 ABI and update test case.

llvm-svn: 154031

This allows us to keep passing reduced masks to SimplifyDemandedBits, but
know about all the bits if SimplifyDemandedBits fails. This allows instcombine
to simplify cases like the one in the included testcase.

llvm-svn: 154011

  reducing unroll count, otherwise the reduced unroll count is not taking
  the "OptimizeForSize" attribute into account.

llvm-svn: 154007

llvm-svn: 154004

llvm-svn: 153996

llvm-svn: 153984

llvm-svn: 153979

llvm-svn: 153977

Add VSELECT to LegalizeVectorTypes::ScalariseVectorResult.  Previously it would crash if it encountered a 1 element VSELECT.  Solution is slightly more complicated than just creating a SELET as we have to mask or sign extend the vector condition if it had different boolean contents from the scalar condition.  Fixes <rdar://problem/11178095>

llvm-svn: 153976

llvm-svn: 153975

When folding X == X we need to check getBooleanContents() to determine if the
result is a vector of ones or a vector of negative ones. 

I tried creating a test case, but the problem seems to only be exposed on a
much older version of clang (around r144500).
rdar://10923049

llvm-svn: 153966

might have more than 19 operands. Add a testcase to make sure I
never screw that up again.

Part of rdar://11026482

llvm-svn: 153961

And indirectly, a dependency on most of the core LLVM optimization
libraries.

llvm-svn: 153957

llvm-svn: 153956

llvm-svn: 153951

llvm-svn: 153949

PLT when LLVM is built as shared library. This mimics the X86 backend towards the approach.

llvm-svn: 153938

llvm-svn: 153935