[llvm-dev] LLVM GPU News Issue #13, June 4 2021

Jakub (Kuba) Kuderski via llvm-dev llvm-dev at lists.llvm.org
Fri Jun 4 09:15:35 PDT 2021


Hi folks,

The 13th 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/06/04/issue-13.html>.

I also pasted the content below, in case you prefer to read in your email
client.

-Jakub

======================================================================

# LLVM GPU News Issue #13, June 4 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 May 21 to June 3 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

*  LLVM-CTH: [The Second Workshop on LLVM Compiler and Tools for HPC](
https://hps.vi4io.org/events/2021/llvm) features multiple GPU centric talks.


##  LLVM and Clang

### Discussions

*  Sameer Sahasrabuddhe posted an [RFC for making function calls
`convergent` by default](
https://lists.llvm.org/pipermail/llvm-dev/2021-June/150814.html). On GPU
targets, "A convergent operation involves inter-thread communication or
synchronization that occurs outside of the memory model, where the set of
threads which participate in communication is implicitly affected by
control flow". The RFC proposed to conservatively make calls `convergent`
by default, and to add the `noconvergent` attribute to indicate that a call
is not sensitive to the set of threads executing any dynamic instance of
that call. This way, "Frontends are no longer required to add a
`convergent` or `noconvergent` attribute if all they seek is correct
execution on GPUs".
*  ggllvm is seeking [help with OpenCL kernel compilation for AMDGPU on
Discourse](
https://llvm.discourse.group/t/tried-to-compile-opencl-kernel-got-close-but-not-quite/3534).
The only suggestion so far did not resolve their problem.

### Commits

*  [CUDA/HIP compilation now defaults to C++14](
https://reviews.llvm.org/D103221) instead of C++98. This change makes it
match the default C++ standard version used by Clang and nvcc, while GCC
already defaults to C++17.
*  HIP now [supports ThinLTO compilation for the AMDGPU target](
https://reviews.llvm.org/D99683). This is controlled by new Clang flags:
`-[no-]offload-lto` and `-foffload-lto=[thin,full]`.
*  HIP device library detection [has been fixed](
https://reviews.llvm.org/D103281) for the [Spack package manager](
https://spack.io/).


## MLIR

### Discussions

* Thomas Raoux is asking about [using the new `GPU_MMAMatrix` type with
Standard ops](
https://llvm.discourse.group/t/using-gpu-type-with-standard-ops/3542)
without having the Standard dialect depend on the GPU dialect. Geoffrey
Martin-Noble pointed out that "standard ops only operate on (a subset of)
builtin types, but perhaps we could consider turning `ShapedType` into an
interface".

### Commits

* GPU MMA store ops are [relaxed](https://reviews.llvm.org/D103023) to
allow chain of MMA ops.
* SPIR-V dialect starts to see better [assembly](
https://reviews.llvm.org/D103152) [result](https://reviews.llvm.org/D103594)
names.
* `spv.module` now has `SingleBlock` and `NoTerminator` traits;
`spv.endmodule` is [retired](https://reviews.llvm.org/D103265).


## OpenMP (Target Offloading)

### Discussions

* An [OpenMP offloading buildbot](https://lab.llvm.org/staging/#/workers/118)
is available in the LLVM buildbot staging area.
* OMPD upstreaming continues with discussions: [D100181](
https://reviews.llvm.org/D100181).
* The patchsets for reworked globalization ([D97680](
https://reviews.llvm.org/D97680) and following) and custom state machines
([D101976](https://reviews.llvm.org/D101976) and following) are almost
ready.
* AMD are reworking the `__shared__` / `__local` implementation for higher
efficiency.
* Linking of static archives with offload code is being worked on again:
[D93525](https://reviews.llvm.org/D93525).

### Commits

* We are replacing libelf with the ELF facilities in LLVM core to cut down
on dependencies and work towards offloading on non-Linux platforms:
[D103545](https://reviews.llvm.org/D103545).
* Multiple refactoring commits to the amdgpu plugin, mainly removing global
state ([D103600](https://reviews.llvm.org/D103600), [D103509](
https://reviews.llvm.org/D103509), ...).
* Various bug fixes: [D103642](https://reviews.llvm.org/D103642), [D103646](
https://reviews.llvm.org/D103646).


## External Compilers

### LLPC

*  The [number of allowed InstCombine iterations was tightened](
https://github.com/GPUOpen-Drivers/llpc/pull/1254). This improves
compilation times by 3% on average.

### Mesa

*  [llvmpipe](https://docs.mesa3d.org/drivers/llvmpipe.html), a software
OpenGL renderer implementation, dropped support for old LLVM versions and
now [requires at least LLVM 3.9](
https://cgit.freedesktop.org/mesa/mesa/commit/?id=54e7353fa60ba3a93679b733a6c9cb8fe8bb4ab6
).


-- 
Jakub Kuderski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210604/6f5ab10c/attachment.html>


More information about the llvm-dev mailing list