AMDGPU target tries to handle the SGPR and VGPR spills in a
custom pass before the actual frame lowering pass. Once they
are handled and the respective frames are eliminated in the
custom pass, certain uses of them still remain. For instance,
the DBG_VALUE instructions inserted by the allocator alongside
the spill instruction will use the corresponding frame index.
They become dead later during PEI and causes a crash while trying to
replace the frame indices. We should possibly avoid this custom pass.
For now, replacing such dead references with null register value.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/AMDGPU/SILowerSGPRSpills.cpp | ||
---|---|---|
405 | You can just check if the stack ID is SGPR spill, you don't need the custom set |
I suppose once this is run between the allocators, we can just rely on LiveDebugVariables
By deleting the debug value we prevent its debug info. Not sure that's the right thing to do.
This patch is meant to be only a short-term fix. If we couldn't have a long-term solution by better handling the spills, we have to replace the noreg with a valid register in the future as the FIXME says.
llvm/lib/Target/AMDGPU/SILowerSGPRSpills.cpp | ||
---|---|---|
405 | There will be VGPR spills too. |
The correct thing is to replace the operand with $noreg, not delete the DBG_VALUE. If we delete the DBG_VALUE entirely we may be incorrectly extending the range of an earlier DBG_VALUE. For example:
DBG_VALUE $rax, !"var" ... SPILL %stack.0 <- $rax DBG_VALUE %stack.0, !"var" ; implicitly "kills" previous DBG_VALUE, "var" now exclusively located in %stack.0 ... CLOBBER $rax ...
If we eliminate the second DBG_VALUE we may end up with something like:
DBG_VALUE $rax, !"var" ... ; no implicit "kill" CLOBBER $rax ... ; now incorrectly describes the location of "var" as $rax even after the clobber
If we just replace the operand, we continue to kill any existing DBG_VALUE.
You can just check if the stack ID is SGPR spill, you don't need the custom set