Release build: guard dump functions with
"#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)"

No functional change. Update r163339.

llvm-svn: 163653

Release build: guard dump functions with "ifndef NDEBUG"

No functional change.

llvm-svn: 163339

Enable the new LoopInfo algorithm by default.

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 ove

Enable the new LoopInfo algorithm by default.

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

show more ...

A new algorithm for computing LoopInfo. Temporarily disabled.

-stable-loops enables a new algorithm for generating the Loop
forest. It differs from the original algorithm in a few respects:

- Not d

A new algorithm for computing LoopInfo. Temporarily disabled.

-stable-loops enables a new algorithm for generating the Loop
forest. It differs from the original algorithm in a few respects:

- Not determined by use-list order.
- Initially guarantees RPO order of block and subloops.
- Linear in the number of CFG edges.
- Nonrecursive.

I didn't want to change the LoopInfo API yet, so the block lists are
still inclusive. This seems strange to me, and it means that building
LoopInfo is not strictly linear, but it may not be a problem in
practice. At least the block lists start out in RPO order now. In the
future we may add an attribute or wrapper analysis that allows other
passes to assume RPO order.

The primary motivation of this work was not to optimize LoopInfo, but
to allow reproducing performance issues by decomposing the compilation
stages. I'm often unable to do this with the current LoopInfo, because
the loop tree order determines Loop pass order. Serializing the IR
tends to invert the order, which reverses the optimization order. This
makes it nearly impossible to debug interdependent loop optimizations
such as LSR.

I also believe this will provide more stable performance results across time.

llvm-svn: 158790

show more ...

Move the implementation of LoopInfo into LoopInfoImpl.h.

The implementation only needs inclusion from LoopInfo.cpp and
MachineLoopInfo.cpp. Clients of the interface should only include the
interface

Move the implementation of LoopInfo into LoopInfoImpl.h.

The implementation only needs inclusion from LoopInfo.cpp and
MachineLoopInfo.cpp. Clients of the interface should only include the
interface. This makes the interface readable and speeds up rebuilds
after modifying the implementation.

llvm-svn: 158787

show more ...

Begin adding static dependence information to passes, which will allow us to
perform initialization without static constructors AND without explicit initialization
by the client. For the moment, pas

Begin adding static dependence information to passes, which will allow us to
perform initialization without static constructors AND without explicit initialization
by the client. For the moment, passes are required to initialize both their
(potential) dependencies and any passes they preserve. I hope to be able to relax
the latter requirement in the future.

llvm-svn: 116334

show more ...

Now with fewer extraneous semicolons!

llvm-svn: 115996

Now that PassInfo and Pass::ID have been separated, move the rest of the passes over to the new registration API.

llvm-svn: 111815

Reapply r110396, with fixes to appease the Linux buildbot gods.

llvm-svn: 110460

Revert r110396 to fix buildbots.

llvm-svn: 110410

Don't use PassInfo* as a type identifier for passes. Instead, use the address of the static
ID member as the sole unique type identifier. Clean up APIs related to this change.

llvm-svn: 110396

Restore dump() methods to Loop and MachineLoop.

llvm-svn: 92772

Explicit template instantiations must happen in the template's immediately
enclosing namespace. Caught by clang++.

llvm-svn: 91480

improve portability to avoid conflicting with std::next in c++'0x.
Patch by Howard Hinnant!

llvm-svn: 90365

Add getTopBlock and getBottomBlock member functions to MachineLoopInfo.

llvm-svn: 84596

Reapply r77654 with a fix: MachineFunctionPass's getAnalysisUsage
shouldn't do AU.setPreservesCFG(), because even though CodeGen passes
don't modify the LLVM IR CFG, they may modify the MachineFuncti

Reapply r77654 with a fix: MachineFunctionPass's getAnalysisUsage
shouldn't do AU.setPreservesCFG(), because even though CodeGen passes
don't modify the LLVM IR CFG, they may modify the MachineFunction CFG,
and passes like MachineLoop are registered with isCFGOnly set to true.

llvm-svn: 77691

show more ...

Revert r77654, it appears to be causing llvm-gcc bootstrap failures, and many
failures when building assorted projects with clang.

--- Reverse-merging r77654 into '.':
U include/llvm/CodeGen/Pass

Revert r77654, it appears to be causing llvm-gcc bootstrap failures, and many
failures when building assorted projects with clang.

--- Reverse-merging r77654 into '.':
U include/llvm/CodeGen/Passes.h
U include/llvm/CodeGen/MachineFunctionPass.h
U include/llvm/CodeGen/MachineFunction.h
U include/llvm/CodeGen/LazyLiveness.h
U include/llvm/CodeGen/SelectionDAGISel.h
D include/llvm/CodeGen/MachineFunctionAnalysis.h
U include/llvm/Function.h
U lib/Target/CellSPU/SPUISelDAGToDAG.cpp
U lib/Target/PowerPC/PPCISelDAGToDAG.cpp
U lib/CodeGen/LLVMTargetMachine.cpp
U lib/CodeGen/MachineVerifier.cpp
U lib/CodeGen/MachineFunction.cpp
U lib/CodeGen/PrologEpilogInserter.cpp
U lib/CodeGen/MachineLoopInfo.cpp
U lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
D lib/CodeGen/MachineFunctionAnalysis.cpp
D lib/CodeGen/MachineFunctionPass.cpp
U lib/CodeGen/LiveVariables.cpp

llvm-svn: 77661

show more ...

Manage MachineFunctions with an analysis Pass instead of the Annotable
mechanism. To support this, make MachineFunctionPass a little more
complete.

llvm-svn: 77654

Make Loop and MachineLoop be subclasses of LoopBase, rather than typedefs,
using the Curiously Recurring Template Pattern with LoopBase.

This will help further refactoring, and future functionality

Make Loop and MachineLoop be subclasses of LoopBase, rather than typedefs,
using the Curiously Recurring Template Pattern with LoopBase.

This will help further refactoring, and future functionality for
Loop. Also, Headers can now foward-declare Loop, instead of pulling
in LoopInfo.h or doing tricks.

llvm-svn: 75519

show more ...

Eliminate a layer of indirection in LoopInfo and MachineLoopInfo.

llvm-svn: 74394

Change class' public PassInfo variables to by initialized with the
address of the PassInfo directly instead of calling getPassInfo.
This eliminates a bunch of dynamic initializations of static data.

Change class' public PassInfo variables to by initialized with the
address of the PassInfo directly instead of calling getPassInfo.
This eliminates a bunch of dynamic initializations of static data.

Also, fold RegisterPassBase into PassInfo, make a bunch of its
data members const, and rearrange some code to initialize data
members in constructors instead of using setter member functions.

llvm-svn: 51022

show more ...

Clean up the use of static and anonymous namespaces. This turned up
several things that were neither in an anonymous namespace nor static
but not intended to be global.

llvm-svn: 51017

Remove uses of llvm/System/IncludeFile.h that are no longer needed.

llvm-svn: 50695

make this build with newer gcc's

llvm-svn: 45637

Don't recalculate the loop info and loop dominators analyses if they're
preserved.

llvm-svn: 45596