Jakub (Kuba) Kuderski via llvm-dev
2021-Mar-05 16:56 UTC
[llvm-dev] LLVM GPU News Issue #7, March 5 2021
Hi folks, The 7th issue of LLVM GPU News, a bi-weekly newsletter on all the GPU things under the LLVM umbrella, is now available at < https://llvm-gpu-news.github.io/2021/03/05/issue-7.html>. I'm also pasting the content below, in case you prefer to read in your email client. -Jakub ===================================================================== # LLVM GPU News Issue #7, March 5 2021 Authors: Jakub Kuderski, Johannes Doerfert, Lei Zhang Welcome to LLVM GPU News, a bi-weekly newsletter on all the GPU things under the LLVM umbrella. This issue covers the period from February 19 to March 4 2021. 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. ## Industry News and Conference Talks * [PyTorch 1.8 was released](https://pytorch.org/blog/pytorch-1.8-released/) and for the first time includes AMD ROCm support. AMD GPU binaries are available through the [PyTorch installation selector]( https://pytorch.org/get-started/locally/), where you can select `ROCm 4.0 (beta)` as the Compute Platform of choice. ## LLVM and Clang ### Discussions * Konrad Trifunovic of Intel [proposes to upstream a SPIR-V backend]( https://lists.llvm.org/pipermail/llvm-dev/2021-March/148905.html) for LLVM. The implementation would be primarily based on GlobalISel and produce the kernel flavor of SPIR-V (for OpenCL), with a future possibility of being extended to the shader flavor (for Vulkan). A long discussion followed the RFC, mostly revolving around the question whether this should be a new LLVM backend, or implemented leveraging MLIR, and how to eventually unify to avoid duplication. The existing SPIR-V support in MLIR targets mostly the shader flavor, with community interests and contributions to grow support for kernel favor too. The big hurdle for reusing the implementation is that it's not currently possible to directly emit MLIR from the LLVM infrastructure and Clang. * Sebastian Neubauer of AMD described the [current state of register spilling, function calls, and related problems]( https://llvm.discourse.group/t/the-current-state-of-spilling-function-calls-and-related-problems/2863) in [SIMT](https://en.wikipedia.org/wiki/Single_instruction,_multiple_threads) targets, e.g., AMDGPU. These start with LLVM IR expressing a single execution thread, instead of multiple threads executing the same instructions in lockstep. In Machine IR, multiple execution threads are represented implicitly. This causes issues for operations that involve more than a single vector lane. Sebastian suggests that the long term solution for some of the problems would be tracking the live ranges of VGPR registers of other lanes. ### Commits * Clang driver for HIP will [detect ROCm installations built by Spack]( https://reviews.llvm.org/D97340). [Spack is a package manager for supercomputers](https://spack.io/), used in the HPC community. * Clang options [`-munsafe-fp-atomics`](https://reviews.llvm.org/D97967) and [`-mconstructor-aliases`](https://reviews.llvm.org/D97959) will be off by default on HIP. They do not work with AMDGPU. ## MLIR ### Discussions ### Commits * A few patches landed into the SPIR-V dialect to improve op naming consistency. ## OpenMP (Target Offloading) ### Discussions * We are working towards the optimization of "globalized" locals in OpenMP target regions ([D97680](https://reviews.llvm.org/D97680)), this is supposed to get us `-fopenmp-cuda-mode` performance while preserving OpenMP semantics. ### Commits * The OpenMP subproject is now [clang-formatted]( https://reviews.llvm.org/D97088). * Various bugs have been fixed, including but not limited to: * [PR49334](https://llvm.org/PR49334): [fix]( https://reviews.llvm.org/D97329), * [PR49250](https://llvm.org/PR49250): [fix]( https://reviews.llvm.org/D97012). ## External Compilers ### LLPC ### Mesa * lavapipe, a CPU Vulkan implementation, can now [run the `vkcube` sample Vulkan application on Windows]( https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7208#note_808941). ### SYCL -- Jakub Kuderski -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210305/c41efa4d/attachment.html>