[PATCH] D69498: IR: Invert convergent attribute handling

[Sameer Sahasrabuddhe via Phabricator via cfe-commits]

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