[llvm-dev] LLVM GPU News Issue #7, March 5 2021
Jakub (Kuba) Kuderski via llvm-dev
llvm-dev at lists.llvm.org
Fri Mar 5 08:56:47 PST 2021
The 7th issue of LLVM GPU News, a bi-weekly newsletter on all
the GPU things under the LLVM umbrella, is now available at <
I'm also pasting the content below, in case you prefer to read in your
# 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
* 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](
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.
* 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.
* A few patches landed into the SPIR-V dialect to improve op naming
## OpenMP (Target Offloading)
* 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
* The OpenMP subproject is now [clang-formatted](
* Various bugs have been fixed, including but not limited to:
* [PR49334](https://llvm.org/PR49334): [fix](
* [PR49250](https://llvm.org/PR49250): [fix](
## External Compilers
* lavapipe, a CPU Vulkan implementation, can now [run the `vkcube` sample
Vulkan application on Windows](
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev