Change the REG_SEQUENCE SDNode to take an explict register class ID as its first operand.  This operand is lowered away by the time we reach MachineInstrs, so the actual register-allocation handling of them doesn't need to change.
This is intended to support using REG_SEQUENCE SDNode's with type MVT::untyped, and is part of the long road to eliminating some of the hacks we currently use to support register pairs and other strange constraints, particularly on ARM NEON.

llvm-svn: 133178

This avoids the manual filtering of reserved registers and removes the
dependency on allocation_order_begin().

Palliative care...

llvm-svn: 133177

llvm-svn: 133176

llvm-svn: 133175

llvm-svn: 133174

llvm-svn: 133172

llvm-svn: 133171

This virtual function will replace allocation_order_begin/end as the one
to override when implementing custom allocation orders. It is simpler to
have one function return an ArrayRef than having two virtual functions
computing different ends of the same array.

Use getRawAllocationOrder() in place of allocation_order_begin() where
it makes sense, but leave some clients that look like they really want
the filtered allocation orders from RegisterClassInfo.

llvm-svn: 133170

names for named metadata nodes.

llvm-svn: 133166

llvm-svn: 133164

llvm-svn: 133160

considered safe enough in this context.

llvm-svn: 133159

llvm-svn: 133158

Original patch by Syoyo Fujita with more comments by me.

llvm-svn: 133153

compares.

2^30 is actually the limit on the number of physical registers per
TargetRegisterInfo.h.

llvm-svn: 133142

This should unbreak the native ARM testers.

llvm-svn: 133141

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: 133118

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

Add a limit to the number of instructions memdep will scan in a single block.  This prevents (at least in some cases) O(N^2) runtime in passes like DSE.

The limit in this patch is probably too high, but it is enough to stop DSE from going completely insane on a testcase I have (which has a single block with around 50,000 non-aliasing stores in it).

rdar://9471075

llvm-svn: 133111

llvm-svn: 133108

Follow up to r133032.

llvm-svn: 133107

Add a new MVT::untyped.  This will be used in future work for modelling ISA features like register pairs and lists with "interesting" constraints (such as ARM NEON contiguous register lists or even-odd paired registers).  We need to be able to generate these instructions (often from intrinsics), but don't want to have to assign a legal type to them.  Instead, we'll use an "untyped" edge to bypass the type-checking and simply ensure that the register classes match.

llvm-svn: 133106

This simplifies many of the target description files since it is common
for register classes to be related or contain sequences of numbered
registers.

I have verified that this doesn't change the files generated by TableGen
for ARM and X86. It alters the allocation order of MBlaze GPR and Mips
FGR32 registers, but I believe the change is benign.

llvm-svn: 133105

Patch by Argyrios Kyrtzidis.

llvm-svn: 133093

llvm-svn: 133089

llvm-svn: 133086

llvm-svn: 133085

llvm-svn: 133083

llvm-svn: 133081

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: 133078