llvm dev - Mar 2006 - [LLVMdev] problem loading analysis results from Inliner pass

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

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/

On Tue, 21 Mar 2006, Michael McCracken wrote:
> 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.
ok
> Module Pass Manager
>  PMF File Loader
> --PMF File Loader
>  Raise allocations from calls to instructions
> --Raise allocations from calls to instructions
...
> ModulePass. On changing the real pass to an ImmutablePass, I get the
> behavior I expected.  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.
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.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/

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

-- 
http://nondot.org/sabre/
http://llvm.org/