|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | The primary advantage is that loop optimizations will be applied in a
stable order. This helps debugging and unit test creation. It is also
a better overall implementation without pathologically bad performance
on deep functions.
On large functions (llvm-stress --size=200000 | opt -loops)
Before: 0.1263s
After:  0.0225s
On deep functions (after tweaking llvm-stress, thanks Nadav):
Before: 0.2281s
After:  0.0227s
See r158790 for more comments.
The loop tree is now consistently generated in forward order, but loop
passes are applied in reverse order over the program. If we have a
loop optimization that prefers forward order, that can easily be
achieved by adding a different type of LoopPassManager.
llvm-svn: 159183 | 
| | 
| 
| 
| 
| 
| 
| | the PassManager annoying and should be reimplemented as a decorator
on top of existing passes (as should the timing data).
llvm-svn: 153305 | 
| | 
| 
| 
| 
| 
| | Patch by Xiaoyi Guo!
llvm-svn: 138737 | 
| | 
| 
| 
| | llvm-svn: 138701 | 
| | 
| 
| 
| 
| 
| | Patch by Xiaoyi Guo!
llvm-svn: 138695 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | An algorithm for incrementally updating LoopInfo within a
LoopPassManager. The incremental update should be extremely cheap in
most cases and can be used in places where it's not feasible to
regenerate the entire loop forest.
- "Unloop" is a node in the loop tree whose last backedge has been removed.
- Perform reverse dataflow on the block inside Unloop to propagate the
  nearest loop from the block's successors.
- For reducible CFG, each block in unloop is visited exactly
  once. This is because unloop no longer has a backedge and blocks
  within subloops don't change parents.
- Immediate subloops are summarized by the nearest loop reachable from
  their exits or exits within nested subloops.
- At completion the unloop blocks each have a new parent loop, and
  each immediate subloop has a new parent.
llvm-svn: 137276 | 
| | 
| 
| 
| | llvm-svn: 136857 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | LoopPassManager. The incremental update should be extremely cheap in
most cases and can be used in places where it's not feasible to
regenerate the entire loop forest.
- "Unloop" is a node in the loop tree whose last backedge has been removed.
- Perform reverse dataflow on the block inside Unloop to propagate the
  nearest loop from the block's successors.
- For reducible CFG, each block in unloop is visited exactly
  once. This is because unloop no longer has a backedge and blocks
  within subloops don't change parents.
- Immediate subloops are summarized by the nearest loop reachable from
  their exits or exits within nested subloops.
- At completion the unloop blocks each have a new parent loop, and
  each immediate subloop has a new parent.
llvm-svn: 136844 | 
| | 
| 
| 
| | llvm-svn: 136843 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | treating debugging information.
It generates output that lools like
8 times line number info lost by Scalar Replacement of Aggregates (SSAUp) 
1 times line number info lost by Simplify well-known library calls 
12 times variable info lost by Jump Threading
llvm-svn: 127381 | 
| | 
| 
| 
| | llvm-svn: 113073 | 
| | 
| 
| 
| | llvm-svn: 111500 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | a Pass abstraction, since that's the level it's actually used at.
Rename Pass' dumpPassStructure to dumpPass.
This eliminates an awkward use of getAsPass() to convert a PMDataManager*
into a Pass* just to permit a dumpPassStructure call.
llvm-svn: 111199 | 
| | 
| 
| 
| 
| 
| | and remove casts from all its callers.
llvm-svn: 110848 | 
| | 
| 
| 
| | llvm-svn: 110460 | 
| | 
| 
| 
| | llvm-svn: 110410 | 
| | 
| 
| 
| 
| 
| 
| 
| | address of the static
ID member as the sole unique type identifier.  Clean up APIs related to this change.
llvm-svn: 110396 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | 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 | 
| | 
| 
| 
| 
| 
| | are run during codegen.
llvm-svn: 100207 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | <string> include.  For some reason the buildbot choked on this while my
builds did not.  It's probably due to a difference in system headers.
---
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: 100204 | 
| | 
| 
| 
| | llvm-svn: 100146 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | -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: 100143 | 
| | 
| 
| 
| | llvm-svn: 100011 | 
| | 
| 
| 
| 
| 
| | timers by pointer instead of by-value.
llvm-svn: 99871 | 
| | 
| 
| 
| | llvm-svn: 99870 | 
| | 
| 
| 
| | llvm-svn: 99862 | 
| | 
| 
| 
| | llvm-svn: 94156 | 
| | 
| 
| 
| | llvm-svn: 82994 | 
| | 
| 
| 
| | llvm-svn: 82993 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | the PassManager code into a regular verifyAnalysis method.
Also, reorganize loop verification. Make the LoopPass infrastructure
call verifyLoop as needed instead of having LoopInfo::verifyAnalysis
check every loop in the function after each looop pass. Add a new
command-line argument, -verify-loop-info, to enable the expensive
full checking.
llvm-svn: 82952 | 
| | 
| 
| 
| | llvm-svn: 82951 | 
| | 
| 
| 
| 
| 
| 
| 
| | code that stops the timer doesn't have to search to find the timer
object before it stops the timer. This avoids a lock acquisition
and a few other things done with the timer running.
llvm-svn: 82949 | 
| | 
| 
| 
| | llvm-svn: 82947 | 
| | 
| 
| 
| 
| 
| | a separate function.
llvm-svn: 82946 | 
| | 
| 
| 
| 
| 
| 
| 
| | LoopPasses for that loop. This avoids trouble with the PassManager
trying to call verifyAnalysis on them, and frees up some memory
sooner rather than later.
llvm-svn: 82945 | 
| | 
| 
| 
| | llvm-svn: 82908 | 
| | 
| 
| 
| | llvm-svn: 80919 | 
| | 
| 
| 
| | llvm-svn: 79836 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | on-the-fly passes as well.
Also don't call finalizers for LoopPass if initialization was not called.
Add a unittest that tests that these methods are called, in the proper
order, and the correct number of times.
llvm-svn: 74438 | 
| | 
| 
| 
| 
| 
| | analysis values, related to the instructions in the basic block.
llvm-svn: 67719 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | get nice and happy stack traces when we crash in an optimizer or codegen.  For
example, an abort put in UnswitchLoops now looks like this:
Stack dump:
0.	Program arguments: clang pr3399.c -S -O3 
1.	<eof> parser at end of file
2.	per-module optimization passes
3.	Running pass 'CallGraph Pass Manager' on module 'pr3399.c'.
4.	Running pass 'Loop Pass Manager' on function '@foo'
5.	Running pass 'Unswitch loops' on basic block '%for.inc'
Abort
llvm-svn: 66260 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | modified in a way that may effect the trip count calculation. Change
IndVars to use this method when it rewrites pointer or floating-point
induction variables instead of using a doInitialization method to
sneak these changes in before ScalarEvolution has a chance to see
the loop. This eliminates the need for LoopPass to depend on
ScalarEvolution.
llvm-svn: 64810 | 
| | 
| 
| 
| | llvm-svn: 64796 | 
| | 
| 
| 
| | llvm-svn: 55779 | 
| | 
| 
| 
| 
| 
| | up the passmgr by avoiding useless work.
llvm-svn: 54528 | 
| | 
| 
| 
| | llvm-svn: 53489 | 
| | 
| 
| 
| | llvm-svn: 53088 | 
| | 
| 
| 
| 
| 
| | Thanks for the feedback!
llvm-svn: 52978 | 
| | 
| 
| 
| | llvm-svn: 52967 | 
| | 
| 
| 
| | llvm-svn: 45418 |