<div dir="ltr">Hi Johannes,<br><br>OpenMP sounds like a great addition and is well within the scope of this newsletter.<br>I think it would be best if you submitted OpenMP news as pull request or github issues for future llvm gpu news issues. This should be straightforward because all you need is to edit markdown files. For example, see <a href="https://github.com/llvm-gpu-news/llvm-gpu-news.github.io/blob/main/docs/_posts/2020-12-11-issue-1.md">https://github.com/llvm-gpu-news/llvm-gpu-news.github.io/blob/main/docs/_posts/2020-12-11-issue-1.md</a>.<br>If that doesn't work for you, feel free to send me a set of keywords and places to scan periodically for new content, e.g., phabricator search filter, mailing lists to watch, etc.<br><br>Sincerely,<br>Jakub</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 11, 2020 at 2:17 PM Johannes Doerfert via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Jakub,<br>
<br>
thanks for this effort, very interesting!<br>
<br>
OpenMP offloading is actively developed and I was even thinking<br>
to produce a irregular OpenMP newsletter. While I might still do,<br>
I think we should have the OpenMP GPU content in here as well.<br>
What is a good way to do that?<br>
<br>
~ Johannes<br>
<br>
<br>
On 12/11/20 11:26 AM, Jakub (Kuba) Kuderski via llvm-dev wrote:<br>
> Hi folks,<br>
><br>
> I'm starting a bi-weekly newsletter on all the GPU things under the LLVM<br>
> umbrella: GPU backends in LLVM, GPU dialects in MLIR, middle-end work<br>
> related to GPU compilation, external LLVM- and MLIR-based GPU compilers,<br>
> relevant conference talks, etc. I'm going to publish new issues every other<br>
> Friday on llvm-dev and a dedicated website:  <a href="https://llvm-gpu-news.github.io" rel="noreferrer" target="_blank">https://llvm-gpu-news.github.io</a><br>
> .<br>
><br>
> The first issue is available at:<br>
> <a href="https://llvm-gpu-news.github.io/2020/12/11/issue-1.html" rel="noreferrer" target="_blank">https://llvm-gpu-news.github.io/2020/12/11/issue-1.html</a>.<br>
> I'm also pasting the content below, in case you prefer to read in your<br>
> email client.<br>
><br>
> The high-level goals are to surface common themes in GPU compilation for<br>
> different hardware, and to raise awareness of the general LLVM<br>
> community about important aspects of GPU compilation.<br>
><br>
> -Jakub<br>
><br>
> ====================================================================<br>
><br>
> # LLVM GPU News Issue #1, December 11 2020<br>
><br>
> Welcome to the first issue of LLVM GPU News, a bi-weekly newsletter on all<br>
> the<br>
> GPU things under the LLVM umbrella. This issues covers the period from<br>
> November 27 to December 10 2020.<br>
><br>
> We welcome your feedback and suggestions. Let us know if we missed anything<br>
> interesting, or<br>
> want us to bring attention to your (sub)project, revisions under review, or<br>
> proposals.<br>
> Please see the bottom of the page for details on how to submit suggestions<br>
> and contribute.<br>
><br>
> ## Industry News and Conference Talks<br>
> *  [AMD published the RDNA 2 Instruction Set Architecture manual.](<br>
> <a href="https://gpuopen.com/rdna2-isa-available/" rel="noreferrer" target="_blank">https://gpuopen.com/rdna2-isa-available/</a>)<br>
>     Some notable changes from the previous GCN ISA are:<br>
>     *  ray tracing support,<br>
>     *  new dot product ALU operations for accelerated inference and deep<br>
> learning,<br>
>     *  VGPR and LDS allocation-unit size were doubled,<br>
>     *  legacy multiply-add instructions were removed (superseded by<br>
> fused-multiply-add).<br>
><br>
> ##  LLVM<br>
><br>
> ### Discussions<br>
> *  Jay Foad ran into [issues with preserved and required transitive<br>
> analyses in the Legacy Pass Manager](<br>
> <a href="http://lists.llvm.org/pipermail/llvm-dev/2020-November/146923.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2020-November/146923.html</a>)<br>
>     in AMDGPU. Jay proposes to add a new pass preservation rule, but some<br>
> existing passes currently violate it.<br>
>     There are no replies as of writing.<br>
> *  Arthur Eubanks is working [towards enabling the New Pass Manager](<br>
> <a href="http://lists.llvm.org/pipermail/llvm-dev/2020-December/147004.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2020-December/147004.html</a>).<br>
>     Arthur looked into AMDGPU support for the NPN and points out that<br>
>     [passes that depended on `TargetMachine::adjustPassManager` need to be<br>
> tweaked to work with the NPN](<br>
> <a href="http://lists.llvm.org/pipermail/llvm-dev/2020-December/147130.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2020-December/147130.html</a>).<br>
> *  João Paulo L. de Carvalho asked about<br>
>     [modeling address space casts in the Scalar Evolution analysis](<br>
> <a href="http://lists.llvm.org/pipermail/llvm-dev/2020-November/146927.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2020-November/146927.html</a>).<br>
>     This prevents simple SYCL loops from being vectorized. There are no<br>
> replies as of writing.<br>
> *  Nichols A. Romero proposed to add Fortran tests to the LLVM Test Suite.<br>
>     [The tests will focus on language features, high-performance proxy<br>
> programs, and OpenMP multi-threading and GPU offloading.](<br>
> <a href="http://lists.llvm.org/pipermail/llvm-dev/2020-November/146873.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2020-November/146873.html</a>)<br>
>     The response seems overwhelmingly positive so far.<br>
><br>
> ### Commits<br>
> *  (In-review) Ongoing work and discussion on<br>
>     [Adding convergence control operand bundle and intrinsics](<br>
> <a href="https://reviews.llvm.org/D85603" rel="noreferrer" target="_blank">https://reviews.llvm.org/D85603</a>) to LLVM IR.<br>
> *  [Clang Offload Bundler gained AMDGPU code object V4 ABI documentation.](<br>
> <a href="https://reviews.llvm.org/D92434" rel="noreferrer" target="_blank">https://reviews.llvm.org/D92434</a>)<br>
> *  Various fixes to AMDGPU assembler diagnostics: [\[1\]](<br>
> <a href="https://reviews.llvm.org/D92084" rel="noreferrer" target="_blank">https://reviews.llvm.org/D92084</a>),<br>
>     [\[2\]](<a href="https://reviews.llvm.org/D92115" rel="noreferrer" target="_blank">https://reviews.llvm.org/D92115</a>), [\[3\]](<br>
> <a href="https://reviews.llvm.org/D92654" rel="noreferrer" target="_blank">https://reviews.llvm.org/D92654</a>).<br>
> *  (In-review) [Don't sink ptrtoint/inttoptr sequences into non-noop<br>
> address space casts.](<a href="https://reviews.llvm.org/D92210" rel="noreferrer" target="_blank">https://reviews.llvm.org/D92210</a>)<br>
>     This resolves an [illegal memory access with atomic shared memory<br>
> JuliaGPU bug](<a href="https://github.com/JuliaGPU/CUDA.jl/issues/558" rel="noreferrer" target="_blank">https://github.com/JuliaGPU/CUDA.jl/issues/558</a>).<br>
> *  [CUDA/HIP hostness function overloading fixes.](<br>
> <a href="https://reviews.llvm.org/D80450" rel="noreferrer" target="_blank">https://reviews.llvm.org/D80450</a>)<br>
>     A new `-fgpu-exclude-wrong-side-overloads` Clang flag controls the<br>
> related behavior.<br>
><br>
> ## MLIR<br>
><br>
> ### Discussions<br>
><br>
> ### Commits<br>
> *  [`gpu.allocate` and `gpu.deallocate` ops were added to runtime function<br>
> calls.](<a href="https://reviews.llvm.org/D91698" rel="noreferrer" target="_blank">https://reviews.llvm.org/D91698</a>)<br>
> *  The `GpuAsyncRegionPass` learned to<br>
>     [move `gpu.wait` ops from `async.execute` regions to its dependencies](<br>
> <a href="https://reviews.llvm.org/D90346" rel="noreferrer" target="_blank">https://reviews.llvm.org/D90346</a>).<br>
>     This prevents unnecessary host synchronization.<br>
><br>
> ## External Compilers<br>
><br>
> Please submit pointers to your mailing lists, forums, or newsletters if you<br>
> want your LLVM-<br>
> or MLIR-based GPU compiler project to be covered in future LLVM GPU News<br>
> issues.<br>
><br>
> ### CUDA<br>
><br>
> ### JuliaGPU<br>
><br>
> ### LLPC<br>
><br>
> ### Mesa<br>
><br>
> ### SYCL<br>
><br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div>Jakub Kuderski</div></div>