[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