[PATCH] D124787: [NVPTX] Implement NVPTX AliasAnalysis

Artem Belevich via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Dec 12 11:16:33 PST 2022


tra added inline comments.


================
Comment at: llvm/lib/Target/NVPTX/NVPTXAliasAnalysis.cpp:61
+  // Therefore a global pointer may alias with a param pointer on some
+  // GPUs via addrspacecast(param->generic->global).
+  //
----------------
param->generic is not implemented yet, so this is overly conservative. 

Do we have any way to check whether ASC(param->generic) is available? If we do, we could use it to determine if we should return MayAlias or NoAlias.


================
Comment at: llvm/test/CodeGen/NVPTX/nvptx-aa.ll:82
+; CHECK-ALIAS: MayAlias: i8* %gen, i8 addrspace(1)* %global
+; CHECK-ALIAS: NoAlias:  i8 addrspace(1)* %global, i8 addrspace(101)* %param
+; CHECK-ALIAS: MayAlias: i8* %gen, i8 addrspace(101)* %param
----------------
asavonic wrote:
> tra wrote:
> > Looks like recently PTX grew ability to convert .param to generic AS:
> > https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-cvta
> > 
> > AFAICT, when that happens, the address *may* be converted into a global pointer:
> > https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#generic-addressing says:
> > 
> > > The Kernel Function Parameters (.param) window is contained within the .global window.
> > 
> > So, technically, a global pointer *may* alias with a param pointer on some GPUs via ASC(param->generic->global).
> > 
> > The good news is that we don't have `cvta.param` implemented yet, so as things stand, there's no aliasing between param and global, but that will likely change in the future. We may want to either conservatively make them "mayAlias" from now on, or keep them as "NoAlias" for now with a TODO to make sure we update it when we get to implement `cvta.param` in lib/Target/NVPTX/NVPTXIntrinsics.td
> > 
> Hmm.. this is unfortunate. If `param` is a subset of `global`, then it also cannot be treated as constant memory. I'll update `alias` and `getModRefInfoMask` functions to handle this.
.param AS is a bit special when it comes to constantness.

Param space should not ever be used in the user-provided IR.  As far as the user IR is concerned, byval arguments live in generic AS and are writeable.

In order to make sure byval arguments are never written to, as required by PTX,  we make a local copy, if one needs to store to it. From that point of view, AS should also consider param space as writable, even though we'll never generate actual writes to it and redirect them to a local copy.





Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124787



More information about the llvm-commits mailing list