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

llvm-svn: 93283

llvm-svn: 91275

llvm-svn: 90354

llvm-svn: 90337

running tail duplication when doing branch folding for if-conversion, and
we also want to be able to run tail duplication earlier to fix some
reg alloc problems.  Move the CanFallThrough function from BranchFolding
to MachineBasicBlock so that it can be shared by TailDuplication.

llvm-svn: 89904

llvm-svn: 85994

Add aggressive anti-dependence breaker. Currently it is not the default for any target. Enable with -break-anti-dependencies=all.

llvm-svn: 85145

llvm-svn: 85127

llvm-svn: 83500

llvm-svn: 82127

llvm-svn: 82038

llvm-svn: 79802

llvm-svn: 79264

Post RA scheduler changes. Introduce a hazard recognizer that uses the target schedule information to accurately model the pipeline. Update the scheduler to correctly handle multi-issue targets.

llvm-svn: 78563

llvm-svn: 78367

llvm-svn: 78020

llvm-svn: 77709

llvm-svn: 77649

llvm-svn: 74825

llvm-svn: 74720

llvm-svn: 74285

llvm-svn: 73174

llvm-svn: 72785

llvm-svn: 72775

code in preparation for code generation.  The main thing it does
is handle the case when eh.exception calls (and, in a future
patch, eh.selector calls) are far away from landing pads.  Right
now in practice you only find eh.exception calls close to landing
pads: either in a landing pad (the common case) or in a landing
pad successor, due to loop passes shifting them about.  However
future exception handling improvements will result in calls far
from landing pads:
(1) Inlining of rewinds.  Consider the following case:
In function @f:
...
  invoke @g to label %normal unwind label %unwinds
...
unwinds:
  %ex = call i8* @llvm.eh.exception()
...

In function @g:
...
  invoke @something to label %continue unwind label %handler
...
handler:
  %ex = call i8* @llvm.eh.exception()
... perform cleanups ...
  "rethrow exception"

Now inline @g into @f.  Currently this is turned into:
In function @f:
...
  invoke @something to label %continue unwind label %handler
...
handler:
  %ex = call i8* @llvm.eh.exception()
... perform cleanups ...
  invoke "rethrow exception" to label %normal unwind label %unwinds
unwinds:
  %ex = call i8* @llvm.eh.exception()
...

However we would like to simplify invoke of "rethrow exception" into
a branch to the %unwinds label.  Then %unwinds is no longer a landing
pad, and the eh.exception call there is then far away from any landing
pads.

(2) Using the unwind instruction for cleanups.
It would be nice to have codegen handle the following case:
  invoke @something to label %continue unwind label %run_cleanups
...
handler:
... perform cleanups ...
  unwind

This requires turning "unwind" into a library call, which
necessarily takes a pointer to the exception as an argument
(this patch also does this unwind lowering).  But that means
you are using eh.exception again far from a landing pad.

(3) Bugpoint simplifications.  When bugpoint is simplifying
exception handling code it often generates eh.exception calls
far from a landing pad, which then causes codegen to assert.
Bugpoint then latches on to this assertion and loses sight
of the original problem.

Note that it is currently rare for this pass to actually do
anything.  And in fact it normally shouldn't do anything at
all given the code coming out of llvm-gcc!  But it does fire
a few times in the testsuite.  As far as I can see this is
almost always due to the LoopStrengthReduce codegen pass
introducing pointless loop preheader blocks which are landing
pads and only contain a branch to another block.  This other
block contains an eh.exception call.  So probably by tweaking
LoopStrengthReduce a bit this can be avoided.

llvm-svn: 72276