Page MenuHomePhabricator

AMDGPU: Invert frame index offset interpretation

Authored by arsenm on Jun 4 2019, 5:52 AM.



Since the beginning, the offset of a frame index has been consistently
interpreted backwards. It was treating it as an offset from the
scratch wave offset register as a frame register. The correct
interpretation is the offset from the SP on entry to the function,
before the prolog. Frame index elimination then should select either
SP or another register as an FP.

Treat the scratch wave offset on kernel entry as the pre-incremented
SP. Rely more heavily on the standard hasFP and frame pointer
elimination logic, and clean up the private reservation code. This
saves a copy in most callee functions.

The kernel prolog emission code is still kind of a mess relying on
checking the uses of physical registers, which I would prefer to

Currently selection directly emits MUBUF instructions, which require
using a reference to some register. Use the register chosen for SP,
and then ignore this later. This should probably be cleaned up to use
pseudos that don't refer to any specific base register until frame
index elimination.

Add a workaround for shaders using large numbers of SGPRs. I'm not
sure these cases were ever working correctly, since as far as I can
tell the logic for figuring out which SGPR is the scratch wave offset
doesn't match up with the shader input initialization in the shader
programming guide.

Diff Detail

Event Timeline

arsenm created this revision.Jun 4 2019, 5:52 AM
rampitec accepted this revision.Jun 4 2019, 2:51 PM


This revision is now accepted and ready to land.Jun 4 2019, 2:51 PM
arsenm closed this revision.Jun 5 2019, 3:17 PM