[PATCH] D68484: [PATCH 01/26] [noalias] LangRef: noalias intrinsics and noalias_sidechannel documentation.

[Jeroen Dobbelaere via Phabricator via llvm-commits]

jeroen.dobbelaere added a comment.

In D68484#2090338 <https://reviews.llvm.org/D68484#2090338>, @efriedma wrote:

> If I'm understanding correctly, `llvm.noalias.arg.guard(p, q)` is equivalent to `getelementptr q, p-q`?


This is not correct: the 'llvm.noalias.arg.guard(p,ptr_provenance)' combines the 'value of the pointer' (p) with the 'provenance of the pointer' (ptr_provenance). 
The ptr_provenance does not has a real 'value'. It is more like a dependency.

When you follow both, they should come together at some point, like at the input argument of a function :

- the ptr_provenance purpose is to track the llvm.provenance.noalias information (and its dependencies). Normally there are no computations on this path.
- the normal 'p' path, should in the best case only contain computations.

Due to inlining, it is possible that somewhere in the flow, the normal 'p' path also contains noalias information. The propagation pass should flatten that out.

> And `load i8, i8* %p, i8* %p_prov` is equivalent to `load(llvm.noalias.arg.guard(p, p_prov))`?

Yes, this is correct. The ptr_provenance path was added explicitly to the load/store instructions, in order to get the llvm.noalias.arg.guard out of the way of most optimizations.
This makes is it much easier to keep the code correct in the presence of optimizations.

>   And `llvm.provenance.noalias([...], %p.addr, <type>** %prov.p.addr, [...]` is equivalent to `llvm.noalias([...], llvm.noalias.arg.guard(p, p_prov), [...])`?

Yes.  llvm.provenance.noalias and llvm.noalias are equivalent. The former does track more information, as it is itself also treated like a 'memory instruction', so that we llvm.noalias.arg.guard is not needed.

>   And llvm.noalias.copy.guard is equivalent to loading a pointer, applying llvm.noalias to it, and storing it back to the same address?

No.

llvm.noalias.copy.guard  tells that the pointer it returns has restrict pointers as specified by the struct indices (encoded in the metadata value).

> So really, these are the new concepts in the IR:
> 
> 1. llvm.noalias.decl: this introduces a new "scope" for aliasing.
> 2. llvm.noalias: this associates a pointer with the llvm.noalias.decl.



3. llvm.noalias.arg.guard: combines a pointer (computation) path with a ptr_provenance path
4. llvm.noalias.copy.guard: indicates on what indices in memory a restrict pointer is located

> And the rest can be expressed in terms of those intrinsics and basic IR instructions.

Yes.
llvm.provenance.noalias was introduced as a 'safeguard', to make it clear that it always must be on the 'ptr_provenance' operand side.
The ptr_provenance operand was introduced to keep the information out of the way of most optimization passes.

> It took me a long time to parse this out; I think the description here needs to be reorganized.  It really needs to separate out the semantic core from the detailed dive into the various intrinsics.  Maybe into five sections: how noalias scopes work, how separating provenance from pointer values works, a high-level description of the intrinsics, the suggested lowering of the C "restrict", and the detailed description of the individual intrinsics.

Yes, that makes sense. I am in the process of putting all of this in a separate document, but I didn't want to wait to get the updated patches out ;)
I hope to update this 01/26 patch early next week with the next iteration of the documentation. This is already very useful input for it !

> 
> 
>  -------
> 
>> Before optimizations, there is the declaration of the restrict pointer and ``llvm.noalias`` is used whenever the value of the restrict pointer is read.
> 
> Maybe explain why you're suggesting this, as opposed to using llvm.noalias when the value is written.  (I guess it has something to do with the C standard's definition of "based on"?)

Yes. I hope that the updated documentation will make this easier to understand.

Thanks !

Jeroen Dobbelaere


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

https://reviews.llvm.org/D68484