The rematerialized instruction may require a more constrained register class
than the register being spilled. In the test case, the spilled register has been
inflated to the DPR register class, but we are rematerializing a load of the
ssub_0 sub-register which only exists for DPR_VFP2 registers.

The register class is reinflated after spilling, so the conservative choice is
only temporary.

llvm-svn: 128610

This revision introduced a dependency cycle, as nlewycky mentioned by email.

llvm-svn: 128597

llvm-svn: 128594

llvm-svn: 128591

Somehow we managed to forget to encode the lane index for a large swathe of NEON instructions.  With this fix, the entire test-suite passes with the Thumb integrated assembler.

llvm-svn: 128587

llvm-svn: 128586

  {STR,LDC}{2}_PRE.
- Fixed the encoding in some places.
- Some of those instructions were using am2offset and now use addrmode2.
Codegen isn't affected, instructions which use SelectAddrMode2Offset were not
touched.
- Teach printAddrMode2Operand to check by the addressing mode which index
mode to print.
- This is a work in progress, more work to come. The idea is to change places
which use am2offset to use addrmode2 instead, as to unify assembly parser.
- Add testcases for assembly parser

llvm-svn: 128585

can be recognized. This fixes <rdar://problem/9183078>.

llvm-svn: 128584

llvm-svn: 128583

  that one of the numbers is signed while the other is unsigned. This could lead
  to a wrong result when the signed was promoted to an unsigned int.

* Add the data layout line to the testcase so that it will test the appropriate
  thing.

Patch by David Terei!

llvm-svn: 128577

llvm-svn: 128574

Prevent infinite growth of the list.

Patch by José Fonseca!

llvm-svn: 128568

StringMap was not properly updating NumTombstones after a clear or rehash.

This was not fatal until now because the table was growing faster than
NumTombstones could, but with the previous change of preventing infinite
growth of the table the invariant (NumItems + NumTombstones <= NumBuckets)
stopped being observed, causing infinite loops in certain situations.

Patch by José Fonseca!

llvm-svn: 128567

Rehash but don't grow when full of tombstones.

Patch by José Fonseca!

llvm-svn: 128566

Rehash but don't grow when full of tombstones.

Patch by José Fonseca!

llvm-svn: 128565

When the hash function uses object pointers all free entries eventually
become tombstones as they are used at least once, regardless of the size.

DenseMap cannot function with zero empty keys, so it double size to get
get ridof the tombstones.

However DenseMap never shrinks automatically unless it is cleared, so
the net result is that certain tables grow infinitely.

The solution is to make a fresh copy of the table without tombstones
instead of doubling size, by simply calling grow with the current size.

Patch by José Fonseca!

llvm-svn: 128564

The rewriter can keep track of multiple stack slots in the same register if they
happen to have the same value. When an instruction modifies a stack slot by
defining a register that is mapped to a stack slot, other stack slots in that
register are no longer valid.

This is a very rare problem, and I don't have a simple test case. I get the
impression that VirtRegRewriter knows it is about to be deleted, inventing a
last opaque problem.

<rdar://problem/9204040>

llvm-svn: 128562

llvm-svn: 128561

Avoid turning a floating point division with a constant power of two into a denormal multiplication.

Some platforms may treat denormals as zero, on other platforms multiplication
with a subnormal is slower than dividing by a normal.

llvm-svn: 128555

Fixes PR9587.

llvm-svn: 128546

The idea is, that if an ieee 754 float is divided by a power of two, we can
turn the division into a cheaper multiplication. This function sees if we can
get an exact multiplicative inverse for a divisor and returns it if possible.

This is the hard part of PR9587.

I tested many inputs against llvm-gcc's frotend implementation of this
optimization and didn't find any difference. However, floating point is the
land of weird edge cases, so any review would be appreciated.

llvm-svn: 128545

llvm-svn: 128543

llvm-svn: 128540

PHINode::Create() giving the (known or expected) number of operands.

llvm-svn: 128537

llvm-svn: 128535

llvm-svn: 128526

When DCE clones a live range because it separates into connected components,
make sure that the clones enter the same register allocator stage as the
register they were cloned from.

For instance, clones may be split even when they where created during spilling.
Other registers created during spilling are not candidates for splitting or even
(re-)spilling.

llvm-svn: 128524

llvm-svn: 128519

llvm-svn: 128517

llvm-svn: 128515

llvm-svn: 128507

llvm-svn: 128506

llvm-svn: 128504

llvm-svn: 128503

was lowering them to sext / uxt + mul instructions. Unfortunately the
optimization passes may hoist the extensions out of the loop and separate them.
When that happens, the long multiplication instructions can be broken into
several scalar instructions, causing significant performance issue.

Note the vmla and vmls intrinsics are not added back. Frontend will codegen them
as intrinsics vmull* + add / sub. Also note the isel optimizations for catching
mul + sext / zext are not changed either.

First part of rdar://8832507, rdar://9203134

llvm-svn: 128502

llvm-svn: 128501

llvm-svn: 128499

llvm-svn: 128497

On x86 we now compile "if (a < 0 && b < 0)" into
	testl	%edi, %esi
	js	IF.THEN

llvm-svn: 128496

llvm-svn: 128495