[PATCH] D87107: [AMDGPU] Target hook to apply target specific split constraint

[Alexander via Phabricator via llvm-commits]

alex-t added a comment.

In D87107#2261429 <https://reviews.llvm.org/D87107#2261429>, @rampitec wrote:

> In D87107#2259217 <https://reviews.llvm.org/D87107#2259217>, @alex-t wrote:
>
>> The idea is:
>>
>> For the block that is queried
>>
>> 1. Look for it's predecessors that can pass control through the S_EXECZ/EXECNZ
>> 2. If found one, look for exec restoring code starting the beginning of the block being queried.
>> 3. Since exec restoring code always belong to the block prologue, search the prologue and if not found return false.
>>
>> Considering your comment that exec == 0 does not matter, we'd rather search upwards before the immediate dominator block in encountered to check what we met first - exec modify or exec restore. The problem here is that XOR can be both.
>
> Thanks. More or less you want to disable split in an empty block preceded by c_branch_exec[n]z. I can understand why this would be a problem. In reality such block can be either empty or contain another branch, because it does not make any sense to pass a control to a block with vector instructions and have no active lanes.
>
> But this leaves couple problems:
>
> 1. It does not disallow a split in a block prologue before exec is restored. This creates exactly the same problem.
> 2. It does not disallow a split even in an empty block where EXEC is not zero, but just wrong. The problem is not zero EXEC, the problem is wrong EXEC, zero is just once case of this.
>
> JBTW, even with all of this it is still OK to split an LI of SGPR. I'd say at the very least callback needs to take an LI in question as well.

In fact, I clearly understand that the explicit and clean way to aceive the goal would be for the block queried check if the value of exec mask in it is exactly the same as in the block to which VNInfo that active in current block got defined.
Details:

1. We have MBB that is queried if it is valid to split the give LI in it.
2. We check which VNInfo (valno) is active in this block.
3. We take MBB where the VNInfo::def SlotIndex lives
4. We proove that along the all passes from MBB with def to current MBB exec mask operations keep consistency. In another words - whatever we did with exec mask it has same value in defMBB and in splitMBB.

It would be great but... it would require values analysis over all passes.


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

https://reviews.llvm.org/D87107