<div dir="ltr">Hi folks,<br><br>The third issue of LLVM GPU News, a bi-weekly newsletter on all the GPU things under the LLVM umbrella, is now available at: <a href="https://llvm-gpu-news.github.io/2021/01/08/issue-3.html">https://llvm-gpu-news.github.io/2021/01/08/issue-3.html</a><div><br>I'm also pasting the content below, in case you prefer to read in your email client.<br><br>-Jakub<br><br>======================================================================<br><br># LLVM GPU News Issue #3, January 8 2021<br><br>Happy New Year! Welcome to the third issue of LLVM GPU News, a bi-weekly<br>newsletter on all the GPU things under the LLVM umbrella. This issue<br>covers the period from December 25 to January 7 2020.<br><br>We welcome your feedback and suggestions. Let us know if we missed anything<br>interesting, or want us to bring attention to your (sub)project, revisions<br>under review, or proposals. Please see the bottom of the page for details<br>on how to submit suggestions and contribute.<br><br>## Industry News and Conference Talks<br><br>*  Alyssa Rosenzweig started a blog post series on [dissecting the Apple<br>   M1 GPU](<a href="https://rosenzweig.io/blog/asahi-gpu-part-1.html">https://rosenzweig.io/blog/asahi-gpu-part-1.html</a>), which<br>   doesn't have any public documentation or open source drivers as of<br>   writing. The goal is to understand the new architecture and accelerate<br>   the development of an open source driver stack. Alyssa already<br>   committed an [early work-in-progress disassembler<br>   implementation](<a href="https://github.com/AsahiLinux/gpu/commit/35f700753635b45b743bd2e615c1801cbf982841">https://github.com/AsahiLinux/gpu/commit/35f700753635b45b743bd2e615c1801cbf982841</a>)<br>   and described the methodology and wokflow used to develop it in the<br>   blog post.<br><br>##  LLVM and Clang<br><br>### Discussions<br><br>*  Madhur Amilkanthwar asked about [using the Attributor framework to<br>   propagate the `amdgpu-flat-work-group-size` attribute in the AMDGPU<br>   backend](<a href="https://lists.llvm.org/pipermail/llvm-dev/2021-January/147584.html">https://lists.llvm.org/pipermail/llvm-dev/2021-January/147584.html</a>).<br><br>### Commits<br><br>*  (In-review) [Remove a custom `amdgpu-inline` pass and replace it with<br>   new Target Transform Info hooks.](<a href="https://reviews.llvm.org/D94153">https://reviews.llvm.org/D94153</a>)<br>   As explained, this is because the custom inliner doesn't fit well into<br>   the New Pass Manager's pipeline and has few differences compared to the<br>   main LLVM inlining pass.<br>*  [Clang won't add debugging information to NVPTX target if optimization<br>   remarks are enabled.](<a href="https://reviews.llvm.org/D94123">https://reviews.llvm.org/D94123</a>) This is because<br>   `ptxas` supports either debug builds with no optimizations or<br>   optimized builds without debug info.<br>*  [Always print error messages in the `libomptarget` CUDA<br>   plugin](<a href="https://reviews.llvm.org/D94263">https://reviews.llvm.org/D94263</a>), even with debugging<br>   disabled.<br>*  Make the [AMDGPU OpenMP target call into `deviceRTL` instead of<br>   `ockl`](<a href="https://reviews.llvm.org/D93356">https://reviews.llvm.org/D93356</a>).<br>   This allows simple OpenMP code to run without ROCm device libraries<br>   installed.<br><br>## MLIR<br><br>### Discussions<br><br>*  Lenny Guo asked for [help with generating SPIR-V binaries from the<br>   SPIR-V MLIR dialect kernels](<a href="https://llvm.discourse.group/t/generate-spirv-binary-from-mlir-dialect-kernels-to-run-it-on-ocl-runtime/2501">https://llvm.discourse.group/t/generate-spirv-binary-from-mlir-dialect-kernels-to-run-it-on-ocl-runtime/2501</a>)<br>   in order to run them with OpenCL runtime. There are no replies as of<br>   writing.<br><br>### Commits<br><br>## External Compilers<br><br>Please submit pointers to your mailing lists, forums, or newsletters if you<br>want your LLVM- or MLIR-based GPU compiler project to be covered in future<br>LLVM GPU News issues.<br><br>### JuliaGPU<br><br>### LLPC<br><br>*  The graphics API-agnostic LGC peephole optimizer learned to<br>   [fold `inttoptr ( add x, const )` into<br>   `gep ( inttoptr x, const )`](<a href="https://github.com/GPUOpen-Drivers/llpc/pull/1091">https://github.com/GPUOpen-Drivers/llpc/pull/1091</a>).<br>   This improves value tracking and facilitates load/store vectorization.<br>   LLVM's instruction combining pass cannot generally perform the same<br>   optimization, because on some systems `const` itself may be a valid<br>   pointer.<br><br>### Mesa<br><br>*  [Always split typed vertex buffer loads on AMD GFX6 and GFX10+](<a href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7751">https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7751</a>)<br>   in RADV/LLVM. This fixes hangs in [Zink](<a href="https://docs.mesa3d.org/drivers/zink.html">https://docs.mesa3d.org/drivers/zink.html</a>)<br>   (an OpenGL over Vulkan implementation) tests.<br><br>### SYCL<br>*  [Intel's oneAPI DPC++ Compiler 2020-12 got released.](<a href="https://github.com/intel/llvm/releases/tag/2020-12">https://github.com/intel/llvm/releases/tag/2020-12</a>)<br>   The release notes contain a long list of SYCL compiler and library<br>   improvements.<br><br></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div>Jakub Kuderski</div></div></div>