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

[Philip Reames]

+1

The design proposal seems reasonable; I have a couple of comments on 
implementation.

On 11/13/2014 04:44 PM, Hal Finkel 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. 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. I was hoping this avoid this part of the design space, but I don't see any way around it -- only some non-hoistable instruction can model a control dependence.
There have been several related ideas being talked about recently. If 
possible, it'd be nice to arrive at something fairly general.

Andy Trick and I were talking about the possibility of a more general 
control dependent metadata holder at the dev meeting.  The basic idea is 
that you'd have an intrinsic something like "void 
llvm.tag_metadata(any_ty %value, !metadata !?)"   The semantics would be 
that the given metadata applies to the given value at the specific 
location.  By combing this with existing forms of metadata, this 
converts each from being a property of a value to being a property of a 
value at a particular location.  Implementation wise, it would be 
extremely similiar to the existing llvm.assume intrinsic.

Your current proposal uses the data dependence off the intrinsic, 
whereas I was thinking using something closer to the assume mechanism.  
Andy had previously put forth an idea (in the 'Optimization hints for 
"constant" loads' thread) for a similar intrinsic to create a new value 
with a data dependence tied to a function with control dependence.  (To 
make scoping !invariant possible.)  I can see appeal in both schemes, 
but it seems like most folks are leaning towards the data dependent model.

Do you think it makes sense to roll this all into one family of 
intrinsics?  Or do you see something in your proposed use which wouldn't 
work for other types of metadata?

Other example use cases:
- !invariant loads mixed with initialization of the same location
- !nonnull and !range facts recorded by a language frontend

p.s. For the sake of completeness, Andy and I were also talking about a 
version of this idea for function attributes as well.  This would give 
us the ability to say things like "if this value is non-null, it is 
dereferenceable to size X".

Philip