search for: setpreservescfg

Dear All, Does the setPreservesCFG() call for passes indicate that the CFG in the local function does not change or that the global CFG does not change? In other words, can a pass call setPreservesCFG() if it adds call instructions to a function? Thanks in advance. -- John T.

On Feb 23, 2009, at 1:23 PM, John Criswell wrote: > Dear All, > > Does the setPreservesCFG() call for passes indicate that the CFG in > the > local function does not change or that the global CFG does not change? The CFG in this context is just the per-function CFG. "setPreservesCFG" can only be used meaninfully for FunctionPasses. > In other words, can a pass c...

...g here? InstructionCombining.cpp:73-82 char InstCombiner::ID = 0; INITIALIZE_PASS(InstCombiner, "instcombine", "Combine redundant instructions", false, false) void InstCombiner::getAnalysisUsage(AnalysisUsage &AU) const { AU.addPreservedID(LCSSAID); AU.setPreservesCFG(); }

...gument should be set to true if the pass only looks at the CFG, i.e. whatever it computes/does is only a function of the CFG, and doesn't otherwise depend on what particular instructions make up the function. Suppose an analysis pass A has this property, and a transform pass P announces (using setPreservesCFG()) that it does not change the CFG. Then A does not need to be recomputed after P has run. So I think it is correct for InstCombine to not set this flag. Ciao, Duncan. Is this a > mistake, or is there deeper meaning here? > > InstructionCombining.cpp:73-82 > > char InstCombiner...

...Utils/UnifyFunctionExitNodes.h" #include "llvm/Analysis/Dominators.h" #include "llvm/Instructions.h" #include "llvm/Function.h" @@ -37,6 +38,10 @@ namespace { AU.addRequired<DominanceFrontier>(); AU.addRequired<TargetData>(); AU.setPreservesCFG(); + // This is a cluster of orthogonal Transforms + AU.addPreserved<UnifyFunctionExitNodes>(); + AU.addPreservedID(LowerSelectID); + AU.addPreservedID(LowerSwitchID); } }; Index: ./lib/Transforms/Scalar/LowerSelect.cpp ============================================...

...Dan Gohman wrote: > Hello, > > Here are a few misc. comments on this patch. > > Would it make sense to mark the ProfileInfo passes as "CFGOnly?" > If so, that would let them be automatically preserved by passes > which don't modify the CFG (and that call AU.setPreservesCFG()). Yes, it would, how do I do this? :-) >> + if (ProfileInfo* PI = getAnalysisIfAvailable<ProfileInfo>()) { >> + PI->splitEdge(OrigPreHeader, NewHeader, NewPreHeader); >> + } >> + >> // Preserve canonical loop form, which means Exit block shou...

..." method. Was there any particular reason to do it this way? I wouldn't mind doing the splitting myself, though I am not using the CVS versions right now. Also, it would be nice to have support for some sort of a "addPreservedTransitive" method ... so that when a pass uses "setPreservesCFG", other passes such as dominator analysis will be automatically preserved too ... Sameer. -- Research Scholar, KReSIT, IIT Bombay http://www.it.iitb.ac.in/~sameerds/

"Daniel Stewart" <stewartd at codeaurora.org> writes: > You haven't mentioned if your passes are implementers of an interface > (like AliasAnalysis). No, they're just regular FunctionPasses. > What seems to matter as far as having a pass free'd from memory are > the LastUsers. The LastUsers are set by required passes. So if a pass > says it requires

I am trying to add an analysis pass as a FunctionPass, and let LICM (LoopPass) depends upon it. So in LICM.cpp, I have the following: virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.setPreservesCFG(); AU.addRequired<DominatorTree>(); AU.addRequired<LoopInfo>(); AU.addRequiredID(LoopSimplifyID); AU.addRequired<AliasAnalysis>(); AU.addRequired<MyAnalysis>(); // Add this AU.addPreserved<AliasAnalysis>();...

Hello, Here are a few misc. comments on this patch. Would it make sense to mark the ProfileInfo passes as "CFGOnly?" If so, that would let them be automatically preserved by passes which don't modify the CFG (and that call AU.setPreservesCFG()). > + if (ProfileInfo* PI = getAnalysisIfAvailable<ProfileInfo>()) { > + PI->splitEdge(OrigPreHeader, NewHeader, NewPreHeader); > + } > + > // Preserve canonical loop form, which means Exit block should > // have only one predecessor. > SplitEdge(L-&g...

