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

[Jeroen Dobbelaere via Phabricator via llvm-commits]

jeroen.dobbelaere added a comment.

>> - 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.

How would you map (before _any_ optimizations; aka, what kind of code should clang produce):

  // int *p, *q,  *s,  *t;
  {
     int *restrict rp = p;
     int *restrict rq = q;
     int *restrict rs = s;
  
     int * based_on_rp1 = rp + index1;
  
     use(rp); 
     use(based_on_rp1); // aliases with rp
     use(rq); // only aliases with rq
     use(rs);
     int * based_on_something;
     if (some_input) {
       based_on_something = based_on_rp1;
     } else {
       based_on_something = rs;
     }
     use(based_on_something); // might alias with rs, or rp
     int * based_on_rp2 = rp + index2;
     use(based_on_rp2);  // aliases with rp
     use(rp);
     use(t); // will not alias with anything above
   }
   use(t+index3); // might alias with everything above

>> - 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.

In some way, it does matter. Intrinsics result in real barriers that can only be left out if done explicitly. (aka, dropping them might result in wrong code).
Metadata can be dropped at will, it should not influence correctness. That is the reason why the full restrict implementation uses both: intrinsics for adding the based-on relationship; metadata for the scope.
The goal of the patches is not just to provide restrict support; The goals is to provide restrict support _and_ good optimizations making use of this knowledge.

> 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.

Were you able to check the initial description ? (https://lists.llvm.org/pipermail/llvm-dev/2019-October/135672.html) As well as the talk I gave last LLVM Dev conference ?
They should give a decent explanation on why  the different concepts are introduced, keeping correctness and optimizations in mind.

Thanks,

Jeroen


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

https://reviews.llvm.org/D68484