[PATCH] D69498: IR: Invert convergent attribute handling

Jay Foad via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Apr 23 01:12:51 PDT 2021


foad added a comment.

In D69498#2705441 <https://reviews.llvm.org/D69498#2705441>, @sameerds wrote:

> I would propose refining the definition of the `noconvergent` attribute as follows:
>
>> noconvergent:
>>
>> Some targets with a parallel execution model provide cross-thread operations whose outcome is affected by the presence of divergent control flow. We call such operations convergent. Optimizations that change control flow may affect the correctness of a program that uses convergent operations. In the presence of divergent control flow, such optimizations conservatively treat every call/invoke instruction as convergent by default. The noconvergent attribute relaxes this constraint as follows:
>>
>> - The noconvergent attribute can be added to a call/invoke to indicate that it is not affected by changes to the control flow that reaches it.
>> - The noconvergent attribute can be added to a function to indicate that it does not execute any convergent operations. A call/invoke automatically inherits the noconvergent attribute if it is set on the callee.

I don't have much to add to the conversation except to point out that this definition defines `noconvergent` in terms of divergent control flow, but the langref itself doesn't define what divergent control flow //is//, which makes it an incomplete spec. (Perhaps I'm just restating @arsenm's objections.) This seems unsatisfactory to me but I have no idea what to do about it. I agree with @sameerds that the current definition of `convergent` is too restrictive because in practice we really do want to be able to move convergent calls past uniform control flow.


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

https://reviews.llvm.org/D69498



More information about the llvm-commits mailing list