[PATCH] D9375: An llvm.noalias intrinsic

[Hal Finkel via llvm-commits]

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

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

> Alternatively, unless they actually get used during inlining (and i
> don't see where they are), promote them post-inlining from one
> intrinsic to the other as a pass, since now it will understand the
> CFG/etc. I don't see this as a significantly different transform
> than us requiring/using LCSSA for most loop passes (though you'd run
> it right after inlining to make sure nothing broke them).

> Given past experience, i'm very very wary of us trying to have
> implicit control flow dependence like this, and to add yet another
> intrinsic we expect to generate often, but are marking as
> read-write, pessimizing plenty of stuff.
> Particularly when we know that, post-inlining, if none of them ended
> up in loops, we don't actually care where they go.

Me too. This is why if we can come up with an alternate design, I'm quite happy :-) 

-Hal 

> I'm fine with having the scope be implicit temporarily because i
> understand you are just trying to transmit language level scope
> info, but at some point, we should be converting that language level
> scope info into something expressed only in terms of llvm's
> cfg/info/etc if we can.

> (and FWIW: i would call this thing llvm.noalias.scope, like you
> suggested in one place)

> --Dan

-- 

Hal Finkel 
Assistant Computational Scientist 
Leadership Computing Facility 
Argonne National Laboratory 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160815/5aa3de81/attachment-0001.html>