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

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.

I'm having a hard time debugging this, so any tips for how to track
the problem down would be appreciated.

I am running on Linux, and the version of LLVM I am working with is
from CVS a couple of months ago, so if this sounds like a problem
that's been solved already, it might be - that'd be good news.

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.

Thanks, and let me know if any more details would be helpful,
-mike

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

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.
> I'm having a hard time debugging this, so any tips for how to track
> the problem down would be appreciated.
Try passing -debug-pass=Structure to opt.
> I am running on Linux, and the version of LLVM I am working with is
> from CVS a couple of months ago, so if this sounds like a problem
> that's been solved already, it might be - that'd be good news.
It doesn't sound familiar.
> 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.

-Chris

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

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/