[llvm-dev] LLVM GPU News Issue #8, March 19 2021

Fri Mar 19 08:53:53 PDT 2021

Hi folks,

The 8th 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/19/issue-8.html>.

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

-Jakub

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

# LLVM GPU News Issue #8, March 19 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 March 5 to March 18 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 and Clang

### Discussions
*  Johannes Doerfert asks about [NVPTX support for llvm math functions](
https://lists.llvm.org/pipermail/llvm-dev/2021-March/149117.html) (e.g.,
`llvm.sin`). NVPTX does not provide `libc` and `libm`, though some math
functions are implemented through the `libdevice` bitcode module. A
solution would be to teach Clang or the LLVM middleend how to match
`__nv_*` functions to the LLVM ones. Johannes [implemented a prototype](
https://reviews.llvm.org/D98516) that adds such function mapping support
through LLVM IR attributes.
*  Jay Foad expressed interest in [using llvm-mca for AMDGPU](
https://lists.llvm.org/pipermail/llvm-dev/2021-March/149068.html) and asked
about the difference between `MicroOpBufferSize=0/1`. Based on the response
from Andrew Trick, Jay implemented a patch that adds [llvm-mca support for
in-order CPUs](https://reviews.llvm.org/D98356).
*  Konrad Trifunovic [summarized the discussion on upstreaming a SPIR-V
backend](https://lists.llvm.org/pipermail/llvm-dev/2021-March/149175.html)
and shared a rough plan with short and long-term objectives.
*  Anastasia Stulova summarized the discussion on [a new file extension for
C++ OpenCL sources](
https://lists.llvm.org/pipermail/cfe-dev/2021-March/067936.html). The
default would be `.clcpp` now, matching the  compiler option
`-cl-std=clc++`. The [Phabricator Clang patch](
https://reviews.llvm.org/D96771) is awaiting any last feedback before
committing.

### Commits

*  AMDGPU switched from using individual cache operands (GLC, SLC, DLC) to
a [single `cache_policy` bitmask operand](https://reviews.llvm.org/D96469).
This reduces the amount of Machine IR code.
*  Fixes for the GFX90a AMDGPU target:
   -  [disable lds_direct](https://reviews.llvm.org/D96469),
   -  [SCC support on buffer atomics](https://reviews.llvm.org/D98731).
*  Split some of the AMDGPU instructions predicated on the `dot2-insts`
target feature [into a new `dot7-insts`](https://reviews.llvm.org/D98717),
in preparation for subtargets that have some but not all of these
instructions.
*  SYCL driver options were reworked. A [new language option
(`SYCLIsHost`)](https://reviews.llvm.org/D97717) is used to identify host
executions. `-fsycl` and `-fno-sycl` became driver-only options rejected
when passed to `-cc1`.
*  (In-review) HIP diagnostic for [aggregate arguments containing
half-precision types](https://reviews.llvm.org/D98143). GCC and Clang do
not have a consistent ABI for half-precision types, so passing these
between the two compilers may result in Undefined Behavior.

## MLIR

### Discussions

### Commits

*  CUDA/ROCDL kernel to blob conversion is now in [a pass](
https://reviews.llvm.org/D98279) registered to `mlir-opt`.
*  [`mlir-cuda-runner`](https://reviews.llvm.org/D98396) and
[`mlir-rocm-runner`](https://reviews.llvm.org/D98447) are gone; integration
tests now use `mlir-opt` and `mlir-cpu-runner`.
*  The SPIR-V dialect sees more ops for Vulkan graphics: [`spv.Image`](
https://reviews.llvm.org/D98270).
*  A few more patches landed into the SPIR-V dialect to improve op naming
consistency.

## OpenMP (Target Offloading)

### Discussions

 * The redesign of the [memory globalization for GPUs](
https://reviews.llvm.org/D97680) is making progress. The [original patch](
https://reviews.llvm.org/D90670) has been refined and entered the testing
stage. Alone it will regress performance significantly but it opens the
possibility to optimize the code further. The [first optimization](
https://reviews.llvm.org/D97818) has been approved.
 * A [redesign of the device runtime](
https://github.com/jdoerfert/llvm-project/tree/feature/openmp_no_dynamic_device_schedule)
has been started, based on earlier, smaller patches ([\[1\]](
https://reviews.llvm.org/D98349), [\[2\]](https://reviews.llvm.org/D98678)).
The overall process is not done but the various bugs in our OpenMP handling
have been already found: [\[3\]](https://bugs.llvm.org/show_bug.cgi?id=49649),
[\[4\]](https://bugs.llvm.org/show_bug.cgi?id=49636), [\[5\]](
https://bugs.llvm.org/show_bug.cgi?id=49468).

### Commits

*  Initial [support for the OpenMP 5.1 `interop` directive](
https://reviews.llvm.org/D98558) has been committed. This adds basic
parsing/sema/serialization support for [`#pragma omp interop`](
https://www.openmp.org/spec-html/5.1/openmpsu71.html).
*  Only [build one bitcode library for each SM](
https://reviews.llvm.org/D97198) on NVPTX targets.
*  The AMDGPU host plugin is now [built by default](
https://reviews.llvm.org/D98654).
*  The AMDGPU device runtime was briefly [built by default](
https://reviews.llvm.org/D98658) but there are issues if the AMDGPU target
is not available and the patch has been reverted until those are cleared.
*  As a middle step in the device runtime redesign we [removed 20% of the
memory allocated to support dynamic scheduling](
https://reviews.llvm.org/D98678) in favor of dynamic allocations. You will
notice only the memory savings if you do not run dynamic schedules on the
device (which you probably should not).

## External Compilers

### LLPC
*  LLPC switched to using the [upstream LLVM implementation of demote to
helper](https://github.com/GPUOpen-Drivers/llpc/pull/1184). This is used by
the discard-to-demote transformation that allows shaders with the `OpKill`
SPIR-V instructions to behave like a helper invocation ([see
`OpDemoteToHelperInvocationEXT`](
https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_shader_demote_to_helper_invocation.html))
instead of terminating the thread.

### Mesa
*  Initial [support for GFX90A](
https://cgit.freedesktop.org/mesa/mesa/log/?qt=grep&q=aldebaran) AMDGPU
landed.

### SYCL

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