[LLVMdev] Queries of an invalidated AA ModulePass

[Will Dietz]

Hi all,

While working on a loadable Alias Analysis module pass, I'm running
into the following issue:

I'm finding my pass queried for results after it has had
'releaseMemory' called on it and its dependencies, but before
runOnModule is called again (on my pass or its deps).  As you might
expect, this makes my pass rather unhappy (and I think correctly so).

This happens with LICM and it's use of AliasSetTracker, here's an
excerpt from opt -debug-pass=Executions.  The rest of the options
passed to opt are every pass from -O3 with -ds-aa before it... :).  Ah
and this is llvm 2.7:

0xd9f7400      Freeing Pass 'Natural Loop Information' on Function 'main'...
0xd9f7400      Freeing Pass 'Dominance Frontier Construction' on
Function 'main'...
0xd9f7400      Freeing Pass 'Standard Library Local Data Structure
Analysis' on Function 'main'...
**********
0xd9f7400      Freeing Pass 'Data Structure Graph Based Alias
Analysis' on Function 'main'...
**********
0xd9f7400      Freeing Pass 'Identify EntryPoints' on Function 'main'...
0xd9f7400      Freeing Pass 'Dominator Tree Construction' on Function 'main'...
0xd9f7400      Freeing Pass 'Bottom-up Data Structure Analysis' on
Function 'main'...
0xd9f7400      Freeing Pass 'Top-down Data Structure Analysis' on
Function 'main'...
0xd9f7400      Freeing Pass 'Local Data Structure Analysis' on
Function 'main'...
0xd9f7400     Executing Pass 'Dominator Tree Construction' on Function
'freetree'...
0xd9f7400     Executing Pass 'Natural Loop Information' on Function
'freetree'...
0xd9f7400     Executing Pass 'Loop Pass Manager' on Function 'freetree'...
0xd9f7a40       Executing Pass 'Canonicalize natural loops' on Loop 'bb2'...
0xd9f7a40        Freeing Pass 'Canonicalize natural loops' on Loop 'bb2'...
0xd9f7400     Executing Pass 'Dominance Frontier Construction' on
Function 'freetree'...
0xd9f7400     Executing Pass 'Loop Pass Manager' on Function 'freetree'...
0xd9bfa70       Executing Pass 'Canonicalize natural loops' on Loop 'bb2'...
0xd9bfa70       Executing Pass 'Loop Invariant Code Motion' on Loop 'bb2'...
opt: /home/vadve/wdietz2/llvm27/llvm/projects/poolalloc/lib/DSA/DataStructureAA.cpp:203:
virtual llvm::AliasAnalysis::ModRefResult<unnamed>::DSAA::getModRefInfo(llvm::CallSite,
llvm::Value*, unsigned int): Assertion `valid && "AA invalidated but
then queried?!"' failed.


Note that "DSAA" is in fact a module pass, and so the line (marked
with stars above)
0xd9f7400      Freeing Pass 'Data Structure Graph Based Alias
Analysis' on Function 'main'...

(Outside the scope of this excerpt it has executed and freed DSAA many
times--but always with respect to a module, not a function)

Which calls releaseMemory, but note that it never runs "Data Structure
Graph Based Alias Analysis" before running LICM, which has the
analysis usage requirement of
      AU.addRequired<AliasAnalysis>();
Additionally I want to point out that it frees the analysis (and it's
deps) for function 'main' but apparently assumes its still valid for
function 'freetree'?  However DSAA and it's deps (TDSA, BUDSA) are all
modulepasses, so there is no concept of invalidating it just for a
particular function....

I apologize for the long (and potentially confusing) nature of this
request.... hopefully you're with me still.

As for what to do about this, that's what I'm hoping you good folk
might have some ideas.  Is this a bug?  What might be done about this?
 Am I misunderstanding something/doing something wrong?

While I'm at it, a related question.  The wording from
http://llvm.org/docs/WritingAnLLVMPass.html#releaseMemory suggests
that you can count in PassManager calling 'releaseMemory' before
calling the next run* method.  Is this a strict requirement?  Working
around this is easy, but I suppose I'm asking if that's not the
behavior I see is that something I should mention?

As always, thanks for your time,

~Will Dietz