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

[Xinliang David Li via llvm-dev]

On Tue, Jul 12, 2016 at 10:57 PM, Chandler Carruth <chandlerc at gmail.com>
wrote:

> 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
> address.
>

We can call this type of dependencies (holding references) hard-dependency.
The soft dependency refers to the case where analysis 'A' depends on 'B'
during computation, but does not need 'B' once it is computed.

There are actually quite a few examples of hard-dependency case. For
instance LoopAccessInfo, LazyValueInfo etc which hold references to other
analyses.

Problem involving hard-dependency is actually easier to detect, as it is
usually a compile time problem. Issues involving soft dependencies are more
subtle and can lead to wrong code gen.

David



>
> 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
> call.
>
> 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/20160712/5234bf09/attachment.html>