[PATCH] D21462: [PM] Make the the new pass manageg support fully generic extra arguments to run methods, both for transform passes and analysis passes.

[Chandler Carruth via llvm-commits]

On Thu, Aug 4, 2016 at 3:38 AM Sean Silva via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> The subsequent discussion also contained Hal saying:
> "I'll go back to my previous position: we need a general dependency graph
> built as the analysis cache is used"
> http://lists.llvm.org/pipermail/llvm-dev/2016-July/102333.html
>
> With Mehdi replying
> "I share the same feeling."
> http://lists.llvm.org/pipermail/llvm-dev/2016-July/102334.html
>
> And no objection from you.
>

Silence is not agreement.

Your only post later on this topic was:
> http://lists.llvm.org/pipermail/llvm-dev/2016-July/102339.html
> which was largely about terminology, and some hand-waving of solutions
> which I explained were inadequate:
> http://lists.llvm.org/pipermail/llvm-dev/2016-July/102346.html
>
> And again, you did not provide any response.
>

That doesn't mean I agree with your analysis.


>
> Just because we could hypothetically refactor a large part of the codebase
> to avoid some specific instances of the issue doesn't mean that we don't
> need to solve it. And if we need to solve it anyway, then the argument for
> doing such a refactoring is quite weak, since it isn't needed.
>

Not necessarily. I presented specific reasons why I think this refactoring
would be beneficial in general. And knowing how widespread a pattern is
does influence the technique best used to address the problem.


>
>> I continue to think the plan at the bottom of that message is the correct
>> way forward until we do the mentioned refactorings of analyses and some of
>> the infrastructure stabilizes.
>>
>
> There are a few cases for which it is not sufficient to just pass in
> through the query path.
> Also, it's not clear if this is feasible e.g. for AA where different AA's
> have different information needed by their query paths.
>

Yes, I suspect there are some cases where this isn't the appropriate
technique. But what remains to be seen IMO is what those cases look like
and what the best technique would be in the face of some of these being
refactored as I have suggested.


> Also, are you suggesting that we need to modify every query of each of the
> following analyses before the new PM can be used with basic confidence that
> there aren't going to be use-after-free errors?
>

No, I suggested that we work-around the issues with the (admittedly error
prone) manual invalidation until we could do these refactorings and
evaluate the best path forward.

However, I suspect there is a *very small* bug that makes the manual
invalidation not work. I would like to fix that, but I've been focused (at
your and others' request) at finishing the CG-related work.

But even then, this list:

BFI
> SCEV
> BasicAA
> LVI
> DemandedBits
> MemDep
> MemorySSA
> SCEVAA
> LoopAccessAnalysis
> DependenceAnalysis
>

Does not actually scare me. It's a lot, but it is tractable IMO.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160809/f69e7e19/attachment.html>