[LLVMdev] Upcoming Changes/Additions to Scoped-NoAlias metadata

[Hal Finkel]

----- Original Message -----
> From: "Chandler Carruth" <chandlerc at google.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Sent: Thursday, November 13, 2014 7:02:58 PM
> Subject: Re: [LLVMdev] Upcoming Changes/Additions to Scoped-NoAlias metadata
> 
> 
> 
> 
> 
> On Thu, Nov 13, 2014 at 4:44 PM, Hal Finkel < hfinkel at anl.gov >
> wrote:
> 
> 
> After discussing this with Chandler offline last week, here's the
> proposed solution: instead of having both !alias.scope and !noalias
> metadata, we'll have only !alias.scope metadata and an intrinsic:
> i8* @llvm.noalias(i8* ptr, !metadata !?) where the metadata argument
> corresponds to a list of !alias.scopes. The idea being that the
> pointer returned by this intrinsic, and all pointers derived from
> it, are assumed not to alias with memory accesses tagged with any of
> the associated !alias.scope metadata entries.
> 
> 
> Could you give examples? I don't quite follow this. I had thought
> that the analysis would be slightly different. My expectation is
> that each noalias argument pointer would turn into a @llvm.noalias
> call, all of them sharing a single metadata "scope". And then any
> loads or stores through a pointer derived from a @llvm.noalias call
> would never alias loads and stores derived through a different
> @llvm.noalias call which had the same scope metadata.

Sorry, I did not state this very well. Yes, that's correct, with the exception that "derived through a different
> @llvm.noalias call which had the same scope metadata" should also be supplemented with being derived from other identified objects (just like with a noalias argument attribute).

> 
> 
> This intrinsic needs to carry control dependencies (it cannot be
> hoisted out of a loop, for example) -- in this sense it is very much
> like @llvm.assume. And like @llvm.assume, we'll need to add logic to
> various passes to ignore it as appropriate so that it does not block
> optimizations unnecessarily.

> We should do something to make this simpler. I think we should have
> an intrinsic inst base class that assume, lifetime, and other
> intrinsics which do not represent actual code in the final program
> derive from so that we don't have to update these lists all over the
> place. If we need 2 tiers to model assume & noalias as distinct from
> the lifetime or other intrinsics, fine. We should have high-level
> categories that can be tested and updated.

Agreed. There is come commonality here that can be exploited for at least some of the passes.

 -Hal


-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory