[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#2090724 <https://reviews.llvm.org/D68484#2090724>, @efriedma wrote:

> In D68484#2090569 <https://reviews.llvm.org/D68484#2090569>, @jeroen.dobbelaere wrote:
>
> >
>
>
> `getelementptr q, (ptrtoint(p)-ptrtoint(q))` should return a pointer with provenance of q, and the value of p.  (http://llvm.org/docs/LangRef.html#pointer-aliasing-rules).  I can't see how it isn't equivalent... unless noalias provenance is somehow different from the usual aliasing rules.


I see now. It is indeed somewhat equivalent. The separate intrinsic makes it easier to convey the specific purpose of the construct and to control the kind of optimizations that we want to allow.
A generalized version of the 'llvm.noalias.arg.guard', maybe something like 'llvm.ptr.provenance %pValue, %pProv1 [, %pProv_i]*',   could convey the same information, and could be a help for fixing the bug you mentions.
But, this is not the goal of the full restrict patches, and I would rather start with the current focused set of intrinsics, before trying to expand on it.

> Does the presence of provenance markings fix https://bugs.llvm.org/show_bug.cgi?id=35229 ?

No, that problem is not fixed with the full restrict patches.

>>>   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).
> 
> Oh, I see, it only applies the provenance to loads derived from that pointer, not all loads from the memory.

yes.


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

https://reviews.llvm.org/D68484