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

Xinliang David Li via llvm-dev llvm-dev at lists.llvm.org
Wed Jul 13 09:53:11 PDT 2016


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

> On Wed, Jul 13, 2016 at 12:47 AM Xinliang David Li <davidxl at google.com>
> wrote:
>
>> On Tue, Jul 12, 2016 at 11:34 PM, Sean Silva <chisophugis at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Tue, Jul 12, 2016 at 11:32 PM, Xinliang David Li <davidxl at google.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Jul 12, 2016 at 10:57 PM, Chandler Carruth <chandlerc at gmail.com
>>>> > wrote:
>>>>
>>>>> Yea, this is a nasty problem.
>>>>>
>>>>> One important thing to understand is that this is specific to analyses
>>>>> which hold references to other analyses. While this isn't unheard of, it
>>>>> isn't as common as it could be. Still, definitely something we need to
>>>>> address.
>>>>>
>>>>
>>>> We can call this type of dependencies (holding references)
>>>> hard-dependency. The soft dependency refers to the case where analysis 'A'
>>>> depends on 'B' during computation, but does not need 'B' once it is
>>>> computed.
>>>>
>>>> There are actually quite a few examples of hard-dependency case. For
>>>> instance LoopAccessInfo, LazyValueInfo etc which hold references to other
>>>> analyses.
>>>>
>>>> Problem involving hard-dependency is actually easier to detect, as it
>>>> is usually a compile time problem. Issues involving soft dependencies are
>>>> more subtle and can lead to wrong code gen.
>>>>
>>>
>>> Did you mean to say that soft-dependency problems are easier to detect?
>>> At least my intuition is that soft-dependency is easier because there is no
>>> risk of dangling pointers to other analyses.
>>>
>>
>> I meant it is harder to detect.  If 'A' soft-depends on 'B', when 'B'
>> gets invalidated, but 'A' survives (can be used without compile time
>> problem such as dangling pointer) -- we don't really  know if 'A' is in
>> fact still in valid state -- as it may need to be recalculated too.
>>
>
> The only way that 'A' is still around is if a pass *specifically* said it
> preserved 'A'. So I think it is reasonable to say that even if 'B' is gone,
> 'A' remains trustworthy here.
>


This can be problematic in other ways -- wrong assumption made by the pass
writer, i.e. 'A' is preserved even though 'B' can be invalidated. But this
is a different issue.

David


>
> The issue with the "hard dependency" that Sean pointed out is that there
> are analyses which are trivial to update, but somewhat incidentally have
> references to other analyses stashed away that are no longer valid. This
> isn't actually a "hard dependency", in that there is no fundamental reason
> why this layering was enforced.
>
> Yet another reason to prefer passing auxiliary analyses into the query
> path rather than modeling these as transitive invalidation is dramatically
> less invalidation.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160713/23403e2e/attachment.html>


More information about the llvm-dev mailing list