This is an archive of the discontinued LLVM Phabricator instance.

[AMDGPU] Avoid assert for saved FP
ClosedPublic

Authored by rampitec on Aug 3 2021, 2:54 PM.

Details

Summary

With spilling into AGPRs enabled we cannot reliably predict
if we need to save FP or not. We may finally spill everything
into AGPRs and never touch stack. In this case we still may
save FP. This is deficiency but not an error, so avoid the
assert.

Diff Detail

Event Timeline

rampitec created this revision.Aug 3 2021, 2:54 PM
rampitec requested review of this revision.Aug 3 2021, 2:54 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 3 2021, 2:54 PM
Herald added a subscriber: wdng. · View Herald Transcript
arsenm added a subscriber: cdevadas.Aug 3 2021, 3:01 PM

We should stop "spilling" to AGPRs entirely. It's not a spill, it's an ordinary copy due to pressure. We just need to start using the combined VGPR+AGPR classes for values @cdevadas was working on this.

The same problem exists for SGPRs and we prune the stack objects before this

We should stop "spilling" to AGPRs entirely. It's not a spill, it's an ordinary copy due to pressure. We just need to start using the combined VGPR+AGPR classes for values @cdevadas was working on this.

The same problem exists for SGPRs and we prune the stack objects before this

All of that is not a reason to assert on a valid program. We also cannot prune stack objects where we create FP copy yet, we do not have spills yet. That is that heurtistic in the determineCalleeSaves to produce WillHaveFP doing that.

We should stop "spilling" to AGPRs entirely. It's not a spill, it's an ordinary copy due to pressure. We just need to start using the combined VGPR+AGPR classes for values @cdevadas was working on this.

The same problem exists for SGPRs and we prune the stack objects before this

All of that is not a reason to assert on a valid program. We also cannot prune stack objects where we create FP copy yet, we do not have spills yet. That is that heurtistic in the determineCalleeSaves to produce WillHaveFP doing that.

Note, if spilling is replaced with the copying then the option itself will be removed and the assert updated as a result. In the meanwhile we should not assert.

We should stop "spilling" to AGPRs entirely. It's not a spill, it's an ordinary copy due to pressure. We just need to start using the combined VGPR+AGPR classes for values @cdevadas was working on this.

The same problem exists for SGPRs and we prune the stack objects before this

All of that is not a reason to assert on a valid program. We also cannot prune stack objects where we create FP copy yet, we do not have spills yet. That is that heurtistic in the determineCalleeSaves to produce WillHaveFP doing that.

This is still just blanket disabling the assert if spill to AGPR happens to be enabled. Can't this be more fine grained?

llvm/lib/Target/AMDGPU/SIFrameLowering.cpp
963

Typo everythying

We should stop "spilling" to AGPRs entirely. It's not a spill, it's an ordinary copy due to pressure. We just need to start using the combined VGPR+AGPR classes for values @cdevadas was working on this.

The same problem exists for SGPRs and we prune the stack objects before this

All of that is not a reason to assert on a valid program. We also cannot prune stack objects where we create FP copy yet, we do not have spills yet. That is that heurtistic in the determineCalleeSaves to produce WillHaveFP doing that.

This is still just blanket disabling the assert if spill to AGPR happens to be enabled. Can't this be more fine grained?

It is too early here to say if that will happen or not. The code itself tries to predict if there will be FP.

rampitec updated this revision to Diff 366347.Aug 13 2021, 1:43 PM
rampitec marked an inline comment as done.

Fixed typo.

arsenm accepted this revision.Aug 25 2021, 5:58 AM

I don't like just disabling the assert but @cdevadas is working on fixing this special case already

This revision is now accepted and ready to land.Aug 25 2021, 5:58 AM
This revision was landed with ongoing or failed builds.Aug 25 2021, 9:51 AM
This revision was automatically updated to reflect the committed changes.