<div dir="ltr">Hi folks,<br><br>The 13th issue of LLVM GPU News, a bi-weekly newsletter on all the GPU things under the LLVM umbrella, is now available at:<br><<a href="https://llvm-gpu-news.github.io/2021/06/04/issue-13.html">https://llvm-gpu-news.github.io/2021/06/04/issue-13.html</a>>.<div><br>I also pasted the content below, in case you prefer to read in your email client.<br><div><br>-Jakub</div></div><div><br></div><div>======================================================================<br><br># LLVM GPU News Issue #13, June 4 2021<br>Authors: Jakub Kuderski, Johannes Doerfert, Lei Zhang<br><br>Welcome to LLVM GPU News, a bi-weekly newsletter on all the GPU things under the LLVM umbrella.<br>This issue covers the period from May 21 to June 3 2021.<br><br>We welcome your feedback and suggestions. Let us know if we missed anything interesting, or want us to bring attention to your (sub)project, revisions under review, or proposals. Please see the bottom of the page for details on how to submit suggestions and contribute.<br><br><br>## Industry News and Conference Talks<br><br>*  LLVM-CTH: [The Second Workshop on LLVM Compiler and Tools for HPC](<a href="https://hps.vi4io.org/events/2021/llvm">https://hps.vi4io.org/events/2021/llvm</a>) features multiple GPU centric talks.<br><br><br>##  LLVM and Clang<br><br>### Discussions<br><br>*  Sameer Sahasrabuddhe posted an [RFC for making function calls `convergent` by default](<a href="https://lists.llvm.org/pipermail/llvm-dev/2021-June/150814.html">https://lists.llvm.org/pipermail/llvm-dev/2021-June/150814.html</a>). On GPU targets, "A convergent operation involves inter-thread communication or synchronization that occurs outside of the memory model, where the set of threads which participate in communication is implicitly affected by control flow". The RFC proposed to conservatively make calls `convergent` by default, and to add the `noconvergent` attribute to indicate that a call is not sensitive to the set of threads executing any dynamic instance of that call. This way, "Frontends are no longer required to add a `convergent` or `noconvergent` attribute if all they seek is correct execution on GPUs".<br>*  ggllvm is seeking [help with OpenCL kernel compilation for AMDGPU on Discourse](<a href="https://llvm.discourse.group/t/tried-to-compile-opencl-kernel-got-close-but-not-quite/3534">https://llvm.discourse.group/t/tried-to-compile-opencl-kernel-got-close-but-not-quite/3534</a>). The only suggestion so far did not resolve their problem.<br><br>### Commits<br><br>*  [CUDA/HIP compilation now defaults to C++14](<a href="https://reviews.llvm.org/D103221">https://reviews.llvm.org/D103221</a>) instead of C++98. This change makes it match the default C++ standard version used by Clang and nvcc, while GCC already defaults to C++17.<br>*  HIP now [supports ThinLTO compilation for the AMDGPU target](<a href="https://reviews.llvm.org/D99683">https://reviews.llvm.org/D99683</a>). This is controlled by new Clang flags: `-[no-]offload-lto` and `-foffload-lto=[thin,full]`.<br>*  HIP device library detection [has been fixed](<a href="https://reviews.llvm.org/D103281">https://reviews.llvm.org/D103281</a>) for the [Spack package manager](<a href="https://spack.io/">https://spack.io/</a>).<br><br><br>## MLIR<br><br>### Discussions<br><br>* Thomas Raoux is asking about [using the new `GPU_MMAMatrix` type with Standard ops](<a href="https://llvm.discourse.group/t/using-gpu-type-with-standard-ops/3542">https://llvm.discourse.group/t/using-gpu-type-with-standard-ops/3542</a>) without having the Standard dialect depend on the GPU dialect. Geoffrey Martin-Noble pointed out that "standard ops only operate on (a subset of) builtin types, but perhaps we could consider turning `ShapedType` into an interface".<br><br>### Commits<br><br>* GPU MMA store ops are [relaxed](<a href="https://reviews.llvm.org/D103023">https://reviews.llvm.org/D103023</a>) to allow chain of MMA ops.<br>* SPIR-V dialect starts to see better [assembly](<a href="https://reviews.llvm.org/D103152">https://reviews.llvm.org/D103152</a>) [result](<a href="https://reviews.llvm.org/D103594">https://reviews.llvm.org/D103594</a>) names.<br>* `spv.module` now has `SingleBlock` and `NoTerminator` traits; `spv.endmodule` is [retired](<a href="https://reviews.llvm.org/D103265">https://reviews.llvm.org/D103265</a>).<br><br><br>## OpenMP (Target Offloading)<br><br>### Discussions<br><br>* An [OpenMP offloading buildbot](<a href="https://lab.llvm.org/staging/#/workers/118">https://lab.llvm.org/staging/#/workers/118</a>) is available in the LLVM buildbot staging area.<br>* OMPD upstreaming continues with discussions: [D100181](<a href="https://reviews.llvm.org/D100181">https://reviews.llvm.org/D100181</a>).<br>* The patchsets for reworked globalization ([D97680](<a href="https://reviews.llvm.org/D97680">https://reviews.llvm.org/D97680</a>) and following) and custom state machines ([D101976](<a href="https://reviews.llvm.org/D101976">https://reviews.llvm.org/D101976</a>) and following) are almost ready.<br>* AMD are reworking the `__shared__` / `__local` implementation for higher efficiency.<br>* Linking of static archives with offload code is being worked on again: [D93525](<a href="https://reviews.llvm.org/D93525">https://reviews.llvm.org/D93525</a>).<br><br>### Commits<br><br>* We are replacing libelf with the ELF facilities in LLVM core to cut down on dependencies and work towards offloading on non-Linux platforms: [D103545](<a href="https://reviews.llvm.org/D103545">https://reviews.llvm.org/D103545</a>).<br>* Multiple refactoring commits to the amdgpu plugin, mainly removing global state ([D103600](<a href="https://reviews.llvm.org/D103600">https://reviews.llvm.org/D103600</a>), [D103509](<a href="https://reviews.llvm.org/D103509">https://reviews.llvm.org/D103509</a>), ...).<br>* Various bug fixes: [D103642](<a href="https://reviews.llvm.org/D103642">https://reviews.llvm.org/D103642</a>), [D103646](<a href="https://reviews.llvm.org/D103646">https://reviews.llvm.org/D103646</a>).<br><br><br>## External Compilers<br><br>### LLPC<br><br>*  The [number of allowed InstCombine iterations was tightened](<a href="https://github.com/GPUOpen-Drivers/llpc/pull/1254">https://github.com/GPUOpen-Drivers/llpc/pull/1254</a>). This improves compilation times by 3% on average.<br><br>### Mesa<br><br>*  [llvmpipe](<a href="https://docs.mesa3d.org/drivers/llvmpipe.html">https://docs.mesa3d.org/drivers/llvmpipe.html</a>), a software OpenGL renderer implementation, dropped support for old LLVM versions and now [requires at least LLVM 3.9](<a href="https://cgit.freedesktop.org/mesa/mesa/commit/?id=54e7353fa60ba3a93679b733a6c9cb8fe8bb4ab6">https://cgit.freedesktop.org/mesa/mesa/commit/?id=54e7353fa60ba3a93679b733a6c9cb8fe8bb4ab6</a>).<br><br></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div>Jakub Kuderski</div></div></div>