[llvm-dev] [PM] I think that the new PM needs to learn about inter-analysis dependencies...

Chandler Carruth via llvm-dev llvm-dev at lists.llvm.org
Tue Jul 12 22:57:10 PDT 2016

Yea, this is a nasty problem.

One important thing to understand is that this is specific to analyses
which hold references to other analyses. While this isn't unheard of, it
isn't as common as it could be. Still, definitely something we need to

Some ideas about mitigating and fixing it below.

On Tue, Jul 12, 2016 at 6:15 PM Sean Silva <chisophugis at gmail.com> wrote:

> How should we solve this? I see two potential solutions:
> 1. Analyses must somehow list the analyses they depend on (either by
> overriding "invalidate" to make sure that they invalidate them, or
> something "declarative" that would allow the AnalysisManager to walk the
> transitive dependencies).

I think this is the right approach. I would personally start by overriding
the invalidate callback everywhere that it is necessary, and see how bad
that becomes.

If it becomes common and burdensome, then we can change the way
invalidation works such that the analysis manager is aware of the preserved
analysis set in more detail, and have it build up the necessary data
structures to know in-advance whether it must make an explicit invalidate

However, I suspect this may not be *too* bad for two reasons:

a) As I mentioned above, I'm hoping there aren't *too* many handles between
different analyses. But I've not done a careful examination, so we can
check this.

b) For many analyses that might trigger this, I think we have a simpler
option. If the analysis is *immutable* for any reason -- that is, it
overrides its invalidate routine to always return "false" the way
TargetLibraryInfo should (although I'm not sure it does currently), we
shouldn't need to do this as it shouldn't be getting cleared out. Does this
make sense? Do others see anything I'm missing with that approach?

2. The AnalysisManager must do a somewhat complicated dance to track when
> analyses call back into it in order to get other analyses.

I would really rather avoid this, as currently the analysis manager's logic
here is very simple, and in many cases we only need the analyses to
*compute* our result, not to embed it. I'm tihnking of stuff like
Dominators is used to build LoopInfo, but there isn't a stale handle there.

There is another aspect of course in that if something is preserving
LoopInfo, it really should be preserving Dominators too...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160713/7abe809b/attachment.html>

More information about the llvm-dev mailing list