[PATCH] D96980: [amdgpu] Revert agnostic SGPR spill.

[Ruiling, Song via Phabricator via llvm-commits]

ruiling added a comment.

In D96980#2587870 <https://reviews.llvm.org/D96980#2587870>, @arsenm wrote:

> In D96980#2587642 <https://reviews.llvm.org/D96980#2587642>, @ruiling wrote:
>
>>>> (I get the argument that IR does not run code if exec = 0, however, MIR models the hardware rather than a high-level language, and exec = 0 is perfectly fine there and even required in some cases, like for the last null export inserted in SIInsertSkips.)
>>>
>>> I'm not convinced this always works. It's possible some transformation ends up violating this. We need to track both sets of predecessors and add some verification for this
>>
>> What do you mean by "violating this"? Do you mean some transformation may failed to keep a jump on EXEC = 0 for each divergent branching?
>
> Yes. The MIR doesn't track divergent predecessors and we don't have any verification for this

I think EXEC = 0 problem can only happen when there is a conditional-branching which can make active lanes less. Unconditional branching will never be a point to bring in EXEC = 0 issue.  I think MIR transform should ensure the branching is always there for conditional-branching, transformations are only allowed to delete unconditional branching while keeping the semantic of the program unchanged. I don't see which step may possibly go wrong.

I also want to say that the possible EXEC = 0 problem (if any) is not specific to such spill solution. If there is any such situation, we definitely should fix it elsewhere. Normal program which includes scalar instructions suffering from "exec=0 sideeffect" would also have such problem.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D96980/new/

https://reviews.llvm.org/D96980