similar to: [LLVMdev] PassManager Dependence Question

On Friday 19 September 2008 17:11, David Greene wrote: > What I'd really like to do is have Pass X re-run but not Pass Y. Pass Y > only uses some bookkeeping from Pass X to speed itself up. Having Pass X > not re-run could cause Pass Y to give wrong answers, but once Pass X is > up-to-date, Pass Y will be fine. To make this a bit more concrete: I noticed that the Verifier

On Sep 19, 2008, at 3:20 PM, David Greene wrote: > On Friday 19 September 2008 17:11, David Greene wrote: > >> What I'd really like to do is have Pass X re-run but not Pass Y. >> Pass Y >> only uses some bookkeeping from Pass X to speed itself up. Having >> Pass X >> not re-run could cause Pass Y to give wrong answers, but once Pass >> X is

On Friday 19 September 2008 17:28, Devang Patel wrote: > On Sep 19, 2008, at 3:20 PM, David Greene wrote: > > On Friday 19 September 2008 17:11, David Greene wrote: > >> What I'd really like to do is have Pass X re-run but not Pass Y. > >> Pass Y > >> only uses some bookkeeping from Pass X to speed itself up. Having > >> Pass X > >> not

On Sep 19, 2008, at 3:11 PM, David Greene wrote: > Let's say I have an analysis pass that's dependent on another > analysis pass > (getAnalysisUsage does the appropraite things). > > So Pass Y depends on Pass X. > > If some transformation pass depends on Pass Y and Pass Y has not been > invalidated by another other pass BUT Pass X _has_ been invalidated > by

On Sep 19, 2008, at 3:20 PM, David Greene wrote: > On Friday 19 September 2008 17:11, David Greene wrote: > >> What I'd really like to do is have Pass X re-run but not Pass Y. >> Pass Y >> only uses some bookkeeping from Pass X to speed itself up. Having >> Pass X >> not re-run could cause Pass Y to give wrong answers, but once Pass >> X is

On Sep 19, 2008, at 3:38 PM, David Greene wrote: >>> So I thought about adding a pass that simply numbers Instructions, >>> have >>> DominatorTrees depend on that pass and then the dominates() question >>> can just >>> return whether one Instruction number is > the other. >>> >>> The number will get out of date as soon as

On Friday 19 September 2008 17:50, Devang Patel wrote: > On Sep 19, 2008, at 3:38 PM, David Greene wrote: > >>> So I thought about adding a pass that simply numbers Instructions, > >>> have > >>> DominatorTrees depend on that pass and then the dominates() question > >>> can just > >>> return whether one Instruction number is > the

On Sep 19, 2008, at 4:03 PM, David Greene wrote: >> Well, one of the domiantor info interface is >> bool dominates(Instruction *A, Instruction *B); >> This will return invalid results. So yes, the info is dirty. > > Not right now it isn't. Right now dominators simply iterates through > instructions. Aha... OK. > In my proposed scheme, it would be dirty only

On Fri, Nov 20, 2009 at 6:54 AM, Andreas Neustifter <astifter-llvm at gmx.at> wrote: > > If I use  AU.addRequired<ProfileInfo>() in SelectionDAGISel.cpp the > wrong ProfileInfo is used. It uses the "No ProfileInfo" implementation > if ProfileInfo but not the one from ProfileInfoLoaderPass. (Which is > immediately discarded after creation.) > You need to

Hi all, I am implementing a new pass for LLVM which extends Call Graph SCCPass. I need DominatorTree Information when I get to individual function. I have added AU.addrequired<DominatorTree>() and AU.addRequired<DominanceFrontier>() in getAnalysisUsage() function. But, when I get to the pass, Pass Manager gives following runtime error Unable to schedule 'Dominator Tree

On Jul 27, 2007, at 3:39 PM, David Greene wrote: > On Friday 27 July 2007 15:15, Devang Patel wrote: > >> Now, if pass sequence is - ModuleLevelPass A, FunctionLevelPass B, >> ModuleLevelPass D, FunctionLevelPass C then >> >> For each Module >> run ModuleLevelPass A >> for each function in this module >> run FunctionLevelPass B >> run

On Friday 27 July 2007 15:15, Devang Patel wrote: > Now, if pass sequence is - ModuleLevelPass A, FunctionLevelPass B, > ModuleLevelPass D, FunctionLevelPass C then > > For each Module > run ModuleLevelPass A > for each function in this module > run FunctionLevelPass B > run ModuleLevelPass D > for each function in this module > run FunctionLevelPass C >

Thanks John. Does this solve the problem of analysis availability though? If I still have to run the function analyses manually, I might as well keep rolling with the CallGraphSCCPass. (I probably should have mentioned that this is what I’m using right now.) Félix > Le 2015-05-19 à 10:12:32, John Criswell <jtcriswel at gmail.com> a écrit : > > On 5/18/15 10:45 PM, Félix Cloutier

On Jul 26, 2007, at 11:25 AM, David Greene wrote: > On Thursday 26 July 2007 11:48, Devang Patel wrote: > >> If in register allocator you have requested another higher level pass >> after LiveVariableAnalysis pass then this may happen. > > Can you explain why this is so? I would assume that I could > declare Pass > dependencies in any order. The manual certainly

Hi all! On 11/20/2009 06:29 PM, Devang Patel wrote: > > On Fri, Nov 20, 2009 at 6:54 AM, Andreas Neustifter wrote: >> >> If I use AU.addRequired<ProfileInfo>() in SelectionDAGISel.cpp the >> wrong ProfileInfo is used. It uses the "No ProfileInfo" implementation >> if ProfileInfo but not the one from ProfileInfoLoaderPass. (Which is >>

On Feb 11, 2009, at 6:05 PM, kapil anand wrote: > Hi all, > > I am implementing a new pass for LLVM which extends Call Graph > SCCPass. I need DominatorTree Information when I get to individual > function. I have added AU.addrequired<DominatorTree>() and > AU.addRequired<DominanceFrontier>() in getAnalysisUsage() function. > > But, when I get to the pass,

On Friday 19 September 2008 18:16, Devang Patel wrote: > > No way I'm going to go through every Pass, check if it manipulates > > instructions, and update the numbering info if it does. I'd rather > > have > > dominators check whenther numbering is up-to-date and update the > > numbering > > itself if it's not, on-the-fly. > > Well, then pass

I just finished upgrading our LLVM to 2.4 and I immediately ran into a problem with dominance frontier calculation: llvm/lib/VMCore/PassManager.cpp:714: void llvm::PMDataManager::verifyDomInfo(llvm::Pass&, llvm::Function&): Assertion `0 && "Invalid dominator info"' failed. Strangely enough, the Pass running when the assert triggers is Dominance Frontier

John Criswell wrote: > ambika wrote: >> Here is getAnalysisUsage() i am using, >> >> void getAnalysisUsage(AnalysisUsage&AU) const { >> AU.setPreservesAll(); >> AU.addRequired<DominatorTree>(); >> } >> >> and then I use it as, >> >> >> bool ptrTest::runOnModule(Module&M) { >> >>

ambika wrote: > Here is getAnalysisUsage() i am using, > > void getAnalysisUsage(AnalysisUsage &AU) const { > AU.setPreservesAll(); > AU.addRequired<DominatorTree>(); > } > > and then I use it as, > > > bool ptrTest::runOnModule(Module &M) { > > DominatorTree &DT = getAnalysis<DominatorTree>(); > ...... >