llvm-6502/lib/Analysis/IPA/CallGraphSCCPass.cpp

610 lines
22 KiB
C++
Raw Normal View History

//===- CallGraphSCCPass.cpp - Pass that operates BU on call graph ---------===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// This file implements the CallGraphSCCPass class, which is used for passes
// which are implemented as bottom-up traversals on the call graph. Because
// there may be cycles in the call graph, passes of this type operate on the
// call-graph in SCC order: that is, they process function bottom-up, except for
// recursive functions, which they process all at once.
//
//===----------------------------------------------------------------------===//
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
#define DEBUG_TYPE "cgscc-passmgr"
#include "llvm/CallGraphSCCPass.h"
#include "llvm/IntrinsicInst.h"
#include "llvm/Function.h"
#include "llvm/PassManagers.h"
#include "llvm/Analysis/CallGraph.h"
#include "llvm/ADT/SCCIterator.h"
#include "llvm/ADT/Statistic.h"
#include "llvm/Support/CommandLine.h"
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
#include "llvm/Support/Debug.h"
#include "llvm/Support/Timer.h"
#include "llvm/Support/raw_ostream.h"
using namespace llvm;
static cl::opt<unsigned>
Implement rdar://6295824 and PR6724 with two tiny changes that can have a big effect :). The first is to enable the iterative SCC passmanager juice that kicks in when the scc passmgr detects that a function pass has devirtualized a call. In this case, it will rerun all the passes it manages on the SCC, up to the iteration count limit (4). This is useful because a function pass may devirualize a call, and we want the inliner to inline it, or pruneeh to infer stuff about it, etc. The second patch is to add *all* call sites to the DevirtualizedCalls list the inliner uses. This list is about to get renamed, but the jist of this is that the inliner now reconsiders *all* inlined call sites as candidates for further inlining. The intuition is this that in cases like this: f() { g(1); } g(int x) { h(x); } We analyze this bottom up, and may decide that it isn't profitable to inline H into G. Next step, we decide that it is profitable to inline G into F, and do so, which means that F now calls H. Even though the call from G -> H may not have been profitable to inline, the call from F -> H may be (in this case because a constant allows folding etc). In my spot checks, this doesn't have a big impact on code. For example, the LLC output for 252.eon grew from 0.02% (from 317252 to 317308) and 176.gcc actually shrunk by .3% (from 1525612 to 1520964 bytes). 252.eon never iterated in the SCC Passmgr, 176.gcc iterated at most 1 time. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102823 91177308-0d34-0410-b5e6-96231b3b80d8
2010-05-01 01:15:56 +00:00
MaxIterations("max-cg-scc-iterations", cl::ReallyHidden, cl::init(4));
STATISTIC(MaxSCCIterations, "Maximum CGSCCPassMgr iterations on one SCC");
//===----------------------------------------------------------------------===//
// CGPassManager
//
/// CGPassManager manages FPPassManagers and CallGraphSCCPasses.
namespace {
class CGPassManager : public ModulePass, public PMDataManager {
public:
static char ID;
explicit CGPassManager(int Depth)
: ModulePass(&ID), PMDataManager(Depth) { }
/// run - Execute all of the passes scheduled for execution. Keep track of
/// whether any of the passes modifies the module, and if so, return true.
bool runOnModule(Module &M);
Revert r64300 and r64301. These were causing the following errors respectively: During llvm-gcc bootstrap: Undefined symbols: "llvm::FPPassManager::doFinalization(llvm::Module&)", referenced from: (anonymous namespace)::CGPassManager::doFinalization(llvm::CallGraph&, llvm::Module&) in libLLVMipa.a(CallGraphSCCPass.o) "llvm::FPPassManager::doInitialization(llvm::Module&)", referenced from: (anonymous namespace)::CGPassManager::doInitialization(llvm::CallGraph&, llvm::Module&) in libLLVMipa.a(CallGraphSCCPass.o) ld: symbol(s) not found collect2: ld returned 1 exit status make[3]: *** [/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore.roots/llvmCore~obj/obj-llvm/Release/bin/opt] Error 1 During an LLVM release build: /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/Release/bin/tblgen -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86 -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target -gen-register-desc -o /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Target/X86/Release/X86GenRegisterInfo.inc.tmp /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86/X86.td llvm[3]: Building X86.td instruction names with tblgen /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/Release/bin/tblgen -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86 -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target -gen-instr-enums -o /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Target/X86/Release/X86GenInstrNames.inc.tmp /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86/X86.td llvm[3]: Building X86.td instruction information with tblgen /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/Release/bin/tblgen -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86 -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target -gen-instr-desc -o /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Target/X86/Release/X86GenInstrInfo.inc.tmp /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86/X86.td llvm[3]: Building X86.td assembly writer with tblgen /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/Release/bin/tblgen -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86 -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target -gen-asm-writer -o /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Target/X86/Release/X86GenAsmWriter.inc.tmp /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86/X86.td llvm[3]: Compiling InstructionCombining.cpp for Release build if /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmgcc42.roots/llvmgcc42~dst/Developer/usr/bin/llvm-g++-4.2 -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/include -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Transforms/Scalar -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O3 -fno-exceptions -Woverloaded-virtual -pedantic -Wall -W -Wwrite-strings -Wno-long-long -Wunused -Wno-unused-parameter -fstrict-aliasing -Wstrict-aliasing -c -MMD -MP -MF "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.d.tmp" -MT "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.lo" -MT "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.o" -MT "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.d" /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Transforms/Scalar/InstructionCombining.cpp -o /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.o ; \ then /bin/mv -f "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.d.tmp" "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Trans git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@64311 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-11 18:19:24 +00:00
bool doInitialization(CallGraph &CG);
bool doFinalization(CallGraph &CG);
/// Pass Manager itself does not invalidate any analysis info.
void getAnalysisUsage(AnalysisUsage &Info) const {
// CGPassManager walks SCC and it needs CallGraph.
Info.addRequired<CallGraph>();
Info.setPreservesAll();
}
virtual const char *getPassName() const {
return "CallGraph Pass Manager";
}
virtual PMDataManager *getAsPMDataManager() { return this; }
virtual Pass *getAsPass() { return this; }
// Print passes managed by this manager
void dumpPassStructure(unsigned Offset) {
errs().indent(Offset*2) << "Call Graph SCC Pass Manager\n";
for (unsigned Index = 0; Index < getNumContainedPasses(); ++Index) {
Pass *P = getContainedPass(Index);
P->dumpPassStructure(Offset + 1);
dumpLastUses(P, Offset+1);
}
}
Pass *getContainedPass(unsigned N) {
assert(N < PassVector.size() && "Pass number out of range!");
return static_cast<Pass *>(PassVector[N]);
}
virtual PassManagerType getPassManagerType() const {
return PMT_CallGraphPassManager;
}
private:
bool RunAllPassesOnSCC(CallGraphSCC &CurSCC, CallGraph &CG,
bool &DevirtualizedCall);
bool RunPassOnSCC(Pass *P, CallGraphSCC &CurSCC,
CallGraph &CG, bool &CallGraphUpToDate,
bool &DevirtualizedCall);
bool RefreshCallGraph(CallGraphSCC &CurSCC, CallGraph &CG,
bool IsCheckingMode);
};
} // end anonymous namespace.
char CGPassManager::ID = 0;
bool CGPassManager::RunPassOnSCC(Pass *P, CallGraphSCC &CurSCC,
CallGraph &CG, bool &CallGraphUpToDate,
bool &DevirtualizedCall) {
bool Changed = false;
PMDataManager *PM = P->getAsPMDataManager();
if (PM == 0) {
CallGraphSCCPass *CGSP = (CallGraphSCCPass*)P;
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
if (!CallGraphUpToDate) {
DevirtualizedCall |= RefreshCallGraph(CurSCC, CG, false);
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
CallGraphUpToDate = true;
}
{
TimeRegion PassTimer(getPassTimer(CGSP));
Changed = CGSP->runOnSCC(CurSCC);
}
// After the CGSCCPass is done, when assertions are enabled, use
// RefreshCallGraph to verify that the callgraph was correctly updated.
#ifndef NDEBUG
if (Changed)
RefreshCallGraph(CurSCC, CG, true);
#endif
return Changed;
}
assert(PM->getPassManagerType() == PMT_FunctionPassManager &&
"Invalid CGPassManager member");
FPPassManager *FPP = (FPPassManager*)P;
// Run pass P on all functions in the current SCC.
for (CallGraphSCC::iterator I = CurSCC.begin(), E = CurSCC.end();
I != E; ++I) {
if (Function *F = (*I)->getFunction()) {
dumpPassInfo(P, EXECUTION_MSG, ON_FUNCTION_MSG, F->getName());
TimeRegion PassTimer(getPassTimer(FPP));
Changed |= FPP->runOnFunction(*F);
}
}
// The function pass(es) modified the IR, they may have clobbered the
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
// callgraph.
if (Changed && CallGraphUpToDate) {
DEBUG(dbgs() << "CGSCCPASSMGR: Pass Dirtied SCC: "
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
<< P->getPassName() << '\n');
CallGraphUpToDate = false;
}
return Changed;
}
/// RefreshCallGraph - Scan the functions in the specified CFG and resync the
/// callgraph with the call sites found in it. This is used after
/// FunctionPasses have potentially munged the callgraph, and can be used after
/// CallGraphSCC passes to verify that they correctly updated the callgraph.
///
/// This function returns true if it devirtualized an existing function call,
/// meaning it turned an indirect call into a direct call. This happens when
/// a function pass like GVN optimizes away stuff feeding the indirect call.
/// This never happens in checking mode.
///
bool CGPassManager::RefreshCallGraph(CallGraphSCC &CurSCC,
CallGraph &CG, bool CheckingMode) {
DenseMap<Value*, CallGraphNode*> CallSites;
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
DEBUG(dbgs() << "CGSCCPASSMGR: Refreshing SCC with " << CurSCC.size()
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
<< " nodes:\n";
for (CallGraphSCC::iterator I = CurSCC.begin(), E = CurSCC.end();
I != E; ++I)
(*I)->dump();
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
);
bool MadeChange = false;
bool DevirtualizedCall = false;
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
// Scan all functions in the SCC.
unsigned FunctionNo = 0;
for (CallGraphSCC::iterator SCCIdx = CurSCC.begin(), E = CurSCC.end();
SCCIdx != E; ++SCCIdx, ++FunctionNo) {
CallGraphNode *CGN = *SCCIdx;
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
Function *F = CGN->getFunction();
if (F == 0 || F->isDeclaration()) continue;
// Walk the function body looking for call sites. Sync up the call sites in
// CGN with those actually in the function.
// Keep track of the number of direct and indirect calls that were
// invalidated and removed.
unsigned NumDirectRemoved = 0, NumIndirectRemoved = 0;
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
// Get the set of call sites currently in the function.
for (CallGraphNode::iterator I = CGN->begin(), E = CGN->end(); I != E; ) {
// If this call site is null, then the function pass deleted the call
// entirely and the WeakVH nulled it out.
if (I->first == 0 ||
// If we've already seen this call site, then the FunctionPass RAUW'd
// one call with another, which resulted in two "uses" in the edge
// list of the same call.
CallSites.count(I->first) ||
// If the call edge is not from a call or invoke, then the function
// pass RAUW'd a call with another value. This can happen when
// constant folding happens of well known functions etc.
CallSite::get(I->first).getInstruction() == 0) {
assert(!CheckingMode &&
"CallGraphSCCPass did not update the CallGraph correctly!");
// If this was an indirect call site, count it.
if (I->second->getFunction() == 0)
++NumIndirectRemoved;
else
++NumDirectRemoved;
// Just remove the edge from the set of callees, keep track of whether
// I points to the last element of the vector.
bool WasLast = I + 1 == E;
CGN->removeCallEdge(I);
// If I pointed to the last element of the vector, we have to bail out:
// iterator checking rejects comparisons of the resultant pointer with
// end.
if (WasLast)
break;
E = CGN->end();
continue;
}
assert(!CallSites.count(I->first) &&
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
"Call site occurs in node multiple times");
CallSites.insert(std::make_pair(I->first, I->second));
++I;
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
}
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
// Loop over all of the instructions in the function, getting the callsites.
// Keep track of the number of direct/indirect calls added.
unsigned NumDirectAdded = 0, NumIndirectAdded = 0;
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
for (Function::iterator BB = F->begin(), E = F->end(); BB != E; ++BB)
for (BasicBlock::iterator I = BB->begin(), E = BB->end(); I != E; ++I) {
CallSite CS = CallSite::get(I);
if (!CS.getInstruction() || isa<DbgInfoIntrinsic>(I)) continue;
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
// If this call site already existed in the callgraph, just verify it
// matches up to expectations and remove it from CallSites.
DenseMap<Value*, CallGraphNode*>::iterator ExistingIt =
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
CallSites.find(CS.getInstruction());
if (ExistingIt != CallSites.end()) {
CallGraphNode *ExistingNode = ExistingIt->second;
// Remove from CallSites since we have now seen it.
CallSites.erase(ExistingIt);
// Verify that the callee is right.
if (ExistingNode->getFunction() == CS.getCalledFunction())
continue;
// If we are in checking mode, we are not allowed to actually mutate
// the callgraph. If this is a case where we can infer that the
// callgraph is less precise than it could be (e.g. an indirect call
// site could be turned direct), don't reject it in checking mode, and
// don't tweak it to be more precise.
if (CheckingMode && CS.getCalledFunction() &&
ExistingNode->getFunction() == 0)
continue;
assert(!CheckingMode &&
"CallGraphSCCPass did not update the CallGraph correctly!");
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
// If not, we either went from a direct call to indirect, indirect to
// direct, or direct to different direct.
CallGraphNode *CalleeNode;
if (Function *Callee = CS.getCalledFunction()) {
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
CalleeNode = CG.getOrInsertFunction(Callee);
// Keep track of whether we turned an indirect call into a direct
// one.
if (ExistingNode->getFunction() == 0) {
DevirtualizedCall = true;
DEBUG(dbgs() << " CGSCCPASSMGR: Devirtualized call to '"
<< Callee->getName() << "'\n");
}
} else {
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
CalleeNode = CG.getCallsExternalNode();
}
// Update the edge target in CGN.
CGN->replaceCallEdge(CS, CS, CalleeNode);
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
MadeChange = true;
continue;
}
assert(!CheckingMode &&
"CallGraphSCCPass did not update the CallGraph correctly!");
// If the call site didn't exist in the CGN yet, add it.
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
CallGraphNode *CalleeNode;
if (Function *Callee = CS.getCalledFunction()) {
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
CalleeNode = CG.getOrInsertFunction(Callee);
++NumDirectAdded;
} else {
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
CalleeNode = CG.getCallsExternalNode();
++NumIndirectAdded;
}
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
CGN->addCalledFunction(CS, CalleeNode);
MadeChange = true;
}
// We scanned the old callgraph node, removing invalidated call sites and
// then added back newly found call sites. One thing that can happen is
// that an old indirect call site was deleted and replaced with a new direct
// call. In this case, we have devirtualized a call, and CGSCCPM would like
// to iteratively optimize the new code. Unfortunately, we don't really
// have a great way to detect when this happens. As an approximation, we
// just look at whether the number of indirect calls is reduced and the
// number of direct calls is increased. There are tons of ways to fool this
// (e.g. DCE'ing an indirect call and duplicating an unrelated block with a
// direct call) but this is close enough.
if (NumIndirectRemoved > NumIndirectAdded &&
NumDirectRemoved < NumDirectAdded)
DevirtualizedCall = true;
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
// After scanning this function, if we still have entries in callsites, then
// they are dangling pointers. WeakVH should save us for this, so abort if
// this happens.
assert(CallSites.empty() && "Dangling pointers found in call sites map");
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
// Periodically do an explicit clear to remove tombstones when processing
// large scc's.
if ((FunctionNo & 15) == 15)
CallSites.clear();
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
}
DEBUG(if (MadeChange) {
dbgs() << "CGSCCPASSMGR: Refreshed SCC is now:\n";
for (CallGraphSCC::iterator I = CurSCC.begin(), E = CurSCC.end();
I != E; ++I)
(*I)->dump();
if (DevirtualizedCall)
dbgs() << "CGSCCPASSMGR: Refresh devirtualized a call!\n";
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
} else {
dbgs() << "CGSCCPASSMGR: SCC Refresh didn't change call graph.\n";
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
}
);
return DevirtualizedCall;
}
/// RunAllPassesOnSCC - Execute the body of the entire pass manager on the
/// specified SCC. This keeps track of whether a function pass devirtualizes
/// any calls and returns it in DevirtualizedCall.
bool CGPassManager::RunAllPassesOnSCC(CallGraphSCC &CurSCC, CallGraph &CG,
bool &DevirtualizedCall) {
bool Changed = false;
// CallGraphUpToDate - Keep track of whether the callgraph is known to be
// up-to-date or not. The CGSSC pass manager runs two types of passes:
// CallGraphSCC Passes and other random function passes. Because other
// random function passes are not CallGraph aware, they may clobber the
// call graph by introducing new calls or deleting other ones. This flag
// is set to false when we run a function pass so that we know to clean up
// the callgraph when we need to run a CGSCCPass again.
bool CallGraphUpToDate = true;
// Run all passes on current SCC.
for (unsigned PassNo = 0, e = getNumContainedPasses();
PassNo != e; ++PassNo) {
Pass *P = getContainedPass(PassNo);
// If we're in -debug-pass=Executions mode, construct the SCC node list,
// otherwise avoid constructing this string as it is expensive.
if (isPassDebuggingExecutionsOrMore()) {
std::string Functions;
#ifndef NDEBUG
raw_string_ostream OS(Functions);
for (CallGraphSCC::iterator I = CurSCC.begin(), E = CurSCC.end();
I != E; ++I) {
if (I != CurSCC.begin()) OS << ", ";
(*I)->print(OS);
}
OS.flush();
#endif
dumpPassInfo(P, EXECUTION_MSG, ON_CG_MSG, Functions);
}
dumpRequiredSet(P);
initializeAnalysisImpl(P);
// Actually run this pass on the current SCC.
Changed |= RunPassOnSCC(P, CurSCC, CG,
CallGraphUpToDate, DevirtualizedCall);
if (Changed)
dumpPassInfo(P, MODIFICATION_MSG, ON_CG_MSG, "");
dumpPreservedSet(P);
verifyPreservedAnalysis(P);
removeNotPreservedAnalysis(P);
recordAvailableAnalysis(P);
removeDeadPasses(P, "", ON_CG_MSG);
}
// If the callgraph was left out of date (because the last pass run was a
// functionpass), refresh it before we move on to the next SCC.
if (!CallGraphUpToDate)
DevirtualizedCall |= RefreshCallGraph(CurSCC, CG, false);
return Changed;
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
}
/// run - Execute all of the passes scheduled for execution. Keep track of
/// whether any of the passes modifies the module, and if so, return true.
bool CGPassManager::runOnModule(Module &M) {
CallGraph &CG = getAnalysis<CallGraph>();
Revert r64300 and r64301. These were causing the following errors respectively: During llvm-gcc bootstrap: Undefined symbols: "llvm::FPPassManager::doFinalization(llvm::Module&)", referenced from: (anonymous namespace)::CGPassManager::doFinalization(llvm::CallGraph&, llvm::Module&) in libLLVMipa.a(CallGraphSCCPass.o) "llvm::FPPassManager::doInitialization(llvm::Module&)", referenced from: (anonymous namespace)::CGPassManager::doInitialization(llvm::CallGraph&, llvm::Module&) in libLLVMipa.a(CallGraphSCCPass.o) ld: symbol(s) not found collect2: ld returned 1 exit status make[3]: *** [/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore.roots/llvmCore~obj/obj-llvm/Release/bin/opt] Error 1 During an LLVM release build: /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/Release/bin/tblgen -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86 -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target -gen-register-desc -o /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Target/X86/Release/X86GenRegisterInfo.inc.tmp /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86/X86.td llvm[3]: Building X86.td instruction names with tblgen /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/Release/bin/tblgen -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86 -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target -gen-instr-enums -o /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Target/X86/Release/X86GenInstrNames.inc.tmp /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86/X86.td llvm[3]: Building X86.td instruction information with tblgen /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/Release/bin/tblgen -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86 -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target -gen-instr-desc -o /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Target/X86/Release/X86GenInstrInfo.inc.tmp /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86/X86.td llvm[3]: Building X86.td assembly writer with tblgen /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/Release/bin/tblgen -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86 -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target -gen-asm-writer -o /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Target/X86/Release/X86GenAsmWriter.inc.tmp /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86/X86.td llvm[3]: Compiling InstructionCombining.cpp for Release build if /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmgcc42.roots/llvmgcc42~dst/Developer/usr/bin/llvm-g++-4.2 -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/include -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Transforms/Scalar -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O3 -fno-exceptions -Woverloaded-virtual -pedantic -Wall -W -Wwrite-strings -Wno-long-long -Wunused -Wno-unused-parameter -fstrict-aliasing -Wstrict-aliasing -c -MMD -MP -MF "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.d.tmp" -MT "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.lo" -MT "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.o" -MT "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.d" /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Transforms/Scalar/InstructionCombining.cpp -o /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.o ; \ then /bin/mv -f "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.d.tmp" "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Trans git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@64311 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-11 18:19:24 +00:00
bool Changed = doInitialization(CG);
// Walk the callgraph in bottom-up SCC order.
scc_iterator<CallGraph*> CGI = scc_begin(&CG);
CallGraphSCC CurSCC(&CGI);
while (!CGI.isAtEnd()) {
// Copy the current SCC and increment past it so that the pass can hack
// on the SCC if it wants to without invalidating our iterator.
std::vector<CallGraphNode*> &NodeVec = *CGI;
CurSCC.initialize(&NodeVec[0], &NodeVec[0]+NodeVec.size());
++CGI;
// At the top level, we run all the passes in this pass manager on the
// functions in this SCC. However, we support iterative compilation in the
// case where a function pass devirtualizes a call to a function. For
// example, it is very common for a function pass (often GVN or instcombine)
// to eliminate the addressing that feeds into a call. With that improved
// information, we would like the call to be an inline candidate, infer
// mod-ref information etc.
//
// Because of this, we allow iteration up to a specified iteration count.
// This only happens in the case of a devirtualized call, so we only burn
// compile time in the case that we're making progress. We also have a hard
// iteration count limit in case there is crazy code.
unsigned Iteration = 0;
bool DevirtualizedCall = false;
do {
DEBUG(if (Iteration)
dbgs() << " SCCPASSMGR: Re-visiting SCC, iteration #"
<< Iteration << '\n');
DevirtualizedCall = false;
Changed |= RunAllPassesOnSCC(CurSCC, CG, DevirtualizedCall);
} while (Iteration++ < MaxIterations && DevirtualizedCall);
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
if (DevirtualizedCall)
DEBUG(dbgs() << " CGSCCPASSMGR: Stopped iteration after " << Iteration
<< " times, due to -max-cg-scc-iterations\n");
if (Iteration > MaxSCCIterations)
MaxSCCIterations = Iteration;
Step #1 to giving Callgraph some sane invariants. The problems with callgraph stem from the fact that we have two types of passes that need to update it: 1. callgraphscc and module passes that are explicitly aware of it 2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes by the CGSCC Passmgr. In the case of #1, we can reasonably expect the passes to update the call graph just like any analysis. However, functionpasses are not and generally should not be CG aware. This has caused us no end of problems, so this takes a new approach. Logically, the CGSCC Pass manager can rescan every function after it runs a function pass over it to see if the functionpass made any updates to the IR that affect the callgraph. This allows it to catch new calls introduced by the functionpass. In practice, doing this would be slow. This implementation keeps track of whether or not the current scc is dirtied by a function pass, and, if so, delays updating the callgraph until it is actually needed again. This was we avoid extraneous rescans, but we still have good invariants when the callgraph is needed. Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode to use a CallBackVH for the callsite entry of the CallGraphNode. This way we can immediately remove entries from the callgraph when a FunctionPass is active instead of having dangling pointers. The current pass tries to tolerate these dangling pointers, but it is just an evil hack. This is related to PR3601/4835/4029. This also reverts r80541, a hack working around the sad lack of invariants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-31 07:23:46 +00:00
}
Revert r64300 and r64301. These were causing the following errors respectively: During llvm-gcc bootstrap: Undefined symbols: "llvm::FPPassManager::doFinalization(llvm::Module&)", referenced from: (anonymous namespace)::CGPassManager::doFinalization(llvm::CallGraph&, llvm::Module&) in libLLVMipa.a(CallGraphSCCPass.o) "llvm::FPPassManager::doInitialization(llvm::Module&)", referenced from: (anonymous namespace)::CGPassManager::doInitialization(llvm::CallGraph&, llvm::Module&) in libLLVMipa.a(CallGraphSCCPass.o) ld: symbol(s) not found collect2: ld returned 1 exit status make[3]: *** [/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore.roots/llvmCore~obj/obj-llvm/Release/bin/opt] Error 1 During an LLVM release build: /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/Release/bin/tblgen -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86 -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target -gen-register-desc -o /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Target/X86/Release/X86GenRegisterInfo.inc.tmp /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86/X86.td llvm[3]: Building X86.td instruction names with tblgen /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/Release/bin/tblgen -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86 -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target -gen-instr-enums -o /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Target/X86/Release/X86GenInstrNames.inc.tmp /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86/X86.td llvm[3]: Building X86.td instruction information with tblgen /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/Release/bin/tblgen -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86 -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target -gen-instr-desc -o /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Target/X86/Release/X86GenInstrInfo.inc.tmp /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86/X86.td llvm[3]: Building X86.td assembly writer with tblgen /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/Release/bin/tblgen -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86 -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target -gen-asm-writer -o /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Target/X86/Release/X86GenAsmWriter.inc.tmp /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86/X86.td llvm[3]: Compiling InstructionCombining.cpp for Release build if /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmgcc42.roots/llvmgcc42~dst/Developer/usr/bin/llvm-g++-4.2 -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/include -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Transforms/Scalar -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O3 -fno-exceptions -Woverloaded-virtual -pedantic -Wall -W -Wwrite-strings -Wno-long-long -Wunused -Wno-unused-parameter -fstrict-aliasing -Wstrict-aliasing -c -MMD -MP -MF "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.d.tmp" -MT "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.lo" -MT "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.o" -MT "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.d" /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Transforms/Scalar/InstructionCombining.cpp -o /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.o ; \ then /bin/mv -f "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.d.tmp" "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Trans git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@64311 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-11 18:19:24 +00:00
Changed |= doFinalization(CG);
return Changed;
}
/// Initialize CG
Revert r64300 and r64301. These were causing the following errors respectively: During llvm-gcc bootstrap: Undefined symbols: "llvm::FPPassManager::doFinalization(llvm::Module&)", referenced from: (anonymous namespace)::CGPassManager::doFinalization(llvm::CallGraph&, llvm::Module&) in libLLVMipa.a(CallGraphSCCPass.o) "llvm::FPPassManager::doInitialization(llvm::Module&)", referenced from: (anonymous namespace)::CGPassManager::doInitialization(llvm::CallGraph&, llvm::Module&) in libLLVMipa.a(CallGraphSCCPass.o) ld: symbol(s) not found collect2: ld returned 1 exit status make[3]: *** [/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore.roots/llvmCore~obj/obj-llvm/Release/bin/opt] Error 1 During an LLVM release build: /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/Release/bin/tblgen -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86 -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target -gen-register-desc -o /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Target/X86/Release/X86GenRegisterInfo.inc.tmp /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86/X86.td llvm[3]: Building X86.td instruction names with tblgen /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/Release/bin/tblgen -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86 -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target -gen-instr-enums -o /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Target/X86/Release/X86GenInstrNames.inc.tmp /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86/X86.td llvm[3]: Building X86.td instruction information with tblgen /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/Release/bin/tblgen -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86 -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target -gen-instr-desc -o /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Target/X86/Release/X86GenInstrInfo.inc.tmp /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86/X86.td llvm[3]: Building X86.td assembly writer with tblgen /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/Release/bin/tblgen -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86 -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target -gen-asm-writer -o /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Target/X86/Release/X86GenAsmWriter.inc.tmp /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86/X86.td llvm[3]: Compiling InstructionCombining.cpp for Release build if /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmgcc42.roots/llvmgcc42~dst/Developer/usr/bin/llvm-g++-4.2 -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/include -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Transforms/Scalar -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O3 -fno-exceptions -Woverloaded-virtual -pedantic -Wall -W -Wwrite-strings -Wno-long-long -Wunused -Wno-unused-parameter -fstrict-aliasing -Wstrict-aliasing -c -MMD -MP -MF "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.d.tmp" -MT "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.lo" -MT "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.o" -MT "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.d" /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Transforms/Scalar/InstructionCombining.cpp -o /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.o ; \ then /bin/mv -f "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.d.tmp" "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Trans git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@64311 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-11 18:19:24 +00:00
bool CGPassManager::doInitialization(CallGraph &CG) {
bool Changed = false;
for (unsigned i = 0, e = getNumContainedPasses(); i != e; ++i) {
if (PMDataManager *PM = getContainedPass(i)->getAsPMDataManager()) {
assert(PM->getPassManagerType() == PMT_FunctionPassManager &&
"Invalid CGPassManager member");
Changed |= ((FPPassManager*)PM)->doInitialization(CG.getModule());
} else {
Changed |= ((CallGraphSCCPass*)getContainedPass(i))->doInitialization(CG);
}
}
return Changed;
}
/// Finalize CG
Revert r64300 and r64301. These were causing the following errors respectively: During llvm-gcc bootstrap: Undefined symbols: "llvm::FPPassManager::doFinalization(llvm::Module&)", referenced from: (anonymous namespace)::CGPassManager::doFinalization(llvm::CallGraph&, llvm::Module&) in libLLVMipa.a(CallGraphSCCPass.o) "llvm::FPPassManager::doInitialization(llvm::Module&)", referenced from: (anonymous namespace)::CGPassManager::doInitialization(llvm::CallGraph&, llvm::Module&) in libLLVMipa.a(CallGraphSCCPass.o) ld: symbol(s) not found collect2: ld returned 1 exit status make[3]: *** [/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore.roots/llvmCore~obj/obj-llvm/Release/bin/opt] Error 1 During an LLVM release build: /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/Release/bin/tblgen -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86 -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target -gen-register-desc -o /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Target/X86/Release/X86GenRegisterInfo.inc.tmp /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86/X86.td llvm[3]: Building X86.td instruction names with tblgen /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/Release/bin/tblgen -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86 -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target -gen-instr-enums -o /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Target/X86/Release/X86GenInstrNames.inc.tmp /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86/X86.td llvm[3]: Building X86.td instruction information with tblgen /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/Release/bin/tblgen -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86 -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target -gen-instr-desc -o /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Target/X86/Release/X86GenInstrInfo.inc.tmp /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86/X86.td llvm[3]: Building X86.td assembly writer with tblgen /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/Release/bin/tblgen -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86 -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target -gen-asm-writer -o /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Target/X86/Release/X86GenAsmWriter.inc.tmp /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Target/X86/X86.td llvm[3]: Compiling InstructionCombining.cpp for Release build if /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmgcc42.roots/llvmgcc42~dst/Developer/usr/bin/llvm-g++-4.2 -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/include -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/include -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Transforms/Scalar -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O3 -fno-exceptions -Woverloaded-virtual -pedantic -Wall -W -Wwrite-strings -Wno-long-long -Wunused -Wno-unused-parameter -fstrict-aliasing -Wstrict-aliasing -c -MMD -MP -MF "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.d.tmp" -MT "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.lo" -MT "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.o" -MT "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.d" /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/lib/Transforms/Scalar/InstructionCombining.cpp -o /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.o ; \ then /bin/mv -f "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Transforms/Scalar/Release/InstructionCombining.d.tmp" "/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.sh.build/lib/Trans git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@64311 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-11 18:19:24 +00:00
bool CGPassManager::doFinalization(CallGraph &CG) {
bool Changed = false;
for (unsigned i = 0, e = getNumContainedPasses(); i != e; ++i) {
if (PMDataManager *PM = getContainedPass(i)->getAsPMDataManager()) {
assert(PM->getPassManagerType() == PMT_FunctionPassManager &&
"Invalid CGPassManager member");
Changed |= ((FPPassManager*)PM)->doFinalization(CG.getModule());
} else {
Changed |= ((CallGraphSCCPass*)getContainedPass(i))->doFinalization(CG);
}
}
return Changed;
}
//===----------------------------------------------------------------------===//
// CallGraphSCC Implementation
//===----------------------------------------------------------------------===//
/// ReplaceNode - This informs the SCC and the pass manager that the specified
/// Old node has been deleted, and New is to be used in its place.
void CallGraphSCC::ReplaceNode(CallGraphNode *Old, CallGraphNode *New) {
assert(Old != New && "Should not replace node with self");
for (unsigned i = 0; ; ++i) {
assert(i != Nodes.size() && "Node not in SCC");
if (Nodes[i] != Old) continue;
Nodes[i] = New;
break;
}
// Update the active scc_iterator so that it doesn't contain dangling
// pointers to the old CallGraphNode.
scc_iterator<CallGraph*> *CGI = (scc_iterator<CallGraph*>*)Context;
CGI->ReplaceNode(Old, New);
}
//===----------------------------------------------------------------------===//
// CallGraphSCCPass Implementation
//===----------------------------------------------------------------------===//
/// Assign pass manager to manage this pass.
void CallGraphSCCPass::assignPassManager(PMStack &PMS,
PassManagerType PreferredType) {
// Find CGPassManager
while (!PMS.empty() &&
PMS.top()->getPassManagerType() > PMT_CallGraphPassManager)
PMS.pop();
assert(!PMS.empty() && "Unable to handle Call Graph Pass");
CGPassManager *CGP;
if (PMS.top()->getPassManagerType() == PMT_CallGraphPassManager)
CGP = (CGPassManager*)PMS.top();
else {
// Create new Call Graph SCC Pass Manager if it does not exist.
assert(!PMS.empty() && "Unable to create Call Graph Pass Manager");
PMDataManager *PMD = PMS.top();
// [1] Create new Call Graph Pass Manager
CGP = new CGPassManager(PMD->getDepth() + 1);
// [2] Set up new manager's top level manager
PMTopLevelManager *TPM = PMD->getTopLevelManager();
TPM->addIndirectPassManager(CGP);
// [3] Assign manager to manage this new manager. This may create
// and push new managers into PMS
Pass *P = CGP;
TPM->schedulePass(P);
// [4] Push new manager into PMS
PMS.push(CGP);
}
CGP->add(this);
}
/// getAnalysisUsage - For this class, we declare that we require and preserve
/// the call graph. If the derived class implements this method, it should
/// always explicitly call the implementation here.
void CallGraphSCCPass::getAnalysisUsage(AnalysisUsage &AU) const {
AU.addRequired<CallGraph>();
AU.addPreserved<CallGraph>();
}
//===----------------------------------------------------------------------===//
// PrintCallGraphPass Implementation
//===----------------------------------------------------------------------===//
namespace {
/// PrintCallGraphPass - Print a Module corresponding to a call graph.
///
class PrintCallGraphPass : public CallGraphSCCPass {
std::string Banner;
raw_ostream &Out; // raw_ostream to print on.
public:
static char ID;
PrintCallGraphPass() : CallGraphSCCPass(&ID), Out(dbgs()) {}
PrintCallGraphPass(const std::string &B, raw_ostream &o)
: CallGraphSCCPass(&ID), Banner(B), Out(o) {}
virtual void getAnalysisUsage(AnalysisUsage &AU) const {
AU.setPreservesAll();
}
bool runOnSCC(CallGraphSCC &SCC) {
Out << Banner;
for (CallGraphSCC::iterator I = SCC.begin(), E = SCC.end(); I != E; ++I)
(*I)->getFunction()->print(Out);
return false;
}
};
} // end anonymous namespace.
char PrintCallGraphPass::ID = 0;
Pass *CallGraphSCCPass::createPrinterPass(raw_ostream &O,
const std::string &Banner) const {
return new PrintCallGraphPass(Banner, O);
}