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

[Eli Friedman via Phabricator via llvm-commits]

efriedma added a comment.

If I'm understanding correctly, `llvm.noalias.arg.guard(p, q)` is equivalent to `getelementptr q, p-q`?  And `load i8, i8* %p, i8* %p_prov` is equivalent to `load(llvm.noalias.arg.guard(p, p_prov))`?  And `llvm.provenance.noalias([...], %p.addr, <type>** %prov.p.addr, [...]` is equivalent to `llvm.noalias([...], llvm.noalias.arg.guard(p, p_prov), [...])`?  And llvm.noalias.copy.guard is equivalent to loading a pointer, applying llvm.noalias to it, and storing it back to the same address?

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.

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

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.

-------

> 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"?)


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

https://reviews.llvm.org/D68484