[PATCH] D69498: IR: Invert convergent attribute handling

Fri Nov 1 06:07:56 PDT 2019

Anastasia added a comment.

In D69498#1725692 <https://reviews.llvm.org/D69498#1725692>, @kariddi wrote:

> In D69498#1725528 <https://reviews.llvm.org/D69498#1725528>, @rjmccall wrote:
>
> > It absolutely makes sense for Clang as a GPU-programming frontend to set attributes appropriately when targeting the GPU.  I'm objecting to making "convergence" and related "code layout is semantics" properties a universal part of the IR semantics that literally every frontend has to know about in order to get reasonable behavior from LLVM.  I know that doing so makes sense to GPU backend developers because you mostly work exclusively on GPU toolchains, but AFAIK there are half a dozen GPU frontends and they're all forks of Clang, whereas there are dozens of LLVM frontends out there that don't care about targeting the GPU and quite possibly never will.  (And even if they do target GPUs, they often will not care about exposing thread groups; many programming environments are just interested in taking advantage of the GPU's parallel-computation power and have no interest in inter-thread interference.)
> >
> > John.
>
>
> I agree that the issue with making it "transparent" as a concept to whoever is not interested in programming models that have the concept of SIMD-wide execution is an open issue (not only related to this patch, but in general to the convergent idea as a whole, where writing a llvm pass that maintains convergence now is an extra burden to the developer of such pass that wasn't there before and that is probably completely orthogonal to the interest of the pass writer probably targeting C/C++ or other non-parallel languages). I opened some discussions going on the other related RFC for extending the concept of convergent to avoid hoisting as well regarding how are we gonna avoid burdening the LLVM community and maintain the invariants we want with respect to this concept.
>  I have no idea what the impact of the convergent attribute is in Clang (with the exception of adding the flag itself), but a lot of the heavy-lifting I know its in LVLM itself.
>
> That said I just want to point out that some of these languages run on CPUs as well (like openCL ) and they share the same properties with respect to instructions that read execution masks of neighboring threads and making sure threads stay converged when executing them. It's certainly unfortunate that LLVM has some deficiencies in supporting these concepts and that the so far proposed solutions are not burden free for the rest of the community. :-/

Aside from functionality issues with inter-thread interference, there is another very related aspect - optimizing for SIMT execution. This topic hasn't been discussed much yet but optimizing for single threaded execution doesn't always yield optimal result when run in SIMT style. For example divergent code regions can significantly slow down execution of multiple threads even if they have small instruction count. I think the biggest gap in LLVM is absence of a way to represent SIMT concept in general i.e. by adding special annotations to functions that run in SIMT mode or adding annotation to the whole module. This can be useful not only to correctly implement `convergent` but to potentially setup separate optimization pass pipeline for GPU-like targets to allow excluding harmful transformations and potentially add more passes to middle end that are targeting SIMT.  Currently there is no solution to this at middle end and therefore each backend ends up adding the same logic during lowering phases instead. However, adding the concept of SIMT seems like a large architectural change and might not be something we can do quickly. Potentially we can identify some small steps towards this goal that can be done now to at least to support the `convergent` for SIMT targets correctly without affecting much non-SIMT community.

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

https://reviews.llvm.org/D69498