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

Jeroen Dobbelaere via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Oct 10 13:56:22 PDT 2019


jeroen.dobbelaere marked an inline comment as done.
jeroen.dobbelaere added inline comments.


================
Comment at: llvm/docs/LangRef.rst:16575
+It will be transformed into a ``llvm.side.noalias`` intrinsic and moved onto
+the ``noalias_sidechannel`` path, so that pointer optimizations can still be
+done and the restrict information is not lost.
----------------
a.elovikov wrote:
> jeroen.dobbelaere wrote:
> > a.elovikov wrote:
> > > > the ``noalias_sidechannel`` path
> > > 
> > > Not sure about terminology, but are `@llvm.noalias.arg.guard`/`@llvm.noalias.copy.guard` considered as `noalias_sidechannel`? I'd suggest not to use the spelling from the load/store instructions and have a more general `moved onto the "side" path` (if my understanding is correct here).
> > The @llvm.noalias.arg.guard   combines the normal path with the noalias_sidechannel path. The @llvm.noalias.copy.guard resides on the normal path and adds extra information to a copy operation (memcpy, load/store).
> > I tried to be consistent in terminology when referring to the 'noalias_sidechannel' path. (but I could also use the 'noalias side channel' or something similar).
> How about this:
> 
> It will be transformed into a ``llvm.side.noalias`` intrinsic and moved onto
> the ``noalias_sidechannel`` path for loads/stores and fed into the @llvm.noalias.arg.guard/@llvm.noalias.copy.guard intrinsics for function boundaries/copies respectively.
...  and fed into the @llvm.noalias.arg.guard intrinsics for function boundaries.

(The @llvm.noalias.copy.guard is generated by the clang frontend)


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

https://reviews.llvm.org/D68484





More information about the llvm-commits mailing list