[PATCH] D69498: IR: Invert convergent attribute handling

[Marcello Maggioni via Phabricator via cfe-commits]

kariddi added a comment.

One thing to probably note is that its not only a "target specific" issue, but 
a language specific issue as well (IMHO). OpenCL, CUDA, SYCL are all languages 
(to name a few) that have a concept of "convergence" and its not related only 
to the fact that they mostly run on a GPU, but to their programming model as 
well with respect to accessing textures and SIMD-wide communication and 
decision making (ballot)

Considering that Clang has support for these languages it kind of makes sense 
to me that the frontend is taking care of implementing the supported languages 
correctly by applying the proper attributes.

Now, its debatable that "convergent" is enough to cover all the cases we need 
... and CUDA for example is running away from "ballot()" and such and moving to 
versions that have an explicit mask of the threads involved in the transaction 
for that reason. Even the new version with the "dynamic instances" of the 
mentioned proposal might not be enough ... but that's discussion for the other 
RFC ...


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

[PATCH] D69498: IR: Invert convergent attribute handling

[Marcello Maggioni via Phabricator via cfe-commits]

kariddi added a comment.

In 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. :-/


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