[LLVMdev] problem loading analysis results from Inliner pass

Michael McCracken michael.mccracken at gmail.com
Wed Mar 22 20:11:49 PST 2006


>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.

On 3/21/06, Chris Lattner <sabre at nondot.org> wrote:
> On Tue, 21 Mar 2006, Michael McCracken wrote:
> > 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.
>
> -Chris

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?

Thanks,
-mike

--
Michael McCracken
UCSD CSE PhD Candidate
research: http://www.cse.ucsd.edu/~mmccrack/
misc: http://michael-mccracken.net/wp/




More information about the llvm-dev mailing list