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

422 lines
15 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/Analysis/CallGraph.h"
#include "llvm/ADT/SCCIterator.h"
#include "llvm/PassManagers.h"
#include "llvm/Function.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/IntrinsicInst.h"
#include "llvm/Support/raw_ostream.h"
using namespace llvm;
//===----------------------------------------------------------------------===//
// 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";
}
// 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:
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 RunPassOnSCC(Pass *P, std::vector<CallGraphNode*> &CurSCC,
CallGraph &CG, bool &CallGraphUpToDate);
void RefreshCallGraph(std::vector<CallGraphNode*> &CurSCC, CallGraph &CG,
bool IsCheckingMode);
};
} // end anonymous namespace.
char CGPassManager::ID = 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
bool CGPassManager::RunPassOnSCC(Pass *P, std::vector<CallGraphNode*> &CurSCC,
CallGraph &CG, bool &CallGraphUpToDate) {
bool Changed = false;
if (CallGraphSCCPass *CGSP = dynamic_cast<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) {
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;
}
StartPassTimer(CGSP);
Changed = CGSP->runOnSCC(CurSCC);
StopPassTimer(CGSP);
// 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;
}
StartPassTimer(P);
FPPassManager *FPP = dynamic_cast<FPPassManager *>(P);
assert(FPP && "Invalid CGPassManager member");
// Run pass P on all functions in the current SCC.
for (unsigned i = 0, e = CurSCC.size(); i != e; ++i) {
if (Function *F = CurSCC[i]->getFunction()) {
dumpPassInfo(P, EXECUTION_MSG, ON_FUNCTION_MSG, F->getName());
Changed |= FPP->runOnFunction(*F);
}
}
StopPassTimer(P);
// 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(errs() << "CGSCCPASSMGR: Pass Dirtied SCC: "
<< 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.
///
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
void CGPassManager::RefreshCallGraph(std::vector<CallGraphNode*> &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(errs() << "CGSCCPASSMGR: Refreshing SCC with " << CurSCC.size()
<< " nodes:\n";
for (unsigned i = 0, e = CurSCC.size(); i != e; ++i)
CurSCC[i]->dump();
);
bool MadeChange = false;
// Scan all functions in the SCC.
for (unsigned sccidx = 0, e = CurSCC.size(); sccidx != e; ++sccidx) {
CallGraphNode *CGN = CurSCC[sccidx];
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.
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!");
// 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.
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())
CalleeNode = CG.getOrInsertFunction(Callee);
else
CalleeNode = CG.getCallsExternalNode();
// Update the edge target in CGN.
for (CallGraphNode::iterator I = CGN->begin(); ; ++I) {
assert(I != CGN->end() && "Didn't find call entry");
if (I->first == CS.getInstruction()) {
I->second = CalleeNode;
break;
}
}
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!");
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 the call site didn't exist in the CGN yet, add it. We assume that
// newly introduced call sites won't be indirect. This could be fixed
// in the future.
CallGraphNode *CalleeNode;
if (Function *Callee = CS.getCalledFunction())
CalleeNode = CG.getOrInsertFunction(Callee);
else
CalleeNode = CG.getCallsExternalNode();
CGN->addCalledFunction(CS, CalleeNode);
MadeChange = true;
}
// 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 ((sccidx & 15) == 0)
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) {
errs() << "CGSCCPASSMGR: Refreshed SCC is now:\n";
for (unsigned i = 0, e = CurSCC.size(); i != e; ++i)
CurSCC[i]->dump();
} else {
errs() << "CGSCCPASSMGR: SCC Refresh didn't change call graph.\n";
}
);
}
/// 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);
std::vector<CallGraphNode*> CurSCC;
// Walk the callgraph in bottom-up SCC order.
for (scc_iterator<CallGraph*> CGI = scc_begin(&CG), E = scc_end(&CG);
CGI != E;) {
// 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.
CurSCC = *CGI;
++CGI;
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 - 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);
dumpPassInfo(P, EXECUTION_MSG, ON_CG_MSG, "");
dumpRequiredSet(P);
initializeAnalysisImpl(P);
// Actually run this pass on the current 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
Changed |= RunPassOnSCC(P, CurSCC, CG, CallGraphUpToDate);
if (Changed)
dumpPassInfo(P, MODIFICATION_MSG, ON_CG_MSG, "");
dumpPreservedSet(P);
verifyPreservedAnalysis(P);
removeNotPreservedAnalysis(P);
recordAvailableAnalysis(P);
removeDeadPasses(P, "", ON_CG_MSG);
}
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 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)
RefreshCallGraph(CurSCC, CG, false);
}
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 Index = 0; Index < getNumContainedPasses(); ++Index) {
Pass *P = getContainedPass(Index);
if (CallGraphSCCPass *CGSP = dynamic_cast<CallGraphSCCPass *>(P)) {
Changed |= CGSP->doInitialization(CG);
} else {
FPPassManager *FP = dynamic_cast<FPPassManager *>(P);
assert (FP && "Invalid CGPassManager member");
Changed |= FP->doInitialization(CG.getModule());
}
}
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 Index = 0; Index < getNumContainedPasses(); ++Index) {
Pass *P = getContainedPass(Index);
if (CallGraphSCCPass *CGSP = dynamic_cast<CallGraphSCCPass *>(P)) {
Changed |= CGSP->doFinalization(CG);
} else {
FPPassManager *FP = dynamic_cast<FPPassManager *>(P);
assert (FP && "Invalid CGPassManager member");
Changed |= FP->doFinalization(CG.getModule());
}
}
return Changed;
}
/// 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 = dynamic_cast<CGPassManager *>(PMS.top());
// Create new Call Graph SCC Pass Manager if it does not exist.
if (!CGP) {
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 = dynamic_cast<Pass *>(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>();
}