<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">From: "Doerfert, Johannes via Openmp-dev" <<a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a>><br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> I'm proposing defining the shared variables with pragma omp target declare<br>
> and rewriting the uses of volatile to follow c++ semantics. Expecting some<br>
> clang work around address spaces and constructors.<br>
<br>
We need to give the users a way to declare shared (global and dynamic)<br>
memory anyway so figuring this out is worth it for sure.<br></blockquote><div><br></div><div>That is well observed. Accessing device memory from OpenMP is likely to be necessary on performance grounds, independent of the runtime implementation tradeoffs.</div><div><br></div><div>I can't find a description in the openmp spec for this. There is a proposal from 2017 at <a href="https://www.openmp.org/wp-content/uploads/openmp-TR5-final.pdf">https://www.openmp.org/wp-content/uploads/openmp-TR5-final.pdf</a> which describes a considerable superset of such functionality. I don't know the background there but can imagine the scope of the paper is challenging at committee stage.</div><div><br></div><div>I'd suggest following the syntax from that paper, and once the implementation is sound, propose it for inclusion in the standard. Would you be open to reviewing such? I'm not sure know how it would fit in with the current rewrite so rough pointers are welcome there. I'm also happy to write it for nvptx first.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'm in favor with a caveat. An OpenMP implementation of the runtime was<br>
on my agenda for the (far ahead) future anyway. However, we have a lot<br>
of ongoing projects and I would postpone this *iff* we have a workaround<br>
for the AMDGPU backend for now. If not, this is very reasonable.<br></blockquote><div><br></div><div>There are paths forward for the AMDGPU backend on HIP but timescales and details are unclear. The pragmatic win would be for a company that doesn't have a cuda or hip implementation and doesn't want to ship a bunch of vendor extensions to opencl.<br></div><div><br></div><div>Thanks,</div><div><br></div><div>Jon</div><div><br></div></div></div>