<div dir="ltr">Hi folks,<br><br>The 25th issue of LLVM GPU News, a bi-weekly newsletter on all the GPU things under the LLVM umbrella, is out: <<a href="https://llvm-gpu-news.github.io/2021/12/17/issue-25.html">https://llvm-gpu-news.github.io/2021/12/17/issue-25.html</a>>.<br>I also paste the content below, in case you prefer to read in your email client.<div><br></div><div>LLVM GPU news is taking a holiday break and we will skip the next December issue. See you next year!<br><br>-Jakub<br><br>======================================================================<br><br># LLVM GPU News #25, December 17 2021<br>Authors: Jakub Kuderski, Alexey Bader, Lei Zhang<br></div><div><br></div><div>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 December 3 to December 16 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 Conferences<br><br><br>##  LLVM and Clang<br><br>### Discussions<br><br>*  Intel, ARM, and Khronos [proposed to start the integration](<a href="https://lists.llvm.org/pipermail/llvm-dev/2021-December/154270.html">https://lists.llvm.org/pipermail/llvm-dev/2021-December/154270.html</a>) of [SPIR-V backend](<a href="https://github.com/KhronosGroup/LLVM-SPIRV-Backend">https://github.com/KhronosGroup/LLVM-SPIRV-Backend</a>) to LLVM. The code has been refactored so it does not require extra changes from GlobalISel or other LLVM target-independent infrastructure. With some SPIR-V functionality missing, the new code is proposed to land as an experimental backend. There are no replies to the proposal at the time of writing.<br><br>### Commits<br><br>*  The HIP toolchain is being refactored with SPIR-V generation in mind. The old toolchain was renamed to `HIPAMDToolChain` and a new one `HIPSPVToolChain` was added. The new toolchain uses the SPIRV-LLVM-Translator as the SPIR-V LLVM backend is not ready yet. Next, the in-review patches will allow emitting SPIR-V binary using `llc`. [D110549](<a href="https://reviews.llvm.org/D110549">https://reviews.llvm.org/D110549</a>), [D110618](<a href="https://reviews.llvm.org/D110618">https://reviews.llvm.org/D110618</a>), [D110622](<a href="https://reviews.llvm.org/D110622">https://reviews.llvm.org/D110622</a>), [D110685](<a href="https://reviews.llvm.org/D110685">https://reviews.llvm.org/D110685</a>)<br>*  Documentation was added for the DWARF location descriptions, as a part of the ['Dwarf Extensions For Heterogeneous Debugging'](<a href="https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html">https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html</a>) used by AMDGPU. [D115587](<a href="https://reviews.llvm.org/D115587">https://reviews.llvm.org/D115587</a>)<br><br><br>## MLIR<br><br>### Discussions<br><br>*  Thomas Raoux is working on adding [async copy from global to shared memory to the GPU dialect](<a href="https://llvm.discourse.group/t/modeling-gpu-async-copy-ampere-feature/4924">https://llvm.discourse.group/t/modeling-gpu-async-copy-ampere-feature/4924</a>): 'async copy is a new feature in Nvidia Ampere GPUs, but other GPUs are likely to support similar feature in the future. It works like a DMA operation that copies data from global to shared memory without going through register and without blocking the execution unit. The big advantage is that it saves register usage and it allows aggressive software pipelining to hide latency.' For more details, see [the blog post](<a href="https://developer.nvidia.com/blog/controlling-data-movement-to-boost-performance-on-ampere-architecture/">https://developer.nvidia.com/blog/controlling-data-movement-to-boost-performance-on-ampere-architecture/</a>). Thomas is seeking feedback on how async copy is modeled before sending out patches for review.<br><br>### Commits<br><br><br>## OpenMP (Target Offloading)<br><br>### Discussions<br><br>### Commits<br><br>*  The new device runtime is now enabled by default for AMDGPU offloading. [D115157](<a href="https://reviews.llvm.org/D115157">https://reviews.llvm.org/D115157</a>)<br><br><br>## External Compilers<br><br>### LLPC<br><br>*  The standalone compiler tool `amdllpc` can now compile multiple shader stages together without having to provide a `.pipe` file. [LLPC#1591](<a href="https://github.com/GPUOpen-Drivers/llpc/pull/1591">https://github.com/GPUOpen-Drivers/llpc/pull/1591</a>)<br><br>### oneAPI DPC++<br><br>#### CUDA/HIP support<br><br>*  Added HIP backend support to [filter selector](<a href="https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/FilterSelector/FilterSelector.adoc">https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/FilterSelector/FilterSelector.adoc</a>) extension.<br>*  Fixed infinite loop when parallel_for range exceeds `INT_MAX`.<br>*  Fixed platform query for USM allocation information.<br>*  Improved performance on CUDA backed by reducing runtime overhead on event handling and using more efficient implementation for barrier and other synchronization built-in functions.<br><br>#### SYCL 2020 support<br><br>*  Switched blocking USM free for OpenCL GPU devices.<br>*  Fixed support for classes implicitly converted from items in `parallel_for`.<br><br>#### Non-standard extensions<br><br>*  Added support for HW threads per EU device query.<br>*  Added implementation of discard_events extension enabling optimization of queue operations.<br>*  Added experimental FPGA latency control feature.<br>*  ESIMD: Add support for an arbitrary number of elements to `simd::copy_from/to`.<br>*  Fixed `bfloat16` construction from integer.<br><br>#### Misc<br><br>*  Improved runtime library performance by reducing overhead of XPTI instrumentation.<br>*  Made initialization of host task thread pool thread-safe.<br>*  Multiple GitHub Actions continuous system improvements:<br>  *  libclc testing added to regular validation.<br>  *  Build of HIP and CUDA back-ends enabled in nightly Docker containers.<br>*  Improved runtime error diagnostics by handling `ZE_RESULT_ERROR_INVALID_ARGUMENT` and out-of-memory Level Zero error codes.<br></div><div><br></div></div>