[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