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

I have convinced myself that it can only happen when a phi value dies. When it
happens, allocate new virtual registers for the components.

llvm-svn: 127827

The register allocator needs to adjust its live interval unions when that happens.

llvm-svn: 127774

This allows the allocator to free any resources used by the virtual register,
including physical register assignments.

llvm-svn: 127560

This makes it possible to register delegates and get callbacks when the spiller
edits live ranges.

llvm-svn: 127389

llvm-svn: 127311

This will we used for keeping register allocator data structures up to date
while LiveRangeEdit is trimming live intervals.

llvm-svn: 127300

LiveRangeEdit::eliminateDeadDefs() will eventually be used by coalescing,
splitting, and spilling for dead code elimination. It can delete chains of dead
instructions as long as there are no dependency loops.

llvm-svn: 127287

llvm-svn: 127181

Values that map to a single new value in a new interval after splitting don't
need new PHIDefs, and if the parent value was never rematerialized the live
range will be the same.

llvm-svn: 126894

llvm-svn: 126002

All new virtual registers created for spilling or splitting point back to their original.

llvm-svn: 125980

llvm-svn: 124779

llvm-svn: 124778

The greedy register allocator revealed some problems with the value mapping in
SplitKit. We would sometimes start mapping values before all defs were known,
and that could change a value from a simple 1-1 mapping to a multi-def mapping
that requires ssa update.

The new approach collects all defs and register assignments first without
filling in any live intervals. Only when finish() is called, do we compute
liveness and mapped values. At this time we know with certainty which values map
to multiple values in a split range.

This also has the advantage that we can compute live ranges based on the
remaining uses after rematerializing at split points.

The current implementation has many opportunities for compile time optimization.

llvm-svn: 124765

use before rematerializing the load.

This allows us to produce:

    addps	LCPI0_1(%rip), %xmm2

Instead of:

    movaps	LCPI0_1(%rip), %xmm3
    addps	%xmm3, %xmm2

Saving a register and an instruction. The standard spiller already knows how to
do this.

llvm-svn: 122133

llvm-svn: 118661

give them individual stack slots once the are actually spilled.

llvm-svn: 117945

llvm-svn: 117677

the remainder register.

Example:

bb0:
  x = 1
bb1:
  use(x)
  ...
  x = 2
  jump bb1

When x is isolated in bb1, the inner part breaks into two components, x1 and x2:

bb0:
  x0 = 1
bb1:
  x1 = x0
  use(x1)
  ...
  x2 = 2
  x0 = x2
  jump bb1

llvm-svn: 117408

llvm-svn: 116951

All registers created during splitting or spilling are assigned to the same
stack slot as the parent register.

When splitting or rematting, we may not spill at all. In that case the stack
slot is still assigned, but it will be dead.

llvm-svn: 116546

splitting or spillling, and to help with rematerialization.

Use LiveRangeEdit in InlineSpiller and SplitKit. This will eventually make it
possible to share remat code between InlineSpiller and SplitKit.

llvm-svn: 116543