<div dir="ltr">Hi folks,<br><br>The 18th issue of LLVM GPU News, a bi-weekly newsletter on all the GPU things under the LLVM umbrella, is out:<br><<a href="https://llvm-gpu-news.github.io/2021/08/20/issue-18.html" target="_blank">https://llvm-gpu-news.github.io/2021/08/20/issue-18.html</a>>.<br><br>I also pasted the content below, in case you prefer to read in your email client.<br><br>-Jakub<br><br>======================================================================<br><br># LLVM GPU News #18, Aug 20 2021<br>Authors: Jakub Kuderski, Lei Zhang<br clear="all"><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 August 6 to August 19 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>*  Henry Linjamäki posted an RFC on ['Emitting HIP device code as SPIR-V'](<a href="https://lists.llvm.org/pipermail/llvm-dev/2021-August/152062.html">https://lists.llvm.org/pipermail/llvm-dev/2021-August/152062.html</a>). The initial focus is to use SPIR-V binaries for OpenCL-like environments: HIPCL, and HIPLZ (Intel Level Zero API). Others point out that this proposal has a large overlap with what changes would be necessary for OpenCL and OpenMP offloading and that it would be preferred to keep non-HIP parts generic. Initially, the project may use the SPIRV-LLVM translator as an external tool until the SPIR-V backend (SPIR-V BE) is available. [Anastasia Stulova suggests waiting for the SPIR-V BE](<a href="https://lists.llvm.org/pipermail/llvm-dev/2021-August/152228.html">https://lists.llvm.org/pipermail/llvm-dev/2021-August/152228.html</a>), to help with its adoption and avoid having to redesign parts of the codebase.<br>*  Frank Winter is working on a JIT compiler targeting AMDGPU GCN and asked for [help with using LLD to link files passed through memory instead of files](<a href="https://lists.llvm.org/pipermail/llvm-dev/2021-August/152138.html">https://lists.llvm.org/pipermail/llvm-dev/2021-August/152138.html</a>). <br>[Fangrui Song responded](<a href="https://lists.llvm.org/pipermail/llvm-dev/2021-August/152139.html">https://lists.llvm.org/pipermail/llvm-dev/2021-August/152139.html</a>) that LLD is generally not ready to be used as a library and gave a few suggestions.<br>*  Dustin Favorite suspects that [`__nvvm_redux_sync_*` CUDA intrinsics are not working as expected](<a href="https://lists.llvm.org/pipermail/llvm-dev/2021-August/152053.html">https://lists.llvm.org/pipermail/llvm-dev/2021-August/152053.html</a>) and result in 'Illegal instruction' errors. There are no replies at the time of writing.<br><br>### Commits<br><br>*  New Clang language defines for C++ for OpenCL version 2021. The language standard is `lang_openclcpp2021`, enabled with the `-cl-std=clc++2021` flag.<br>*  Rematerialization of virtual register uses is not allowed. The change affected AMDGPU, ARM/Thumb, MIPS, RISC-V, and x86. [D106408](<a href="https://reviews.llvm.org/D106408">https://reviews.llvm.org/D106408</a>)<br>   -  Machine LICM (Loop Invariant Code Motion) will not rematterialzie instructions with virtual register uses. Such an instruction will not be hoisted out of the loop in a belief that the register allocator will sink it back if needed. This impacts AMDGPU. [D107677](<a href="https://reviews.llvm.org/D107677">https://reviews.llvm.org/D107677</a>)<br>*  `alias.scope` metadata is added to lowered AMDGPU LDS struct to improve alias analysis. [D108315](<a href="https://reviews.llvm.org/D108315">https://reviews.llvm.org/D108315</a>)<br>*  `GlobalISel` gained a combine for `PTR_ADD` with register banks. [D103326](<a href="https://reviews.llvm.org/D103326">https://reviews.llvm.org/D103326</a>)<br><br><br>## MLIR<br><br>### Discussions<br><br>*  There are questions about [marking](<a href="https://llvm.discourse.group/t/mark-gpu-launchfuncop-async/4089">https://llvm.discourse.group/t/mark-gpu-launchfuncop-async/4089</a>) `gpu::LaunchFuncOp` async and how to [lower and run](<a href="https://llvm.discourse.group/t/making-linalg-matmul-to-gpu-runnable-code/3910">https://llvm.discourse.group/t/making-linalg-matmul-to-gpu-runnable-code/3910</a>) `linalg.matmul` using CUDA.<br><br>### Commits<br><br>*  `spv.(InBounds)PtrAccessChain` ops are [defined](<a href="https://reviews.llvm.org/D108070">https://reviews.llvm.org/D108070</a>). <br><br><br>## OpenMP (Target Offloading)<br><br>### Discussions<br><br>### Commits<br><br>*  A bunch of refactoring patches by Jon Chesterfield:<br>   -  Lane masks are now represented with `uint64_t` instead of `__kmpc_impl_lanemask_t` in `deviceRTLs`. [D108317](<a href="https://reviews.llvm.org/D108317">https://reviews.llvm.org/D108317</a>)<br>   -  Replace `OMPGridValues` array with struct. [D108339](<a href="https://reviews.llvm.org/D108339">https://reviews.llvm.org/D108339</a>)<br>   -  Refactor `GridValues`: remove redundant fields and replace pointer with virtual function. [D108380](<a href="https://reviews.llvm.org/D108380">https://reviews.llvm.org/D108380</a>)<br><br><br>## External Compilers<br><br>### LLPC<br><br>### Mesa<br><br></div><div><br></div>-- <br><div dir="ltr" data-smartmail="gmail_signature"><div>Jakub Kuderski</div></div></div>