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

Sean Silva via llvm-dev llvm-dev at lists.llvm.org
Wed Jul 13 02:02:05 PDT 2016

On Wed, Jul 13, 2016 at 1:50 AM, Chandler Carruth <chandlerc at gmail.com>

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

Yeah, the overhead is my main concern. (also, this would be very difficult
to coexist with the old PM so at least in the immediate future isn't an

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

Looking around a bit:
Looks like DomTreeNode isn't held by anything currently.
Pointers to Loop are only held by LAA as far as I can tell.
CallGraphSCC objects are only used by GlobalsAA but only for a
"recalculate" step.
Region's data structures don't seem to be held by anything.

So it seems like LAA is the main offender in this regard.

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160713/ba543b71/attachment.html>

More information about the llvm-dev mailing list