[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
Wed Jul 13 01:50:16 PDT 2016

On Wed, Jul 13, 2016 at 1:40 AM Sean Silva <chisophugis at gmail.com> wrote:

> On Wed, Jul 13, 2016 at 12:39 AM, Hal Finkel <hfinkel at anl.gov> wrote:
>> Interesting. I'm not sure this is the right metric, however. There are
>> lots of analyses that hold pointers to other analyses but don't need to.
>> The analysis handle itself can be reacquired lazily if we care to do so.
> Are you thinking of instead holding a pointer to the analysis manager?

I'm really concerned with using this approach as the common case. It
triggers the run of the analyses at very strange points (mid-query of some
other analysis) and forces us to pay the analysis manager lookup overhead
on every query. For many analyses, this overhead is larger than the actual

There may be cases where this is the only sane way to manage things, but
this should be the exception rather than the rule IMO.

>> What's truly problematic is holding pointers into another analysis's data
>> structures. To be concrete, holding a pointer to ScalarEvolution is not a
>> fundamental problem because we could make the analysis reacquire the
>> pointer at the start of every query. Holding SCEV* is the problem.
> Looks like SCEV* at least is held only by LoopAccessInfo. (Looks like LAA
> holds Loop* too)

Note that Loop (and SCC) are somewhat special as they are IRUnitTs and
might as a consequence be more reasonable to hold on to and expect
definitive invalidation to occur. But I say "might". I think this will be
case-by-case depending on how they're being used.

> New updated rendering at http://reviews.llvm.org/F2161258
> (DependenceAnalysis was missing some edges in my previous rendering and I
> didn't have and I've added LoopAccessAnalysis; I've updated
> http://reviews.llvm.org/P6603). Which other analyses vend data objects
> that others might hold pointers to?

SCEV, Loop, SCC, DomTreeNode, and Region leap immediately to mind. and 3 of
those are what would be IRUnitTs (Region being the third, and its weird and
likely won't be in the new PM ever).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160713/c042b6b6/attachment.html>

More information about the llvm-dev mailing list