The main advantages here are way better heuristics, taking into account not
just loop depth but also __builtin_expect and other static heuristics and will
eventually learn how to use profile info. Most of the work in this patch is
pushing the MachineBlockFrequencyInfo analysis into the right places.

This is good for a 5% speedup on zlib's deflate (x86_64), there were some very
unfortunate spilling decisions in its hottest loop in longest_match(). Other
benchmarks I tried were mostly neutral.

This changes register allocation in subtle ways, update the tests for it.
2012-02-20-MachineCPBug.ll was deleted as it's very fragile and the instruction
it looked for was gone already (but the FileCheck pattern picked up unrelated
stuff).

llvm-svn: 184105

llvm-svn: 177356

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.

Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]

llvm-svn: 169131

No functional change, just moved header files.

Targets can inject custom passes between register allocation and
rewriting. This makes it possible to tweak the register allocation
before rewriting, using the full global interference checking available
from LiveRegMatrix.

llvm-svn: 168806

PR14098 contains an example where we would rematerialize a MOV8ri
immediately after the original instruction:

  %vreg7:sub_8bit<def> = MOV8ri 9; GR32_ABCD:%vreg7
  %vreg22:sub_8bit<def> = MOV8ri 9; GR32_ABCD:%vreg7

Besides being pointless, it is also wrong since the original instruction
only redefines part of the register, and the value read by the new
instruction is wrong.

The problem was the LiveRangeEdit::allUsesAvailableAt() didn't
special-case OrigIdx == UseIdx and found the wrong SSA value.

llvm-svn: 166068

All callers can simply use the corresponding MRI functions.

llvm-svn: 165985

Fixes PR13943.

llvm-svn: 164778

LiveRangeEdit::eliminateDeadDefs() can delete a dead instruction that
reads unreserved physregs. This would leave the corresponding regunit
live interval dangling because we don't have shrinkToUses() for physical
registers.

Fix this problem by turning the instruction into a KILL instead of
deleting it. This happens in a landing pad in
test/CodeGen/X86/2012-05-19-CoalescerCrash.ll:

  %vreg27<def,dead> = COPY %EDX<kill>; GR32:%vreg27

becomes:

  KILL %EDX<kill>

An upcoming fix to the machine verifier will catch problems like this by
verifying regunit live intervals.

This fixes PR13498. I am not including the test case from the PR since
we already have one exposing the problem once the verifier is fixed.

llvm-svn: 161182

LiveRangeEdit::foldAsLoad() can eliminate a register by folding a load
into its only use. Only do that when the load is safe to move, and it
won't extend any live ranges.

This fixes PR13414.

llvm-svn: 160575

Don't depend on LiveIntervals::hasInterval() to determine if a physreg
is reserved and constant.

llvm-svn: 159013

Also make sure registers aren't erased twice if the dead def mentions
the register twice.

This fixes PR12911.

llvm-svn: 157254

Dead code elimination during coalescing could cause a virtual register
to be split into connected components. The following rewriting would be
confused about the already joined copies present in the code, but
without a corresponding value number in the live range.

Erase all joined copies instantly when joining intervals such that the
MI and LiveInterval representations are always in sync.

llvm-svn: 157135

The dead code elimination with callbacks is still useful.

llvm-svn: 157100

No functional change.

llvm-svn: 157079

llvm-svn: 153975

Fixes to r153903.  Added missing explanation of behaviour when the VirtRegMap is NULL.  Also changed it in this case to just avoid updating the map, but live ranges or intervals will still get updated and created

llvm-svn: 153914

llvm-svn: 153906

Refactored the LiveRangeEdit interface so that MachineFunction, TargetInstrInfo, MachineRegisterInfo, LiveIntervals, and VirtRegMap are all passed into the constructor and stored as members instead of passed in to each method.

llvm-svn: 153903

methods are no longer needed now that LinearScan has gone away.

(Contains tweaks trivialSpillEverywhere to enable the removal of getNewVRegs).

llvm-svn: 151658

llvm-svn: 150820

llvm-svn: 146960

If we create new intervals for a variable that is being spilled, then those new intervals are not guaranteed to also spill.  This means that anything reading from the original spilling value might not get the correct value if spills were missed.

Fixes <rdar://problem/10546864>

llvm-svn: 146428

generator to it. For non-bundle instructions, these behave exactly the same
as the MC layer API.

For properties like mayLoad / mayStore, look into the bundle and if any of the
bundled instructions has the property it would return true.
For properties like isPredicable, only return true if *all* of the bundled
instructions have the property.
For properties like canFoldAsLoad, isCompare, conservatively return false for
bundles.

llvm-svn: 146026

The old naming scheme (load/use/def/store) can be traced back to an old
linear scan article, but the names don't match how slots are actually
used.

The load and store slots are not needed after the deferred spill code
insertion framework was deleted.

The use and def slots don't make any sense because we are using
half-open intervals as is customary in C code, but the names suggest
closed intervals.  In reality, these slots were used to distinguish
early-clobber defs from normal defs.

The new naming scheme also has 4 slots, but the names match how the
slots are really used.  This is a purely mechanical renaming, but some
of the code makes a lot more sense now.

llvm-svn: 144503

This function doesn't have anything to do with spill weights, and MRI
already has functions for manipulating the register class of a virtual
register.

llvm-svn: 137123

Remat during spilling triggers dead code elimination. If a phi-def
becomes unused, that may also cause live ranges to split into separate
connected components.

This type of splitting is different from normal live range splitting. In
particular, there may not be a common original interval.

When the split range is its own original, make sure that the new
siblings are also their own originals. The range being split cannot be
used as an original since it doesn't cover the new siblings.

llvm-svn: 134413

llvm-svn: 130931

When an interfering live range ends at a dead slot index between two
instructions, make sure that the inserted copy instruction gets a slot index
after the dead ones. This makes it possible to avoid the interference.

Ideally, there shouldn't be interference ending at a deleted instruction, but
physical register coalescing can sometimes do that to sub-registers.

This fixes PR9823.

llvm-svn: 130687

llvm-svn: 129883

llvm-svn: 129579

In particular, don't repeatedly recompute the PIC base live range after rematerialization.

llvm-svn: 129275

When dead code elimination removes all but one use, try to fold the single def into the remaining use.

Rematerialization can leave single-use loads behind that we might as well fold whenever possible.

llvm-svn: 128918

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

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

llvm-svn: 128490

llvm-svn: 128469

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

The register allocator needs to know when the range shrinks.

llvm-svn: 128145

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

llvm-svn: 127773