Jakub (Kuba) Kuderski via llvm-dev
2020-Dec-25 22:12 UTC
[llvm-dev] LLVM GPU News Issue #2, December 25 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>