[LLVMdev] Queries of an invalidated AA ModulePass

[Will Dietz]

On Tue, Jun 29, 2010 at 1:41 PM, Dan Gohman <gohman at apple.com> wrote:
> My best guess is that the problem is that loopsimplify (Canonicalize
> natural loops) doesn't preserve DSAA. It preserves AliasAnalysis, but as
> docs/AliasAnalysis.html now mentions, this doesn't actually do anything.
> And DSAA clobbers loopsimplify, because the pass manager can't
> keep a LoopPass live across a ModulePass run. Given these constraints,
> it's not possible for the pass manager to set up LICM's prerequisites.
>

Thanks for the reply.

If I'm understanding you correctly--LICM's prerequisites (perhaps
because preserving AA doesn't do anything/work) are presently
impossible to satisfy (when the AA is a modulepass) and as such
PassManager tries to run it without its requirements satisfied and
hopes for the best?
Or put a different way, LICM and its deps just plain don't work with
AA implemented as a modulepass?
(Out of curiosity is there a reason this kind of situation doesn't
result in some "unable to satisfy pass requirements" assertion?
Complexity?)

Looking at the bug tracker (for whatever reason I only searched open
bugs before), this looks relevant:

http://llvm.org/bugs/show_bug.cgi?id=3323

So it appears it's known and understood but not fixed because no one
need it yet...which is understandable.  I imagine that puts this in
"patches welcome" territory?

>> 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?
>
> It's a design intent, at least. If you have cases where it doesn't
> work, please report them.
>

Will do, thanks.

~Will