search for: cfgonly

Hi, You need to initialize your pass with: INITIALIZE_PASS_BEGIN(YourPass, "your-pass", "Your Pass", /*cfgonly=*/false, /*analysis=*/false) INITIALIZE_PASS_DEPENDENCY(PostDominatorTreeWrapperPass) INITIALIZE_PASS_END(YourPass, "your-pass", "Your Pass", /*cfgonly=*/false, /*analysis=*/false) So as to both register your pass, and have PostDominatorTreeWrapperPass (which is the Analysis pa...

Hi everyone, I write a new FunctionPass which wants to use pass PostDominatorTree, so I implement the next function: void getAnalysisUsage(AnalysisUsage &AU) const { AU.addRequired<PostDominatorTree>(); AU.setPreservesAll(); } Then I get PDT through the next statement: PostDominatorTree *PDT = &getAnalysis<PostDominatorTree>(); My code can be successfully

Hi! On 12/03/2009 07:50 PM, 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->spli...

...now, what you need to know is that these classes are going away, and are being replaced with a new macro INITIALIZE_PASS(). I will be applying this change to LLVM HEAD shortly. You can update you code as follows: static RegisterPass<GVN> X("arg", "My Pass's Name", CFGOnly, IsAnalysis); becomes: INITIALIZE_PASS(GVN, "arg", "My Pass's Name", CFGOnly, IsAnalysis); For the moment, these are equivalent, but as the work progresses on this front, RegisterPass will go away and INITIALIZE_PASS will be changed to expand to the right thing for the ne...

...e asssert stmt to use it? -------------- next part -------------- ;; 1st PassInfo (this=0x2aaaac3472a0, name=0x2aaaabe24421 "Target Data Layout", arg=0x2aaaabe24434 "targetdata", pi=17004736, normal=0xada74e <llvm::Pass* llvm::callDefaultCtor<llvm::TargetData>()>, isCFGOnly=false, is_analysis=true) at /home/xliu/dev/llvm/include/llvm/PassSupport.h:59 (gdb) bt #0 PassInfo (this=0x2aaaac3472a0, name=0x2aaaabe24421 "Target Data Layout", arg=0x2aaaabe24434 "targetdata", pi=17004736, normal=0xada74e <llvm::Pass* llvm::callDefaultCtor<llvm::Target...

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); > + } &g...

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

Any comments at all on this? Chandler perhaps? I've since dug a bit further, and it seems like the template-based solution wouldn't work anyway because DLL loading on Windows can't do the required commoning. So the general approach taken in https://reviews.llvm.org/D62802 seems to be the only technically viable path forward, though it would still be good to get an outside look at the