[PATCH] D116270: [AMDGPU] Enable divergence-driven XNOR selection

[Alexander via Phabricator via llvm-commits]

alex-t added a comment.

In D116270#3231623 <https://reviews.llvm.org/D116270#3231623>, @foad wrote:

> In D116270#3231609 <https://reviews.llvm.org/D116270#3231609>, @alex-t wrote:
>
>> Now:
>>
>>   We select the divergent NOT to V_NOT_B32_e32 and divergent XOR to V_XOR_B32_e64. The selection is correct but we missed the opportunity to exploit the fact that even divergent NOT may be selected to S_NOT_B32 w/o the correctness lost.
>
> No, you cannot correctly select divergent NOT to S_NOT_B32. That is not what was happening before your patch (see https://reviews.llvm.org/D116270?vs=on&id=396159#change-5HrmrjqhUdXJ). What was happening was that an input like `~(uniform ^ divergent)` was being "reassociated" to `~uniform ^ divergent` so it could be correctly selected to S_NOT + V_XOR. I assume this was done with a very clever selection pattern, but I am suggesting that instead of that you could implement it as a DAG combine (to do the reassociation), so there is no need for clever selection patterns.

Once again, in my case BOTH nodes (not,xor) are divergent!

  %s.load = load i32, i32 addrspace(4)* %s.kernarg.offset.cast, align 4, !invariant.load !0

DIVERGENT:       %v = call i32 @llvm.amdgcn.workitem.id.x(), !range !1
DIVERGENT:       %xor = xor i32 %v, %s.load
DIVERGENT:       %d = xor i32 %xor, -1
DIVERGENT:       store i32 %d, i32 addrspace(1)* %out.load, align 4

And the correct selection is V_NOT_B32_e32.
But after the selection is done, we can in some cases rearrange instructions in such a way that we replace the V_NOT_B32_e32 with the S_NOT_B32 keeping the code correct.
The long test in my function does this.

Why it was S_NOT_B32 before my patch? Because of the SIInstrInfo::lowerScalarXnor + moveToVALU "magic"


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116270