[llvm] [NVPTX] Check Before inserting AddrSpaceCastInst in NVPTXLoweringAlloca (PR #106127)
Artem Belevich via llvm-commits
llvm-commits at lists.llvm.org
Tue Aug 27 17:02:34 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:
> Does the PTX spec place the upstream requirements that allocas must be allocated in the generic address space instead of LOCAL? (I imagine if there is reg spilling), or is this an implementation detail of the LLVM backend?
In this case, PTX is oblivious of allocas. It's just another chunk of memory on the stack. We bundle allocas and other on-stack objects into it. As such, it can only live in the local parameter space in PTX, which is represented as the `local` AS(5) in LLVM.
LLVM does not do any register spilling in NVPTX (we pretend to have infinite number of registers), but if/when ptxas does it during compilation to SASS, the spilled registers do end up in the same memory.
> If it is the latter, what do you think the LLVM backend's policy should be?
LLVM can't always lower syntactically correct IR. We also do not have any good way to report compilation errors, so an assertion is the best we can do here, so we at least have a chance to catch unintentional bad cases during the tests.
I think assert is appropriate here.
https://github.com/llvm/llvm-project/pull/106127
More information about the llvm-commits
mailing list