about AnalysisUsage

Just noticed that quite a few passes like LoopSimplify are implemented
in a single .cpp file ... this makes it impossible to specify
LoopSimplify using the "addRequired" method. Was there any particular
reason to do it this way? I wouldn't mind doing the splitting myself,
though I am not using the CVS versions right now.

Also, it would be nice to have support for some sort of a
"addPreservedTransitive" method ... so that when a pass uses
"setPreservesCFG", other passes such as dominator analysis will be
automatically preserved too ...

Sameer.

Just noticed that quite a few passes like LoopSimplify are implemented
in a single .cpp file ... this makes it impossible to specify
LoopSimplify using the "addRequired" method. Was there any particular
reason to do it this way? I wouldn't mind doing the splitting myself,
though I am not using the CVS versions right now.

For this, just use:

    AU.addRequiredID(LoopSimplifyID);

"LoopSimplifyID" is a marker that is used to identify the pass, which is exported from the .cpp file.

Also, it would be nice to have support for some sort of a
"addPreservedTransitive" method ... so that when a pass uses
"setPreservesCFG", other passes such as dominator analysis will be
automatically preserved too ...

It would be nice, however, if you pass doesn't modify the CFG (even if it uses loop simplify) just say so. If it does, then you will have to explicitly update all of the data structures you want to preserve...

-Chris

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.

    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

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.

Sameer,

This through me for a loop the first time that I saw it as well. But,
there is a method to the madness. LLVM *really* encapsulates things and
does so to the point of not making external symbols for things that
don't need to be. This saves link time and some object file bloat
(except for debug symbols). For its size, an optimized version of any of
the tools links pretty quickly, compared to other C++ programs I know of
this magnitude. The encapsulation also prevents inheritance mistakes and
rampant featurism.

Reid