This is an archive of the discontinued LLVM Phabricator instance.

[AMDGPU] Fix the dead frame indices during custom spill lowering.
ClosedPublic

Authored by cdevadas on Mar 5 2021, 5:47 AM.

Details

Summary

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.

Diff Detail

Event Timeline

cdevadas created this revision.Mar 5 2021, 5:47 AM
cdevadas requested review of this revision.Mar 5 2021, 5:47 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 5 2021, 5:47 AM
arsenm added inline comments.Mar 8 2021, 5:55 AM
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

arsenm added a comment.Mar 8 2021, 6:00 AM

I suppose once this is run between the allocators, we can just rely on LiveDebugVariables

I'm not sure if replacing with noreg or just erasing the dbg_value is better

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.

scott.linder accepted this revision.Mar 9 2021, 9:27 AM

I'm not sure if replacing with noreg or just erasing the dbg_value is better

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.

This revision is now accepted and ready to land.Mar 9 2021, 9:27 AM