[PATCH] D9375: An llvm.noalias intrinsic

[Daniel Berlin via llvm-commits]

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/59011bb7/attachment.html>