"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 another pass, the required pass sticks around. The > last user is the last pass that required some other particular pass. > It appears in your case that F requires A and C. The PassManager will > indicate that F is the last user of A. The fact that C doesn't > preserve A is seemingly meaningless. Therefore A will be run, > followed by C, followed by F.That's just broken. But I had come to a similar conclusion over the weekend. The obvious question is, if I remove the dependency from F how do I guarantee the information is available when it runs?> This brings up a question I had about the meaning of "preserve". Some > places I read (here on the mailing list + the docs) seem to indicate > that preserving is about keeping something around because you may want > to use it again. While other places seem to indicate that it is about > whether a pass is invalidated. These are very two different things, > and, as far as I can tell, the code seems to implement neither of > these ideas.Spot on.> To solve your issue, can you use a barrier pass? This might force the > passes to re-run when you need them.What's a barrier pass? -David
<dag at cray.com> writes:>> To solve your issue, can you use a barrier pass? This might force the >> passes to re-run when you need them. > > What's a barrier pass?Ah. We haven't upgraded to that version of LLVM yet (but it's in the works!). For the record and mailing-list posterity, I was able to fix the problem by removing setPreservesCFG from pass E. That's just a huge ugly kludge but it's good enough for this case. -David
> To solve your issue, can you use a barrier pass? This might force the > passes to re-run when you need them.What's a barrier pass? /lib/Transforms/IPO/BarrierNoopPass.cpp
----- Original Message -----> From: dag at cray.com > To: llvmdev at cs.uiuc.edu > Sent: Monday, April 21, 2014 12:08:22 PM > Subject: Re: [LLVMdev] PassManager Woes > > <dag at cray.com> writes: > > >> To solve your issue, can you use a barrier pass? This might force > >> the > >> passes to re-run when you need them. > > > > What's a barrier pass? > > Ah. We haven't upgraded to that version of LLVM yet (but it's in the > works!).If you need, backporting the barrier pass should be trivial. It does not really do anything special, just its existence forces later passes to "break out" from any preceding CGSCC pass manager. -Hal> > For the record and mailing-list posterity, I was able to fix the > problem > by removing setPreservesCFG from pass E. That's just a huge ugly > kludge > but it's good enough for this case. > > -David > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory