sameerds added a comment. I realize now that what @foad says above puts the idea in a clearer context. Essentially, any check for isConvergent() isn't happening in a vacuum. It is relevant only in the presence of divergent control flow, which in turn is relevant only when the target has divergence. Any standalone check for isConvergent() is merely making a pessimistic assumption that all the control flow incident on it is divergent. This has two consequences:
1. The meaning of the `convergent` attribute has always been target-dependent. 2. Dependence on TTI is not a real cost at all. We may eventually update every use of isConvergent() to depend on a check for divergence. The check for TTI is only the first step towards that. 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. 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
