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

[Chandler Carruth via llvm-dev]

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

> On Tue, Jul 12, 2016 at 9:00 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>
>> I think that (2) is the right answer, but I'm not sure that the dance
>> needs to be all that complicated. Each analysis can contain a list (small
>> vector) of other analysis that depend on it, and the interface to get an
>> analysis can take a pointer to add to this list. When an analysis is
>> invalidated, the manager can queue the invalidation of the others in the
>> list.
>>
>
> At least with the current arrangement, there is not just one
> AnalysisManager, but rather one per IRUnitT (with the
> <X>AnalysisManager<Y>Proxy analyses to go between them). So a pointer to
> the analysis is not enough; you also need a pointer to the AnalysisManager
> that is caching the result of that analysis. Since the invalidation method
> is actually typed to take the IRUnitT, you now need a way to store a
> reference to the other analysis manager in a type-erased way (since e.g. a
> function analysis can depend on a module analysis or vice versa).
>
> It's sort of hairy and potentially requires quite a bit of storage
> (relative to the other PM data structures). E.g. a module analysis that
> queries various function analyses on each function will create
> O(NumFunctionPassesUsed * NumFunctionsInModule) back pointers to itself.
> Also, what happens if the module analysis is invalidated? Do we need to
> store even more pointers from the module analysis back to the function
> analyses so that it can "unregister" itself as a dependency?
>
> Having a single AnalysisManager that stores analyses for all the different
> IRUnitT's might somewhat simplify this, but it would still be pretty
> complicated I think.
>

Yea, I largely agree. I'd try out overriding the invalidate method and
triggering on the necessary set first, and see how that goes before we go
down this road.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160713/f4911401/attachment.html>