[llvm] [NVPTX] Check Before inserting AddrSpaceCastInst in NVPTXLoweringAlloca (PR #106127)
Artem Belevich via llvm-commits
llvm-commits at lists.llvm.org
Wed Sep 4 10:55:13 PDT 2024
================
@@ -72,12 +72,21 @@ bool NVPTXLowerAlloca::runOnFunction(Function &F) {
Changed = true;
auto ETy = allocaInst->getAllocatedType();
auto LocalAddrTy = PointerType::get(ETy, ADDRESS_SPACE_LOCAL);
- auto NewASCToLocal = new AddrSpaceCastInst(allocaInst, LocalAddrTy, "");
- auto GenericAddrTy = PointerType::get(ETy, ADDRESS_SPACE_GENERIC);
- auto NewASCToGeneric =
- new AddrSpaceCastInst(NewASCToLocal, GenericAddrTy, "");
- NewASCToLocal->insertAfter(allocaInst);
- NewASCToGeneric->insertAfter(NewASCToLocal);
+ PointerType *AllocInstPtrTy =
+ cast<PointerType>(allocaInst->getType()->getScalarType());
+ Instruction *NewASCToGeneric = allocaInst;
+ if (AllocInstPtrTy->getAddressSpace() != ADDRESS_SPACE_LOCAL) {
----------------
Artem-B wrote:
> What is the right way for NVPTX / LLVM to exploit that all generic statespace allocas point to local statespace?
I'm not sure there's much to exploit. The best we can do with allocas is to get rid of them, which makes their AS a moot point. The allocas that are still left around, will be eventually lowered into the `.local` storage in PTX. Theoretically knowing AS could be used to tell LLVM that cost of the loads/stores is high, but I do not see it making much of a difference whether LLVM can do anything different based on that info. If it needs to use the alloca, it has to do it, and the potential performance difference between direct or generic pointer access will be dwarfed by the actual cost of touching the `.local` memory.
So, accepting `alloca addrspace (5)` is fine for completeness sake, but I don't see it making any measurable positive impact on performance.
https://github.com/llvm/llvm-project/pull/106127
More information about the llvm-commits
mailing list