[PATCH] D9375: An llvm.noalias intrinsic

Hal Finkel via llvm-commits llvm-commits at lists.llvm.org
Mon Oct 3 16:17:24 PDT 2016


----- Original Message -----

> From: "Daniel Berlin" <dberlin at dberlin.org>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Raul Silvera" <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: Tuesday, August 16, 2016 4:26:39 PM
> Subject: Re: [PATCH] D9375: An llvm.noalias intrinsic

> 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 :)

Danny, et al., 

I just posted rebased versions of all of the patches in the patchset (in case that makes it easier to review). There are a few patches left that haven't been okayed yet: 

D9401 llvm.noalias - The AA implementaton 
D9378 llvm.noalias - Add IRBuilder support 
D9400 llvm.noalias - Use noalias intrinsics when inlining (and update them when cloning metadata) 

I've been holding off on committing this patch until these others are reviewed (so that the intrinsic can actually mean something). Can you please review these? 

Thanks again, 
Hal 

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

-- 

Hal Finkel 
Lead, Compiler Technology and Programming Languages 
Leadership Computing Facility 
Argonne National Laboratory 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161003/2d550f00/attachment-0001.html>


More information about the llvm-commits mailing list