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

[Hal Finkel via llvm-dev]

----- Original Message -----

> From: "Chandler Carruth" <chandlerc at gmail.com>
> To: "Hal Finkel" <hfinkel at anl.gov>, "Sean Silva"
> <chisophugis at gmail.com>
> Cc: "Xinliang David Li" <davidxl at google.com>, "llvm-dev"
> <llvm-dev at lists.llvm.org>, "Davide Italiano"
> <dccitaliano at gmail.com>, "Tim Amini Golling"
> <mehdi.amini at apple.com>, "Sanjoy Das"
> <sanjoy at playingwithpointers.com>, "Pete Cooper"
> <peter_cooper at apple.com>
> Sent: Wednesday, July 13, 2016 3:05:26 AM
> Subject: Re: [PM] I think that the new PM needs to learn about
> inter-analysis dependencies...

> 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. 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.
> 
> Agreed. I suspect this is the dominant pattern.

> > FWIW, I still think this is common enough to design a solution that
> > makes it easy to get this right.
> 
> I somewhat suspect that it would be better to pass these in along the
> query path rather than have results cache them. The reason is that
> if the user of the analysis is aware of the other analyses it
> depends on, it will also be aware of that cost and the reality of
> potentially wanting to preserve them.

> I'd be interested in us spending some time trying to make this
> refactoring and at least understanding how hard it is before we
> engineer a solution that makes the analysis management more complex.
I'm not too concerned about making analysis management more complex for this purpose; handling transitive analysis invalidation was always going to have been necessary. 

> So as you seemed to agree in your other email (sorry for the heavily
> branching thread) perhaps we should start with the potentially error
> prone approach now, and see how much iteration can move toward
> "nothing to do" by lifting things into the query path rather than
> the result object.
Yes, I'm happy to see where this goes. The more I think about it, the more I suspect that regardless of how easy the scheme is to use the main conceptual challenge will be remembering/knowing that it needs to be used. 

-Hal 

-- 

Hal Finkel 
Assistant Computational Scientist 
Leadership Computing Facility 
Argonne National Laboratory 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160713/1e9d3853/attachment.html>