llvm-svn: 133205

Reviewed by chapuni. Sorry for breaking.

llvm-svn: 133200

llvm-svn: 133189

than trying to insert them immediately after the invoke.

llvm-svn: 133188

llvm-svn: 133176

llvm-svn: 133172

names for named metadata nodes.

llvm-svn: 133166

Original patch by Syoyo Fujita with more comments by me.

llvm-svn: 133153

llvm-svn: 133139

llvm-svn: 133134

llvm-svn: 133133

llvm-svn: 133132

REQUIRES: Asserts
REQUIRES: Debug

This required chaining test configuration properties. It seems like a
generally good thing to do.

llvm-svn: 133131

llvm-svn: 133128

accumulator forwarding.  Specifically (from SVN log entry):

Distribute (A + B) * C to (A * C) + (B * C) to make use of NEON multiplier
accumulator forwarding:
vadd d3, d0, d1
vmul d3, d3, d2
=>
vmul d3, d0, d2
vmla d3, d1, d2

Make sure it catches cases where operand 1 is add/fadd/sub/fsub, which was
intended in the original revision.

llvm-svn: 133127

llvm-svn: 133124

llvm-svn: 133115

Function::getNumBlockIDs() should be used instead of Function::size() to set the upper limit on the block IDs since basic blocks might get removed (simplified away) after being initially numbered. Plus the test case, in which SelectionDAGBuilder::visitBr() calls llvm::MachineFunction::removeFromMBBNumbering(), which introduces the hole in numbering leading to an assert in llc (prior to the fix).

llvm-svn: 133113

llvm-svn: 133108

llvm-svn: 133089

optimizations when emitting calls to the function;  instead those calls may
use faster relocations which require the function to be immediately resolved
upon loading the dynamic object featuring the call.  This is useful when it
is known that the function will be called frequently and pervasively and
therefore there is no merit in delaying binding of the function.

Currently only implemented for x86-64, where it turns into a call through
the global offset table.

Patch by Dan Gohman, who assures me that he's going to add LangRef documentation
for this once it's committed.

llvm-svn: 133080

llvm-svn: 133068

Note that this actually changes code generation, and someone who
understands this target better should check the changes.

- R12Q is now allocatable. I think it was omitted from the allocation
  order by mistake since it isn't reserved. It as apparently used as a
  GOT pointer sometimes, and it should probably be reserved if that is
  the case.

- The GR64 registers are allocated in a different order now. The
  register allocator will automatically put the CSRs last. There were
  other changes to the order that may have been significant.

The test fix is because r0 and r1 swapped places in the allocation order.

llvm-svn: 133067

llvm-svn: 133064

Added a test case for handling physreg aliases during pre-RA-sched.

llvm-svn: 133063

llvm-svn: 133062

specifying that the target CPU is corei7.

llvm-svn: 133053

are also greater than the alias.

llvm-svn: 133038

the bits being cleared by the AND are not demanded by the BFI.

The previous BFI dag combine rule was actually incorrect (or used to be
correct until BFI representation changed).

rdar://9609030

llvm-svn: 133034

Add an optimization that looks for a specific pair-wise add pattern and generates a vpaddl instruction instead of scalarizing the add.
Includes a test case.

llvm-svn: 133027

llvm-svn: 133026

converted to add x,x if x is a undef.  add undef, undef does not guarantee
that the resulting low order bit is zero.
Fixes <rdar://problem/9453156> and <rdar://problem/9487392>.

llvm-svn: 133022

llvm-svn: 133021

llvm-svn: 133014

llvm-svn: 133009

llvm-svn: 133001

llvm-gcc-x86_64-linux-selfhost buildbot and others.

llvm-svn: 133000

llvm-svn: 132995

llvm-svn: 132991

llvm-svn: 132988