<div dir="ltr"><div dir="ltr"><div dir="ltr">Hi folks,<br><br>The 9th issue of LLVM GPU News, a bi-weekly newsletter on all the GPU things under the LLVM umbrella, is now available at <<a href="https://llvm-gpu-news.github.io/2021/04/02/issue-9.html" target="_blank">https://llvm-gpu-news.github.io/2021/04/02/issue-9.html</a>>.<div><br>I also pasted the content below, in case you prefer to read in your email client.<br><div><br>-Jakub<br><br>======================================================================<br><br># LLVM GPU News Issue #9, April 2 2021<br>Authors: Jakub Kuderski, Johannes Doerfert, Lei Zhang<br></div></div><div><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 March 19 to April 1 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>*  [AMD ROCm](<a href="https://github.com/RadeonOpenCompute/ROCm">https://github.com/RadeonOpenCompute/ROCm</a>) v4.1 has been [released](<a href="https://github.com/RadeonOpenCompute/ROCm/releases/tag/rocm-4.1.0">https://github.com/RadeonOpenCompute/ROCm/releases/tag/rocm-4.1.0</a>).<br><br>##  LLVM and Clang<br><br>### Discussions<br><br>*  Discussion on the 'Abstracting over SSA form IRs to implement generic analyses' RFC has seen some new activity. Sameer Sahasrabuddhe [shared their perspective](<a href="https://lists.llvm.org/pipermail/llvm-dev/2021-March/149523.html">https://lists.llvm.org/pipermail/llvm-dev/2021-March/149523.html</a>) and identified that the main issue is that LLVM IR/MIR basic blocks do not explicitly track their successors and predecessors. Nicolai Hähnle [clarified what the most important decisions are](<a href="https://lists.llvm.org/pipermail/llvm-dev/2021-March/149560.html">https://lists.llvm.org/pipermail/llvm-dev/2021-March/149560.html</a>) to move the proposal forward. In addition, Nicolai noted that changing the in-memory representation of basic blocks to contain predecessor and successor vectors would allow terminator instruction to refer to those, and potentially result in reduced memory usage.<br><br>### Commits<br><br>*  [AMDGPU PAL usage documentation was updated.](<a href="https://reviews.llvm.org/D93125">https://reviews.llvm.org/D93125</a>)<br>*  (In-review) AMDGPU Machine IR optimization to [remove unnecessary cache invalidations](<a href="https://reviews.llvm.org/D99128">https://reviews.llvm.org/D99128</a>).<br><br>## MLIR<br><br>### Discussions<br><br>### Commits<br><br>*  Conversion to NNVM/ROCL now [uses](<a href="https://reviews.llvm.org/D98937">https://reviews.llvm.org/D98937</a>) a data layout entry to specify the bitwidth for index type.<br><br><br>## OpenMP (Target Offloading)<br><br>### Discussions<br><br>*  Nader Al Awar asked about using the [`-fembed-bitcode` Clang option with OpenMP target offload for CUDA](<a href="https://lists.llvm.org/pipermail/llvm-dev/2021-March/149529.html">https://lists.llvm.org/pipermail/llvm-dev/2021-March/149529.html</a>). There are no replies as of writing.<br>*  [Asynchronous offloading bugs](<a href="https://bugs.llvm.org/show_bug.cgi?id=49816">https://bugs.llvm.org/show_bug.cgi?id=49816</a>) were discovered and are being discussed on the mailing list and the bugtracker.<br>*  The device runtime for LLVM 12 shows performance regressions, [\[1\]](<a href="https://bugs.llvm.org/show_bug.cgi?id=49752">https://bugs.llvm.org/show_bug.cgi?id=49752</a>) and [\[2\]](<a href="https://bugs.llvm.org/show_bug.cgi?id=49764">https://bugs.llvm.org/show_bug.cgi?id=49764</a>), that will be addressed in the 12.1 release.<br>*  A rewrite of the device runtime is being tested right now. The first results look promising with regards to performance and memory usage.<br>*  Issues with Clang's device code generation were detected: [\[1\]](<a href="https://bugs.llvm.org/show_bug.cgi?id=49779">https://bugs.llvm.org/show_bug.cgi?id=49779</a>), [\[2\]](<a href="https://bugs.llvm.org/show_bug.cgi?id=49777">https://bugs.llvm.org/show_bug.cgi?id=49777</a>), and will be resolved soon.<br><br>### Commits<br><br>*  OpenMP declare mapper will now pass variable names to the runtime for [better feedback](<a href="https://reviews.llvm.org/D99681">https://reviews.llvm.org/D99681</a>).<br>*  Asynchronous errors reported by the device runtime will be [less confusing](<a href="https://reviews.llvm.org/D99510">https://reviews.llvm.org/D99510</a>).<br>*  Failed offloading will not cause an [assertion error](<a href="https://reviews.llvm.org/D99443">https://reviews.llvm.org/D99443</a>) anymore.<br>*  Optimization for variable globalization on the device is [already available](<a href="https://reviews.llvm.org/D97818">https://reviews.llvm.org/D97818</a>) while we prepare to [switch to the new system](<a href="https://reviews.llvm.org/D97680">https://reviews.llvm.org/D97680</a>).<br><br>## External Compilers<br><br>### LLPC<br><br>### Mesa<br><br>*  [Dave Airlie reported](<a href="https://airlied.blogspot.com/2021/03/sketchy-vulkan-benchmarks-lavapipe-vs.html">https://airlied.blogspot.com/2021/03/sketchy-vulkan-benchmarks-lavapipe-vs.html</a>) that they found lavapipe, the Mesa's CPU-based Vulkan implementation, to be faster than [SwiftShader](<a href="https://github.com/google/swiftshader">https://github.com/google/swiftshader</a>), a CPU-based Vulkan implementation from Google. This is based on a set of randomly picked [Vulkan samples from Sascha Willems](<a href="https://github.com/SaschaWillems/Vulkan">https://github.com/SaschaWillems/Vulkan</a>).<br><br>### SYCL<br><br><br></div>-- <br><div dir="ltr"><div>Jakub Kuderski</div></div></div></div></div>