...me() << "!\n"; LoopInfo& li = getAnalysis<LoopInfoWrapperPass>().getLoopInfo(); return false; } virtual void getAnalysisUsage(AnalysisUsage& au) const override { au.setPreservesCFG(); au.addRequired<LoopInfoWrapperPass>(); } }; } char SkeletonPass::ID = 0; //Automatically enable the pass. //http://adriansampson.net/blog/clangpass.html static void registerSkeletonPass(const PassManagerBuilder &, legac...

...Manager Preliminary module verification Dominator Tree Construction Module Verifier Bitcode Writer I checked out the latest svn code of LLVM. Clearly, FunctionAttrs requires AliasAnalysis of AU. virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.setPreservesCFG(); AU.addRequired<AliasAnalysis>(); AU.addRequired<TargetLibraryInfo>(); CallGraphSCCPass::getAnalysisUsage(AU); } My changeset is almost like this. the issue has gone away. --- a/lib/Transforms/IPO/FunctionAttrs.cpp +++ b/lib/Transforms/IPO/FunctionAttrs.cpp @@...

Hi all, this (altough a big patch) is actually pretty straight forward: It (tries) to preserve ProfileInfo in all -std-compile-opts passes and all X86-Backend passes. There is still some passes that have corner cases where the ProfileInfo is not correct after the pass. Some passes are still missing... How shall I proceed with this? Andi -------------- next part -------------- A non-text

...d readnone } ;---------------------------------------------------------------- then %call1 will be removed by the Dead Instruction Elimination pass. I.e. that pass is not preserving the CallGraph! Dead Instruction Elimination is a BasicBlockPass, and DeadInstElimination::getAnalysisUsage is doing setPreservesCFG() (even though that should be implicit for a BasicBlockPass afaik). When reading the description of BasicBlockPass it seems to be legal to remove calls, and that should not impact the CFG, right? But it will impact the CallGraph. I believe that when the FunctionPass Manager is used from within the...

I'm attempting to add some support for hoisting/sinking of memory-using intrinsics in loops, and so I want to use MemoryDependenceAnalysis in LICM, but when I modify getAnalysisUsge to include this : virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.setPreservesCFG(); AU.addRequired<DominatorTree>(); AU.addRequired<LoopInfo>(); AU.addRequiredID(LoopSimplifyID); AU.addRequired<MemoryDependenceAnalysis>(); // <--- added AU.addRequired<AliasAnalysis>(); AU.addPreserved<AliasAnalysis>();...

...------------------------------ > > > > then %call1 will be removed by the Dead Instruction Elimination pass. I.e. > that pass is not preserving the CallGraph! > > > > Dead Instruction Elimination is a BasicBlockPass, and > DeadInstElimination::getAnalysisUsage is doing setPreservesCFG() (even > though that should be implicit for a BasicBlockPass afaik). > > When reading the description of BasicBlockPass it seems to be legal to > remove calls, and that should not impact the CFG, right? But it will impact > the CallGraph. > > > > I believe that when the...

...> > > > then %call1 will be removed by the Dead Instruction Elimination pass. I.e. > > that pass is not preserving the CallGraph! > > > > > > > > Dead Instruction Elimination is a BasicBlockPass, and > > DeadInstElimination::getAnalysisUsage is doing setPreservesCFG() (even > > though that should be implicit for a BasicBlockPass afaik). > > > > When reading the description of BasicBlockPass it seems to be legal to > > remove calls, and that should not impact the CFG, right? But it will impact > > the CallGraph. > > > >...

>> br2uncond->eraseFromParent(). This results in br1cond loosing it's >> label/offset. How could I resolve this? > Your code is broken. AnalyzeBranch should not modify anything. > > I was taking a clue from Mips/MipsInstrInfo.cpp: AnalyzeBranch :( > Could you please suggest appropriate alternative place for such a > modification? Ah sorry, my memory served me

...cond pass is a function pass which requires the first pass above. The passes run fine when executed alone. I get the following error when I try to run my second pass with the following code added > > void getAnalysisUsage(AnalysisUsage &AU)const{ > AU.setPreservesCFG(); > AU.addRequired<First_Pass>(); > > } Assertion failed: (PI && "Expected required passes to be initialized"), function schedulePass, file PassManager.cpp, line 597. I register the passes using RegisterPass function call. What else s...

This is just a note to mention that I just checked in this change (and fallout from it): http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20021021/000876.html Which renames: AnalysisUsage::preservesAll -> getPreservesAll AnalysisUsage::preservesCFG -> setPreservesCFG to be consistent with the already existing setPreservesAll method. This was a very confusing arrangement that Casey recently pointed out. I fixed all uses of these that are in the CVS repository. When these updates reach you, you will have to update any uses of these methods to call the new nam...