By default, all passes invalidate all other passes of their type or more
granular. In this case, what's going on is that all of the module passes
are implicitly invalidating the results of "PMF File Loader". Marking it
immutable will do what you want (nothing will ever invalidate it because
it's immutable) but make sure this really is what you want
> I'll also try to replicate the exact same conditions on darwin to see
> if the platform makes a difference, since I didn't run into this
> problem until moving to linux.
If it did, that would be a SERIOUS bug.
OK, it does the same things on darwin, so it's not platform related.
> opt: /home/mmccrack/lens/obj-llvm-darcslocal/../llvm-darcslocal/llvm/lib/VMCore/PassManagerT.h:426:
> void llvm::PassManagerT<UnitType>::markPassUsed(const llvm::PassInfo*,
> llvm::Pass*) [with UnitType = llvm::Module]: Assertion
> `getAnalysisOrNullUp(P) &&
> dynamic_cast<ImmutablePass*>(getAnalysisOrNullUp(P)) && "Pass
> available but not found! " "Perhaps this is a module pass requiring a
> function pass?"' failed.
> Which is also unexpected. I think for now I will attempt to make my
> pass work as Immutable, but I'm still curious why having both be a
> ModulePass gets this error, where both as an ImmutablePass is OK for
> the PassManager and one of each is also OK. Strange, but maybe I'm
> missing something.
It is hard for me to say without more information. Make sure you don't
have an immutable pass requiring a modulepass or something like that.
OK, I think I can summarize the situation better now:
What I have is an analysisgroup with one immutable pass member and one
module pass member - admittedly, this is nonsensical, so I'll be
making them both immutable, but this is to satisfy my curiousity, and
I think there might still be something sketchy going on here. Neither
of those analyses required any other passes.
When I had the heterogeneous analysis group, but only function passes
were requiring the group, everything worked as expected - the real
pass, a module pass could get loaded and be used instead of the dummy
pass, not invalidated early, and no crashes.
When I made the change of having an CallGraphSCCPass (the inliner)
require my analysis group, that's when I noticed the problems. With
that change, the modulepass member of the analysis group would be
invalidated immediately (I'm still not sure why this happens as a
result of what is requiring the pass), and the pass that required it
would get a bad pointer out of getAnalysis.
When I change both members of the analysis group to module passes,
that's when I get the assertion failure "Pass available but not found"
/ "perhaps this is a modulepass requiring a functionpass?", although
the only changes I made is to add one edge from a CallgraphSCCPass to
an AnalysisGroup, both members of which are now ModulePasses.
note: the assertion failure happens while building LLVM, in the
bytecode-library compilation phase, so it is happening when my 'real'
pass is not loaded.
So, having a heterogeneous AnalysisGroup is probably always wrong, and
I guess we might want to check for it at registration time. However, I
don't see what is wrong with having a CallgraphSCCPass require an
analysis group with one ModulePass. That doesn't seem to be a case of
a higher-granularity pass requiring a lower-granularity pass, but is
it a similar limitation of the current Pass Manager?