[LLVMdev] problem loading analysis results from Inliner pass

Michael McCracken michael.mccracken at gmail.com
Tue Mar 21 14:28:25 PST 2006


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/




More information about the llvm-dev mailing list