[llvm-dev] LLVM GPU News Issue #2, December 25 2020

Fri Dec 25 14:12:34 PST 2020

Hi folks,

The second 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/2020/12/25/issue-2.html.

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

Happy holidays,
Jakub

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

# LLVM GPU News Issue #2, December 25 2020

Welcome to the second issue of LLVM GPU News, a bi-weekly newsletter on all
the GPU things under the LLVM umbrella. This issue covers the period from
December 11 to December 24 2020.

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

*  [Portable Computing Language (PoCL) v1.6 was released](
http://portablecl.org/pocl-1.6.html).
   The release provides Clang/LLVM 11 support, in addition to the existing
   compatibility down to LLVM 6.0. CUDA backed gained several performance
   optimizations, including use of 32-bit pointer arithmetic for local
   memory, use of static CUDA memory blocks for `__local` blocks and
   function arguments, and loop unrolling heuristic tweaks.
*  [AMD released ROCm v4.0](
https://github.com/RadeonOpenCompute/ROCm/blob/master/AMD_ROCm_Release_Notes_v4.0.pdf
)
   with support for the new MI100 accelerator (HPC GPU) and its new CDNA
   architecture. CDNA is based on the previous GCN architecture and
   backward-compatible with it.

##  LLVM and Clang

### Discussions

*  Nicolai Hähnle posted a proposal on
   [abstractions over SSA form IRs to implement generic analyses](
http://lists.llvm.org/pipermail/llvm-dev/2020-December/147433.html).
   This is an attempt to restart the discussion over the previously
   [proposed CfgTraits abstraction](
http://lists.llvm.org/pipermail/llvm-dev/2020-October/145945.html)
   that was [reverted in late October 2020](
https://github.com/llvm/llvm-project/commit/e025d09b216dc2239e1b502f4f277abb6fb4648a
).
   The main motivation is to facilitate writing IR-generic analyses that
   operate on both CFG and SSA values, e.g., divergence analysis. The RFC
   comes with a [detailed overview of the C++ generic programming
techniques](
https://docs.google.com/document/d/1sbeGw5uNGFV0ZPVk6h8Q5_dRhk4qFnKHa-uZ-O3c4UY/edit?usp=sharing
)
   and thoughts on how each would fit in the existing LLVM code. Nicolai
   implemented his proposed generic abstractions in a few Phabricator
   revisions:
   *  [D92924: Introduce opaque handles for type erasure.](
https://reviews.llvm.org/D92924)
   *  [D83089: Based on the handle infrastructure, refactor the dominator
tree with type-erased base classes.](https://reviews.llvm.org/D83089)
   *  [D92925: Introduce an SsaContext context class concept for static
polymorphism.](https://reviews.llvm.org/D92925)
   *  [D92926: Introduce an ISsaContext "global" interface class for
dynamic polymorphism.](https://reviews.llvm.org/D92926)
   *  [D83094: Implement a new analysis (cycle info) written generically as
non-template code.](https://reviews.llvm.org/D83094)

   There are no replies under the thread as of writing.

*  Yaxun (Sam) Liu sent and RFC for
   [unified offloading option for CUDA/HIP/OpenMP](
http://lists.llvm.org/pipermail/cfe-dev/2020-December/067362.html).
   The proposal is to make the clang offloading options more concise by
   representing the offloading kind, target, and device architecture with a
   new triple, e.g., `-offload=omp-amd-gfx900`, `-offload=hip-amd-gfx906`.
   Artem Belevich pointed out that making the naming consistent is
   difficult because each offload instance may require an arbitrarily
   complex set of options, and options per individual offload instance may
   differ minimally. Ben Boeckel is concerned about shell quoting rules
   being difficult to get correct with a more complex argument parsing
   model.

### Commits

*  [Implement SYCL address space attributes handling.](
https://reviews.llvm.org/D89909)
   This addresses issues with pointers that have the same address space in
   Clang AST, but different one when lowered to LLVM IR.
*  (In review) [Introduce an OpenMP assumption to ignore possible external
function callers](https://reviews.llvm.org/D93079),
   `omp_no_external_caller_in_target_region`. This function attribute is
   handled by the existing OpenMP target state machine optimization.

## MLIR

### Discussions

* George Mitenkov posted an RFC on
  [converting multi-threaded SPIR-V to the LLVM dialect](
https://llvm.discourse.group/t/rfc-converting-multi-threaded-spir-v-to-llvm-dialect-overview/2463
).
  After the [initial work during the GSoC project](
https://github.com/georgemitenkov/GSoC-2020)
  that focused on single-threaded code, the next step is to handle
  multi-threaded GPU kernels with synchronization so that they can be
  compiled for CPU execution. George proposes to map each workgroup to a
  CPU thread and subgroups/invocations to SIMD vector operations.
  There are no replies under the thread as of writing.

### Commits

*  [The SPIR-V dialect learned to convert `select+cmp` into GLSL clamp.](
https://reviews.llvm.org/D93618)
*  SPIR-V (de-)serialization refactoring. The two were
   [split into separate libraries](https://reviews.llvm.org/D91548) and
   de-templated: [\[1\]](https://reviews.llvm.org/D93535), [\[2\]](
https://reviews.llvm.org/D93504).

## External Compilers

Please submit pointers to your mailing lists, forums, or newsletters if you
want your LLVM- or MLIR-based GPU compiler project to be covered in future
LLVM GPU News issues.

### CUDA

### JuliaGPU

*  Simone Azeglio and Ayaoyao214 asked about
   [overcoming slow scalar operation on GPU arrays](
https://discourse.julialang.org/t/overcoming-slow-scalar-operations-on-gpu-arrays/49554
).

### LLPC

*  Steven Perron added [support for multi-table descriptor sets](
https://github.com/GPUOpen-Drivers/llpc/pull/1074).
   This allows for experimentation with more flexible binding models than
   in the Vulkan API that currently guarantees that all resources in the
   same descriptor set will be in the same descriptor table. The patch
   lifts this assumption.

### Mesa

* Michael Tang [committed initial code for a new `spirv_to_dxil` library](
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8043).
  The plan is to use the Mesa code for WebGPU shader compilation for
  DirectX, using the following translation path: WGSL (WebGPU Shading
  Language) -> SPIR-V (IR from Khronos) -> NIR (Mesa's IR) -> DXIL (DirectX
  Intermediate Language).

### SYCL

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