<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 14, 2020 at 12:20 PM Doerfert, Johannes <<a href="mailto:jdoerfert@anl.gov">jdoerfert@anl.gov</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 Sam, thanks for driving this, I really like the idea!<br>
<br>
Here are some thoughts:<br>
<br>
Make the "kind" optional if it can be deduced, as Alexey noted. So<br>
   -offload=amd-gfx900<br>
should work fine if we have an -x c and -fopenmp set. Error out if<br>
it is ambiguous.<br>
<br>
Allow multiple -offload occurrences.<br>
<br>
Keep the support of the old ways for now as well.<br>
<br>
Allow to pass the kind + triple + arch as first part of the new -offload<br>
flag and any options as a second part, so:<br>
  -offload=hip-amd-gfx906<br>
works but also does<br>
  -offload="amd-gfx906 -fvectorize" -x hip<br>
as well as<br>
  -offload="amd -march=gfx906 -fno-vectorize" -fopenmp<br>
This will make it way easier to use.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">Naming things consistently is hard. We need to consider that we'll need to pass an arbitrary complex set of options for each offload instance, whatever it may be. There may be a lot of options per individual offload instance that would differ only minimally. Having to repeat all of them will be tedious at best. We may also need to pass options further down the compilation stack. E.g. we may want different ptxas options for each CUDA target.</div></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Perhaps we could enhance the option parser to create a notion of argument scope? "Arguments in a string" approach sort of does it already in a limited way, but it would still need CLI parser changes to handle the options consistently.</div><div class="gmail_default" style="font-family:verdana,sans-serif">If we implement one scope level, making it hierarchical should not be that much harder.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Having such CLI model would allow us to do thing like this:</div><div class="gmail_default" style="font-family:verdana,sans-serif">--offload=hip-gfx9* --something-common-to-all-gfx9xx targets> </div><div class="gmail_default" style="font-family:verdana,sans-serif">   --offload=hip-gfx999 --something-for-gfx999-only</div><div class="gmail_default" style="font-family:verdana,sans-serif">--offload-end 2 // pops two levels of CLI scopes. 1 level if no argument is given.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="">The identifier could be a regex/glob match on an arbitrary string. We don't need it to carry any specific paramenters itself, they should just be meaningful enough for the parts of the code that care about particular scope to provide their 'scope string' to match against.</div><div class="gmail_default" style="">I.e. for example above, HIP toolchain would set CLI scope(s) to be hip-gfx999. There will be implicit top-level '--offload=.*' which would always match and then the parser would reparse the options taking into account only the matching scopes. This could allow us to specify both OMP and CUDA/HIP options for the same compilation -- we could conceivably benefit from OMP offload to multiple threads in the host-side compilation.</div><div class="gmail_default" style=""> <br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">It all may be an utter overkill, too. WDYT?</span></div><div class="gmail_default" style="font-family:verdana,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif"><br></span></div><div class="gmail_default" style="font-family:verdana,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">--Artem</span></div><div class="gmail_default" style="font-family:verdana,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I hope some of these make some sense :)<br>
<br>
~ Johannes<br>
<br>
<br>
On 12/12/20 8:11 AM, Liu, Yaxun (Sam) wrote:<br>
> [AMD Public Use]<br>
><br>
> Currently CUDA/HIP and OpenMP has different offloading options, e.g.<br>
><br>
> clang++  -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx900 test.cpp<br>
><br>
> clang++ -offload-arch=gfx906 test.hip<br>
><br>
> Our users request to have a concise way to specify offloading options for OpenMP. Ideally, one option to convey offloading kind, offloading triple, and offloading device arch.<br>
><br>
> On the other hand, there are some limitations of the current offloading option for CUDA/HIP:<br>
><br>
> 1. It does not specify offloading kind whereas relies on file type to infer offloading kind. If input file is not CUDA/HIP source code (e.g. bundled LLVM bit code), there needs a way to specify offloading kind.<br>
><br>
> 2. It does not specify offloading target triple whereas relies on device arch to infer target triple. As HIP is ported to different targets, there needs a way to specify offloading target triple.<br>
><br>
> In summary, a unified offloading option is preferred, which conveys offloading kind, offloading target triple and offloading device arch.<br>
><br>
> I would like to propose to either have a new option or extend the existing -offload-arch option for that, in the format kind-triple-arch, e.g.<br>
><br>
> -offload=omp-amd-gfx900<br>
><br>
> -offload=hip-amd-gfx906<br>
><br>
> Whereas kind and triple can be abbreviations for conciseness, e.g. omp expands to openmp, amd expands to amdgcn-amd-amdhsa. Arch can be omitted, in which case clang will use the default arch for the triple.<br>
><br>
> Your feedbacks are welcome.<br>
><br>
> Thanks.<br>
><br>
> Sam<br>
><br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">--Artem Belevich</div></div></div>