[LLVMdev] problem loading analysis results from Inliner pass

[Michael McCracken]

A

On 3/21/06, Michael McCracken <michael.mccracken at gmail.com> wrote:
> On 3/21/06, Chris Lattner <sabre at nondot.org> wrote:
> > On Mon, 20 Mar 2006, Michael McCracken wrote:
> >
> > > Hi, I'm trying to access an analysis pass from the Inliner pass, and
> > > I'm having a lot of trouble getting that to work - I can verify that
> > > my pass is loaded and run (it is a dynamically loaded pass that is
> > > part of an analysisgroup), however, when I access it using
> > > getAnalysis<> from within Inliner::runOnSCC, I am instead getting the
> > > default, dummy version of my analysis, which should be overridden by
> > > the one that was brought in with -load.
> >
> > What sort of pass is it?  The inliner is a ModulePass, so the only thing
> > it can getAnalysis<> are modulepasses and immutablepasses: functionpasses
> > won't work.
>
> My pass is a ModulePass, although it's actually just an interface to
> external data, so I suppose it could potentially be an ImmutablePass.
> I've been meaning to revisit that, but it wasn't a high priority as
> long as it was working.
>
> ...snip...
> >
> > > This arrangement of analysis passes has worked in the past, and the
> > > fact that my pass is loaded but not resolved correctly leads me to
> > > believe it isn't a platform issue, but I'm open to any suggestions.
> >
> > That's possible too, I don't really know.  I would guess that it's a
> > function pass which is getting killed before you pass runs.
> > -debug-pass=Structure should help figure out if that's the case.
>
> using -debug-pass=Structure does show me that my pass is loaded and
> killed immediately. Here's a sample. "Dummy PMF Interface" is the noop
> default implementation of the "PMFAnalysis" analysis group, while "PMF
> File Loader" is the real implementation that I'm interested in.
>
> Pass Arguments:  -pmf-load -raiseallocs -simplifycfg -mem2reg
> -globalopt -globaldce -ipconstprop -deadargelim -instcombine
> -simplifycfg -prune-eh -inline -argpromotion -raise -tailduplicate
> -simplifycfg -scalarrepl -instcombine -break-crit-edges -condprop
> -tailcallelim -simplifycfg -reassociate -loopsimplify -licm
> -instcombine -indvars -loop-unroll -instcombine -load-vn -gcse -sccp
> -instcombine -break-crit-edges -condprop -dse -mergereturn -adce
> -simplifycfg -deadtypeelim -constmerge -verify
> Target Data Layout
> Dummy PMF Interface
> Basic Alias Analysis (default AA impl)
> Basic Value Numbering (default GVN impl)
> Module Pass Manager
>   PMF File Loader
> --PMF File Loader
>   Raise allocations from calls to instructions
> --Raise allocations from calls to instructions
>   Function Pass Manager
>     Simplify the CFG
> --  Simplify the CFG
>     Immediate Dominators Construction
>     Dominator Tree Construction
> --  Immediate Dominators Construction
>     Dominance Frontier Construction
>     Promote Memory to Register
> --  Dominance Frontier Construction
> --  Dominator Tree Construction
> --  Promote Memory to Register
>   Global Variable Optimizer
> --Global Variable Optimizer
>   Dead Global Elimination
> --Dead Global Elimination
>   Interprocedural constant propagation
> --Interprocedural constant propagation
>   Dead Argument Elimination
> --Dead Argument Elimination
>   Function Pass Manager
>     Combine redundant instructions
> --  Combine redundant instructions
>     Simplify the CFG
> --  Simplify the CFG
>   Call Graph Construction
>   Remove unused exception handling info
> --Remove unused exception handling info
>   Function Integration/Inlining
> --Function Integration/Inlining
>   Promote 'by reference' arguments to scalars
> --Promote 'by reference' arguments to scalars
> --Call Graph Construction
>   Function Pass Manager
> ... continues...
>
> That's on my linux box - on darwin, a similar (but not exactly the
> same) set of passes yields the expected result, where PMF File Loader
> is alive for the whole sequence.
>
> I had just written a more detailed version of this email when I
> realized that the dummy pass and the real pass were not the exact same
> type - the dummy was an ImmutablePass and the real pass was a
> ModulePass. On changing the real pass to an ImmutablePass, I get the
> behavior I expected.

Just some more information:

After a more thorough test, that isn't quite the case - since the
ImmutablePass is never 'run', my code needs modification to work.
However, I thought that maybe I could just make them both ModulePasses
instead, but that produces the following runtime error:

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.

-mike

> A quick scan of the docs doesn't say anything
> about the members of a group needing to be the same kind of pass - is
> that really the case? It does make sense, but maybe there ought to be
> a way to catch this automatically, at least in debug builds?
> Admittedly, it seems like a pretty unlikely problem, but it was
> confusing.
>
> 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.
>
> Thanks,
> -mike
>
> --
> Michael McCracken
> UCSD CSE PhD Candidate
> research: http://www.cse.ucsd.edu/~mmccrack/
> misc: http://michael-mccracken.net/wp/
>


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