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

[Sean Silva via llvm-commits]

On Mon, Aug 8, 2016 at 11:34 PM, Chandler Carruth <chandlerc at gmail.com>
wrote:

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

Okay, I'll take a break from this PM stuff for a month or so.

-- Sean Silva


>
> 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/4401882d/attachment.html>