[PATCH] D46756: [AMDGPU] Reworked SIFixWWMLiveness

[Daniel Schürmann via Phabricator via llvm-commits]

daniel-schuermann added a comment.

First, thanks for working on this issue, it's on our table since ages and I couldn't find a proper solution yet.
I tested your patch with my shader_ballot implementation on DOOM, but still get a bunch of artifacts (https://github.com/daniel-schuermann/mesa/commits/shader_ballot).
It might also be that my implementation is bugged, so I'd be glad in case you have AMDVLK branch with working

  OpExtension "SPV_AMD_gcn_shader"
  OpExtension "SPV_AMD_shader_ballot"
  OpExtension "SPV_AMD_shader_trinary_minmax"
  OpExtension "SPV_KHR_shader_ballot"
  OpExtension "SPV_KHR_subgroup_vote"
  OpCapability SubgroupBallotKHR
  OpCapability SubgroupVoteKHR
  OpCapability Group

if you let me know if DOOM works for you.

In https://reviews.llvm.org/D46756#1138135, @tpr wrote:

> Actually that plan does not work for one of the cases handled in the current change: when there is a def towards the end of a loop and a use outside the loop, and there is some WWM inside the loop. There is no phi node at the top of the loop at all for that, but we need to spot the case and introduce one (and make its value undef from the loop pre-header) because the liveness needs to go round the loop to allow for lanes that were in the loop but have become inactive because they have already decided to leave the loop.


According to literature[1], there are exactly three types of phi-nodes:
γ - functions represent the joining point of different paths created by an “if-then-else” branch in the source program.
μ - functions, which only exist at loop headers, merge initial and loop-carried values.
η - functions represent values that leave a loop.

The case you are talking about requires an η phi-node after the loop exit, which should be there if we are in LCSSA-form. (If not, we'd have to lower to LCSSA.)
I think, case distinction makes sense here as these are the only variations of phi-nodes. For the η-node, we'd have to check if a Def of a phi-src can reach itself (as it's inside a loop) via a WWM region to resolve this issue.
The same might be true for the μ phi-nodes (e.g. if we have only one initial and one loop-carried value and afterwards a WWM region inside the loop, then neither the initial value reaches the loop-carried value via WWM nor the other way around).
The other cases according to @nhaehnle's proposal.

[1] Tu, Peng, and David Padua. "Efficient building and placing of gating functions." ACM SIGPLAN Notices 30.6 (1995): 47-55.


Repository:
  rL LLVM

https://reviews.llvm.org/D46756