llvm-svn: 125658

llvm-svn: 125651

the right thing and stop trying to copy it. Fixes PR8944.

llvm-svn: 125648

transformation if we can't legally create a build vector of the correct
type. Check that we can make the transformation first, and add a TODO to
refactor this code with similar cases.

Fixes: PR9223 and rdar://9000350
llvm-svn: 125631

llvm-svn: 125629

llvm-svn: 125625

Some single precision VFP instructions may be executed on NEON pipeline, but not double precision ones.

llvm-svn: 125624

This is submitted by Joerg Sonnenberger and fixes his PR8685.

llvm-svn: 125595

This is necessary to avoid a crash in certain tangled situations where a kill
flag is first correctly moved to a merged instruction, and then needs to be
moved again:

  STR %R0, a...
  STR %R0<kill>, b...

First becomes:

  STR %R0, b...
  STM a, %R0<kill>, ...

and then:

  STM a, %R0, ...
  STM b, %R0<kill>, ...

We can now remove the kill flag from the merged STM when needed. 8960050.

llvm-svn: 125591

Ignore DBG_VALUE machine instructions while constructing instruction ranges based on location info. 
Machine instruction range consisting of only DBG_VALUE MIs only contributes consecutive labels in assembly output, which is harmless, and empty scope entry in DebugInfo, which confuses debugger tools.

llvm-svn: 125577

llvm-svn: 125574

llvm-svn: 125571

llvm-svn: 125567

llvm-svn: 125563

Fix 9216 - Endless loop in InstCombine pass.
The pattern "A&(A^B) -> A & ~B" recreated itself because ~B is
actually a xor -1.

llvm-svn: 125557

llvm-svn: 125552

llvm-svn: 125547

llvm-svn: 125546

llvm-svn: 125537

llvm-svn: 125534

Simplify the spill weight calculation a bit by bypassing
getApproximateInstructionCount() and using LiveInterval::getSize() directly.
This changes the computed spill weights, but only by a constant factor in each
function. It should not affect how spill weights compare against each other, and
so it shouldn't affect code generation.

llvm-svn: 125530

Do not hoist @llvm.dbg.value. Here, @llvm.dbg.value is "referring" a value that is modified inside loop.

llvm-svn: 125529

section.

llvm-svn: 125526

Fix PR8854. Track inserted copies to avoid read before write. Sorry, it's hard to reduce a sensible small test case.

llvm-svn: 125523

llvm-svn: 125521

builders unhappy.

llvm-svn: 125504

llvm-svn: 125490

- Add custom operand matching for imod and iflags.
- Rename SplitMnemonicAndCC to SplitMnemonic since it splits more than CC
  from mnemonic.
- While adding ".w" as an operand, don't change "Head" to avoid passing the
  wrong mnemonic to ParseOperand.
- Add asm parser tests.
- Add disassembler tests just to make sure it can catch all cps versions.

llvm-svn: 125489

idiom.  Change various clients to simplify their code.

llvm-svn: 125487

vector fp conversions.

llvm-svn: 125482

llvm-svn: 125481

llvm-svn: 125477

llvm-svn: 125476

have their low bits set to zero.  This allows us to optimize
out explicit stack alignment code like in stack-align.ll:test4 when
it is redundant.

Doing this causes the code generator to start turning FI+cst into
FI|cst all over the place, which is general goodness (that is the
canonical form) except that various pieces of the code generator
don't handle OR aggressively.  Fix this by introducing a new
SelectionDAG::isBaseWithConstantOffset predicate, and using it
in places that are looking for ADD(X,CST).  The ARM backend in
particular was missing a lot of addressing mode folding opportunities
around OR.

llvm-svn: 125470

generating i8 shift amounts for things like i1024 types.  Add
an assert in getNode to prevent this from occuring in the future,
fix the buggy transformation, revert my previous patch, and
document this gotcha in ISDOpcodes.h

llvm-svn: 125465

llvm-svn: 125464

llvm-svn: 125463

plus some variations of this.  According to my auto-simplifier this occurs a lot
but usually in combination with max/min idioms.  Because max/min aren't handled
yet this unfortunately doesn't have much effect in the testsuite.

llvm-svn: 125462

It caused a crash in MultiSource/Benchmarks/Bullet.
Opt hit an assertion with "opt -std-compile-opts" because
Constant::getAllOnesValue doesn't know how to handle floats.

This patch added a test to reproduce the problem and a check that the
destination vector is of integer type.

Thank you Benjamin!

llvm-svn: 125459

the shift amounts are in a suitably wide type so that
we don't generate out of range constant shift amounts.

This fixes PR9028.

llvm-svn: 125458