search for: skipmodule

..."Interprocedural constant propagation", false, false) -ModulePass *llvm::createIPConstantPropagationPass() { return new IPCP(); } +ModulePass *llvm::createIPConstantPropagationPass() { + llvm_unreachable("fnord"); +} bool IPCP::runOnModule(Module &M) { if (skipModule(M)) > Any idea why this wasn't removed when IPSCCP was introduced? Probably worth > understanding that before ripping it out, but in the current state of things I > don't think removing it will be problematic. > > diff --git a/llvm/lib/Transforms/IPO/IPConstantPropagation.cp...

...pass manager: bool runOnFunction(Function &F) override { if (skipFunction(F)) return false; // do pass } What's the right way to proceed with this? There are 50-100 calls to skipFunction() in legacy passes. This doesn't even account for other types of IR units, like skipModule(Module&). I suppose it's possible to manually go in and add in the same check in the new passes, but that seems tedious (and how do you test that at scale? clearly there aren't many tests for it right now since check-llvm passes under the new pass manager). An alternative of skipping p...

The pass is pretty rudimental (as the comment at the top of the file hints), and it seems LLVM already has IPSCCP (which should do a better job at interprocedural constant propagation). I'm also not entirely sure it's used anywhere. Is there any reason to keep it around? Thanks, -- Davide "There are no solved problems; there are only problems that are more or less solved" --

...ide { > if (skipFunction(F)) > return false; > > // do pass > > } > > > > What's the right way to proceed with this? There are 50-100 calls to > skipFunction() in legacy passes. This doesn't even account for other types > of IR units, like skipModule(Module&). > > > > I suppose it's possible to manually go in and add in the same check in the > new passes, but that seems tedious (and how do you test that at scale? > clearly there aren't many tests for it right now since check-llvm passes > under the new pass mana...

...t we have now: >    - There is a single OptBisect object, requested through LLVMContext >      (managed as ManagedStatic). > >    - OptBisect is defined in lib/IR, but does use analyses, >      which is a known layering issue > >    - Pass hierarchy provides skipModule etc helper functions > >    - Individual passes opt-in to OptBisect activities by manually > calling skip* helper functions >      whenever appropriate > > With current state of new-pm PassInstrumentation potential OptBisect > implementation > will ha...

...ide { > if (skipFunction(F)) > return false; > > // do pass > > } > > > > What's the right way to proceed with this? There are 50-100 calls to > skipFunction() in legacy passes. This doesn't even account for other types > of IR units, like skipModule(Module&). > > > > I suppose it's possible to manually go in and add in the same check in the > new passes, but that seems tedious (and how do you test that at scale? > clearly there aren't many tests for it right now since check-llvm passes > under the new pass mana...

...osed on the implementation. Kind of a summary of what we have now:   - There is a single OptBisect object, requested through LLVMContext     (managed as ManagedStatic).   - OptBisect is defined in lib/IR, but does use analyses,     which is a known layering issue   - Pass hierarchy provides skipModule etc helper functions   - Individual passes opt-in to OptBisect activities by manually calling skip* helper functions     whenever appropriate With current state of new-pm PassInstrumentation potential OptBisect implementation will have the following properties/issues:   - OptBisect object th...

...ic method like getCounterIdForName(std::string &Name) etc. - Use it to decide if this pass is required to be executed or not. - For new passmaager just before executing run() for a pass we can check this counter. - For legacy pass manager we can directly use this debug counter in skipFunction()/skipModule() etc method. - There is already FIXME: added for moving getDescription() from OptBisect class to respective IR units like Loop, Region etc. So that new pass manager can also use those methods. - However to support feature added in this https://reviews.llvm.org/D44464 we may need to add a callbac...

...Name(std::string > &Name) etc. > - Use it to decide if this pass is required to be executed or not. > - For new passmaager just before executing run() for a pass we can check > this counter. > - For legacy pass manager we can directly use this debug counter in > skipFunction()/skipModule() etc method. > - There is already FIXME: added for moving getDescription() from OptBisect > class to respective > IR units like Loop, Region etc. So that new pass manager can also use > those methods. > - However to support feature added in this https://reviews.llvm.org/D44464 &gt...

As a point of clarification, optnone is already being handled by the pass itself in the legacy implementation. The skip[IR unit] functions are provided by the pass base classes, and the attribute is checked there. This happens any time the legacy wrapper is run, no matter how it is run. Regarding the opt-bisect design, I’m not particularly fond of the managed static either, but I do want to

...of a summary of what we have now: > - There is a single OptBisect object, requested through LLVMContext > (managed as ManagedStatic). > > - OptBisect is defined in lib/IR, but does use analyses, > which is a known layering issue > > - Pass hierarchy provides skipModule etc helper functions > > - Individual passes opt-in to OptBisect activities by manually calling > skip* helper functions > whenever appropriate > > With current state of new-pm PassInstrumentation potential OptBisect > implementation will have the following properties/i...

...t we have now: >    - There is a single OptBisect object, requested through LLVMContext >      (managed as ManagedStatic). > >    - OptBisect is defined in lib/IR, but does use analyses, >      which is a known layering issue > >    - Pass hierarchy provides skipModule etc helper functions > >    - Individual passes opt-in to OptBisect activities by manually > calling skip* helper functions >      whenever appropriate > > With current state of new-pm PassInstrumentation potential > OptBisect implementation will have the fo...

...ool runOnModule(Module &M) override; + + void getAnalysisUsage(AnalysisUsage &AU) const override { + AU.addRequired<BlockFrequencyInfoWrapperPass>(); + AU.addRequired<BranchProbabilityInfoWrapperPass>(); + } +}; + +bool CFGProfilePass::runOnModule(Module &M) { + if (skipModule(M)) + return false; + + llvm::DenseMap<std::pair<StringRef, StringRef>, uint64_t> Counts; + + for (auto &F : M) { + if (F.isDeclaration()) + continue; + getAnalysis<BranchProbabilityInfoWrapperPass>(F).getBPI(); + auto &BFI = getAnalysis<BlockFrequenc...