Turn them into noop KILL instructions instead. This lets the scavenger know when
super-registers are killed and defined.

llvm-svn: 128645

llvm-svn: 128643

This way, shrinkToUses() will ignore the instruction that is about to be
deleted, and we avoid leaving invalid live ranges that SplitKit doesn't like.

Fix a misunderstanding in MachineVerifier about <def,undef> operands. The
<undef> flag is valid on def operands where it has the same meaning as <undef>
on a use operand. It only applies to sub-register defines which also read the
full register.

llvm-svn: 128642

llvm-svn: 128639

llvm-svn: 128634

We don't expect the real "powf()" on some hosts (and powf() would be available on other hosts).
For consistency, std::pow(double,double) may be called instead.
Or, precision issue might attack us, to see unstable regalloc and stack coloring.

llvm-svn: 128629

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

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

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

llvm-svn: 128537

llvm-svn: 128535

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

The spill weight is not recomputed for an unspillable register - it stays infinite.

llvm-svn: 128490

llvm-svn: 128469

This may eliminate some uses of the spilled registers, and we don't want to
insert reloads for that.

llvm-svn: 128468

llvm-svn: 128465

the FailBB dominator is correctly calculated. Believe it or not, there isn't a
functionality change here.

llvm-svn: 128455

dominator information.

llvm-svn: 128452

llvm-svn: 128450

The instruction to be rematerialized may not be the one defining the register
that is being spilled. The traceSiblingValue() function sees through sibling
copies to find the remat candidate.

llvm-svn: 128449

becomes reachable when before it wasn't). Check to make sure that it's not null
before trying to use it.

llvm-svn: 128434

integrated-as.

llvm-svn: 128431

llvm-svn: 128398

The reassignment phase was able to move interference with a higher spill weight,
but it didn't happen very often and it was fairly expensive.

The existing interference eviction picks up the slack.

llvm-svn: 128397

The main register class may have been inflated by live range splitting, so that
register class is not necessarily valid for the snippet instructions.

Use the original register class for the stack slot interval.

llvm-svn: 128351

It couldn't be used outside of the file because SDISelAsmOperandInfo
is local to SelectionDAGBuilder.cpp. Making it a static function avoids
a weird linkage dance.

llvm-svn: 128342

Correctly terminate the range of register DBG_VALUEs when the register is
clobbered or when the basic block ends.

The code is now ready to deal with variables that are sometimes in a register
and sometimes on the stack. We just need to teach emitDebugLoc to say 'stack
slot'.

llvm-svn: 128327

The .dot directives don't need labels, that is a leftover from when we created
line number info manually.

Instructions following a DBG_VALUE can share its label since the DBG_VALUE
doesn't produce any code.

llvm-svn: 128284

Yet another case of unchecked NULL node (for physreg copy).
May fix PR9509.

llvm-svn: 128266

printing a single character.

llvm-svn: 128256

Add an assertion to linear scan to prevent it from allocating registers outside
the register class.

<rdar://problem/9183021>

llvm-svn: 128254

A better approach would be to move source id handling inside MC.

llvm-svn: 128233

Also cleaning up some duplicated code while I'm here.

llvm-svn: 128176

so the scheduler can't create new interferences on the copies
themselves. Prior to this fix the scheduler could get stuck in a loop
creating copies.
Fixes PR9509.

llvm-svn: 128164

llvm-svn: 128163

Each of these instructions may have a RegsClobberInsn entry that can't be
ignored. Consecutive ranges are coalesced later when DwarfDebug::emitDebugLoc
merges entries.

llvm-svn: 128155

The register allocator needs to know when the range shrinks.

llvm-svn: 128145

Empty ranges may represent undef values.

llvm-svn: 128144

llvm-svn: 128143