[PATCH] D9375: An llvm.noalias intrinsic

[Daniel Berlin via llvm-commits]

So i whiteboarded this, and i don't think there is a good way to do it
given how often we destroy the types of info right now.
:(

I guess we'll just have to live with it for now.

Thanks for working through this with me, greatly appreciate it.

Other than calling it llvm.noalias.scope, i would think this is good to go
:)


On Tue, Aug 16, 2016 at 11:31 AM, Daniel Berlin <dberlin at dberlin.org> wrote:

>
>
> On Mon, Aug 15, 2016 at 8:18 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>
>>
>> ------------------------------
>>
>> *From: *"Daniel Berlin" <dberlin at dberlin.org>
>> *To: *"Hal Finkel" <hfinkel at anl.gov>
>> *Cc: *rsilvera at google.com, "Chandler Carruth" <chandlerc at gmail.com>,
>> "David Majnemer" <david.majnemer at gmail.com>, "Nicolai Hähnle-Montoro" <
>> nhaehnle at gmail.com>, "Chad Rosier" <mcrosier at codeaurora.org>,
>> "llvm-commits" <llvm-commits at lists.llvm.org>,
>> reviews+D9375+public+6271545f2d8b34dd at reviews.llvm.org
>> *Sent: *Monday, August 15, 2016 10:03:58 PM
>> *Subject: *Re: [PATCH] D9375: An llvm.noalias intrinsic
>>
>>
>>> The one without loop info, can be readnone.
>>> The with loop info, we figure that out :)
>>>
>>> That sounds great, but I don't have any idea how that would work.
>>>
>>
>> At the point in time when I insert the intrinsics, I'm either in the
>>> inliner or in the frontend, and I don't know anything about loops.
>>>
>>
>>
>>> Moreover, I might be inserting the intrinsics into places that won't
>>> obviously dominate, or be inside, loops until after inlining.
>>>
>>
>>
>>> Even if I add loop information to the inliner (which we'll want to do
>>> anyway), having the inliner each for newly-dominating llvm.noalias
>>> intrinsics and fix them up with information about the newly-inserted loops
>>> seems asymptotically unfavorable.
>>>
>>
>> Note that if we do loop info in the inliner, and keep it up to date, you
>> already have all the info you need to fix-them-up, and i guess i don't see
>> what the issue is.
>>
>> At worst, all you have to do is track what block these things appear in,
>> and when loopinfo determines that block has a loop id, you promote them and
>> give them that loop id...
>> When it determines a block no longer has a loop id, you demote them.
>> It already has to do all the real work to keep the loops up to date
>> anyway ...
>>
>> Just to be clear, what I'm going to care about is finding intrinsics that
>> dominate a given loop, not those in the loop.
>>
>
> Ah. I would have figured you also cared about the intra-iteration
> intrinsic, and that would have appeared at the start of the loop body,
> since that is where the restrict scope ends up starting after inlining
>
>
>
>
>> So either I need each loop to have some list of dominating intrinsics
>> (i.e. originally dominating, neglecting any hosting that might occur), or
>> each intrinsic needs a list of the loops it originally dominates. It is
>> maintaining this that I was afraid could get expensive. These lists could
>> be filtered by loops only containing some pointer based on the intrinsic
>> (we can probably use a direct use/def check here because omission would be
>> conservatively correct). Is your opinion still the same?
>>
>
> Let me see how often we destroy loopinfo.
>
> The ideal non-loop way to store this is to just augment dominator tree
> nodes, or store it associated with the dfs numbers in the domtree (which
> would allow collection for a given loop in O(level depth of dom tree) time,
> but we definitely destroy that too much.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160816/4f945e03/attachment.html>