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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
