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

Philip Reames
Fri, 14 Nov 2014 18:27:58 -0000

+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