On Fri, Apr 29, 2005 at 08:10:17AM -0500, Chris Lattner wrote:> AU.addRequiredID(LoopSimplifyID); > > "LoopSimplifyID" is a marker that is used to identify the pass, which is > exported from the .cpp file.I'll have to declare a PassInfo* called LoopSimplifyID inside namespace llvm, in order for that to compile correctly, right? I was wondering why not simply make it available for AU.addRequired instead. I guess that AU.addRequired will not be sufficient because LoopSimplify is not an analysis that the PassManager can update when some other pass changes the CFG. So the only way for my pass to ensure that the loops are simplified is to explicitly invoke LoopSimplify ... is that correct? Sameer. -- Research Scholar, KReSIT, IIT Bombay http://www.it.iitb.ac.in/~sameerds/
On Fri, 29 Apr 2005, Sameer D. Sahasrabuddhe wrote:> On Fri, Apr 29, 2005 at 08:10:17AM -0500, Chris Lattner wrote: > >> AU.addRequiredID(LoopSimplifyID); >> >> "LoopSimplifyID" is a marker that is used to identify the pass, which is >> exported from the .cpp file. > > I'll have to declare a PassInfo* called LoopSimplifyID inside > namespace llvm, in order for that to compile correctly, right? I was > wondering why not simply make it available for AU.addRequired instead.It's already available by #including llvm/Transforms/Scalar.h. For example see lib/Transforms/Scalar/LICM.cpp which requires loop simplify.> I guess that AU.addRequired will not be sufficient because > LoopSimplify is not an analysis that the PassManager can update when > some other pass changes the CFG. So the only way for my pass to ensure > that the loops are simplified is to explicitly invoke LoopSimplify ... > is that correct?We could definitely expose the pass class itself, but there are no implementation details or any other state that is useful. Following the principle of information hiding, it seemed better just to expose the fact that we need the loops to be simplified rather than to tightly couple the users to the class definition. -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/
On Fri, Apr 29, 2005 at 10:32:18PM -0500, Chris Lattner wrote:> We could definitely expose the pass class itself, but there are no > implementation details or any other state that is useful.Yeah ... this, and Transforms/Scalar.h answer my original original question about why a lot of passes are present as a single CPP. The whole LLVM code generally abhors including class definitions through header files unless absolutely necessary. It's taking me a little effort to get used to that, but it should turn out to be a Good Thing(tm) after all. But the problem is that the presence and the significance of Scalar.h was not immediately obvious! Sameer. -- Research Scholar, KReSIT, IIT Bombay http://www.it.iitb.ac.in/~sameerds/