[PATCH] D68484: [PATCH 01/27] [noalias] LangRef: noalias intrinsics and ptr_provenance documentation.

Nuno Lopes via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jan 31 02:09:29 PST 2022


nlopes added a comment.

> I am not sure what you expect the semantics of `@llvm.noalias` and `@llvm.noalias.end` to be. Having examples on how this is supposed to work and and to allow us to implement C99 restrict would be useful.

I believe these two are sufficient:

  declare i8* @llvm.noalias(i8*) noalias argmemonly
  declare void @llvm.noalias.end(i8*, i8*) argmemonly

noalias creates a new object with data aliasing that of the input and same size. noalias.end() doesn't do anything. It's there to prevent memory operations to cross the boundary.
These intrinsics delimit the lexical scope of the restrict variables. They are also introduced when inlining a function with noalias paramater attributes.

So:

  {
    restrict *q = p;
    use(q);
  }
  use(p);

is represented as:

  %q = call @llvm.noalias(%p)
  use(%q)
  call @llvm.noalias.end(%p, %q)
  
  use(%p)

The two uses cannot cross the barriers. This is enforced by LLVM out-of-the-box. Of course one can implement transformations to widen or eliminate the barriers.

> - the need to implement the 'based on' relationship, also in a a way that clang is producing code, where this dependency is not easily seen. The same restrict pointer usage can appear in different blocks at different places.

You need to elaborate this a bit more, otherwise I don't understand what you mean.

> - One of the aims is also to allow memory operations to be moved across (certain) barriers as much as possible. The used intrinsics should (in the end) get completely out of the way of optimizations. The original `@llvm.noalias` is opaque, but gets converted into a `@llvm.provenance.noalias` later on which is put on the ptr_provenance path for that specific reason.

Sure, but barriers exist and cannot be removed. restrict creates a new memory block in a well-defined region. Barriers can be widened and even removed (by giving up on the restrict information). But whether you use intrinsics as barriers or some metadata doesn't matter.
Intrinsics as the ones proposed above have the advantage of being correct from day one and without missing places that need to be updated to learn about the new metadata. This is a huge plus.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68484/new/

https://reviews.llvm.org/D68484



More information about the llvm-commits mailing list