llvm-svn: 125968

llvm-svn: 123129

This pass precomputes CFG block frequency information that can be used by the
register allocator to find optimal spill code placement.

Given an interference pattern, placeSpills() will compute which basic blocks
should have the current variable enter or exit in a register, and which blocks
prefer the stack.

The algorithm is ready to consume block frequencies from profiling data, but for
now it gets by with the static estimates used for spill weights.

This is a work in progress and still not hooked up to RegAllocGreedy.

llvm-svn: 122938

The analysis will be needed by both the greedy register allocator and the
X86FloatingPoint pass. It only needs to be computed once when the CFG doesn't
change.

This pass is very fast, usually showing up as 0.0% wall time.

llvm-svn: 122832

A MachineLoopRange contains the intervals of slot indexes covered by the blocks
in a loop. This representation of the loop blocks is more efficient to compare
against interfering registers during register coalescing.

llvm-svn: 121917

registers for a given virtual register.

Reserved registers are filtered from the allocation order, and any valid hint is
returned as the first suggestion.

For target dependent hints, a number of arcane target hooks are invoked.

llvm-svn: 121497

both forward and backward scheduling. Rename it to
ScoreboardHazardRecognizer (Scoreboard is one word). Remove integer
division from the scoreboard's critical path.

llvm-svn: 121274

This new register allocator is initially identical to RegAllocBasic, but it will
receive all of the tricks that RegAllocBasic won't get.

RegAllocGreedy will eventually replace linear scan.

llvm-svn: 121234

function so that it can be shared with StrongPHIElimination.

llvm-svn: 120951

This analysis is going to run immediately after LiveIntervals. It will stay
alive during register allocation and keep track of user variables mentioned in
DBG_VALUE instructions.

When the register allocator is moving values between registers and the stack, it
is very hard to keep track of DBG_VALUE instructions. We usually get it wrong.
This analysis maintains a data structure that makes it easy to update DBG_VALUE
instructions.

llvm-svn: 120385

llvm-svn: 119716

llvm-svn: 119385

framework. It's purpose is not to improve register allocation per se,
but to make it easier to develop powerful live range splitting. I call
it the basic allocator because it is as simple as a global allocator
can be but provides the building blocks for sophisticated register
allocation with live range splitting. 

A minimal implementation is provided that trivially spills whenever it
runs out of registers. I'm checking in now to get high-level design
and style feedback. I've only done minimal testing. The next step is
implementing a "greedy" allocation algorithm that does some register
reassignment and makes better splitting decisions.

llvm-svn: 117174

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

llvm-svn: 115949

llvm-svn: 114999

This reverts commit r113632

Conflicts:

	cmake/modules/AddLLVM.cmake

llvm-svn: 113819

llvm-svn: 113632

llvm-svn: 111063

experimental pass that allocates locals relative to one another before
register allocation and then assigns them to actual stack slots as a block
later in PEI. This will eventually allow targets with limited index offset
range to allocate additional base registers (not just FP and SP) to
more efficiently reference locals, as well as handle situations where
locals cannot be referenced via SP or FP at all (dynamic stack realignment
together with variable sized objects, for example). It's currently
incomplete and almost certainly buggy. Work in progress.

Disabled by default and gated via the -enable-local-stack-alloc command
line option.

rdar://8277890

llvm-svn: 111059

llvm-svn: 110654

llvm-svn: 110429

This is a work in progress. So far we have some basic loop analysis to help
determine where it is useful to split a live range around a loop.

The actual loop splitting code from Splitter.cpp is also going to move in here.

llvm-svn: 108842

llvm-svn: 108700

llvm-svn: 108620

llvm-svn: 107781

InlineSpiller inserts loads and spills immediately instead of deferring to
VirtRegMap. This is possible now because SlotIndexes allows instructions to be
inserted and renumbered.

This is work in progress, and is mostly a copy of TrivialSpiller so far. It
works very well for functions that don't require spilling.

llvm-svn: 107227

Please use the fast allocator instead.

llvm-svn: 106051

llvm-svn: 105987

So far this is just a clone of -regalloc=local that has been lobotomized to run
25% faster. It drops the least-recently-used calculations, and is just plain
stupid when it runs out of registers.

The plan is to make this go even faster for -O0 by taking advantage of the short
live intervals in unoptimized code. It should not be necessary to calculate
liveness when most virtual registers are killed 2-3 instructions after they are
born.

llvm-svn: 102006

llvm-svn: 101976

Ok, third time's the charm.  No changes from last time except the CMake
source addition.  Apparently the buildbots were wrong about failures.

---

Add some switches helpful for debugging:

-print-before=<Pass Name>

Dump IR before running pass <Pass Name>.

-print-before-all

Dump IR before running each pass.

-print-after-all

Dump IR after running each pass.

These are helpful when tracking down a miscompilation.  It is easy to
get IR dumps and do diffs on them, etc.

To make this work well, add a new getPrinterPass API to Pass so that
each kind of pass (ModulePass, FunctionPass, etc.) can create a Pass
suitable for dumping out the kind of object the Pass works on.

llvm-svn: 100249

llvm-svn: 100222

llvm-svn: 100206

llvm-svn: 97545

llvm-svn: 96292

reduce down to a single value.  InstCombine already does this transformation
but DAG legalization may introduce new opportunities.  This has turned out to
be important for ARM where 64-bit values are split up during type legalization:
InstCombine is not able to remove the PHI cycles on the 64-bit values but
the separate 32-bit values can be optimized.  I measured the compile time 
impact of this (running llc on 176.gcc) and it was not significant.

llvm-svn: 95951

llvm-svn: 95041

llvm-svn: 93905

llvm-svn: 93571