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

Chandler Carruth chandlerc at google.com
Thu Nov 13 17:02:58 PST 2014


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.


> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141113/a23a0a0e/attachment.html>


More information about the llvm-dev mailing list