<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 Thu, Mar 4, 2021 at 10:34 AM Liu, Yaxun (Sam) <<a href="mailto:Yaxun.Liu@amd.com">Yaxun.Liu@amd.com</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">[AMD Public Use]<br>
<br>
There is another aspect we need to consider: how to modify the -target option by additional options?<br>
<br>
For the existing --offload-arch option, we could use -Xarch_ to add specific options for it.<br></blockquote><div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">`-Xarch_xxx` as implemented right now is a rather limiter hack. IIRC it only accepts options w/o arguments which limits its usability.</div></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">
<br>
Assuming we have an <span class="gmail_default" style="font-family:verdana,sans-serif"></span>-offload="amdgcn -mcpu=gfx906" option, then we want to add some options specific to it by an additional option, what should we do?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">I think we've been conflating telling the driver what to compile for and customizing individual sub-compilations.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div></div><div class="gmail_default" style="font-family:verdana,sans-serif">We could explicitly separate the two tasks. E.g.:</div><div class="gmail_default" style="font-family:verdana,sans-serif">`--[no-]offload=target1,target2,target3...`</div><div class="gmail_default" style="font-family:verdana,sans-serif">`--Xoffload=target_pattern target_options...`</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">This way your example would be handled with:</div><div class="gmail_default" style="font-family:verdana,sans-serif">"--offload=gfx906,gfx1010"</div><div class="gmail_default" style="font-family:verdana,sans-serif">"--Xoffload=gfx* options common to all AMD GPUs"</div><div class="gmail_default" style="font-family:verdana,sans-serif">"--Xoffload=gfx906 -mcpu=gfx906 --fsomething-specific-to-gfx906"</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><div><div class="gmail_default">In the end `-Xarch_xxx` would become an alias for '-Xoffload=xxx'.</div></div><div> </div></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">--Artem</div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thanks.<br>
<br>
Sam<br>
<br>
-----Original Message-----<br>
From: Doerfert, Johannes <<a href="mailto:jdoerfert@anl.gov" target="_blank">jdoerfert@anl.gov</a>> <br>
Sent: Thursday, February 11, 2021 12:59 PM<br>
To: Artem Belevich <<a href="mailto:tra@google.com" target="_blank">tra@google.com</a>>; Liu, Yaxun (Sam) <<a href="mailto:Yaxun.Liu@amd.com" target="_blank">Yaxun.Liu@amd.com</a>><br>
Cc: Ben Boeckel <<a href="mailto:ben.boeckel@kitware.com" target="_blank">ben.boeckel@kitware.com</a>>; Lieberman, Ron <<a href="mailto:Ron.Lieberman@amd.com" target="_blank">Ron.Lieberman@amd.com</a>>; <a href="mailto:a.bataev@hotmail.com" target="_blank">a.bataev@hotmail.com</a>; Chan, SiuChi <<a href="mailto:siuchi.chan@amd.com" target="_blank">siuchi.chan@amd.com</a>>; Searles, Mark <<a href="mailto:Mark.Searles@amd.com" target="_blank">Mark.Searles@amd.com</a>>; cfe-dev (<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>) <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>; <a href="mailto:jeffrey.sandoval@hpe.com" target="_blank">jeffrey.sandoval@hpe.com</a>; Jon Chesterfield <<a href="mailto:jonathanchesterfield@gmail.com" target="_blank">jonathanchesterfield@gmail.com</a>><br>
Subject: Re: [cfe-dev] [RFC] Unified offloading option for CUDA/HIP/OpenMP<br>
<br>
[CAUTION: External Email]<br>
<br>
I'm OK with either.<br>
<br>
On 2/11/21 11:42 AM, Artem Belevich wrote:<br>
> On Thu, Feb 11, 2021 at 8:30 AM Liu, Yaxun (Sam) <<a href="mailto:Yaxun.Liu@amd.com" target="_blank">Yaxun.Liu@amd.com</a>> wrote:<br>
><br>
>> [AMD Public Use]<br>
>><br>
>><br>
>><br>
>> Sorry for the delay.<br>
>><br>
>><br>
>><br>
>> Both Johannes’ and Artem’s proposals should satisfy the needs of users:<br>
>><br>
>><br>
>><br>
>> Option 1:<br>
>><br>
>><br>
>><br>
>> `-offload=<offload-pattern> optA optB optC`.<br>
>><br>
>><br>
>><br>
>> Option 2:<br>
>><br>
>><br>
>><br>
>> `-offload=<offload-pattern>,optA,optB,optC`.<br>
>><br>
> I'm fine with #2. We're using something similar with our build tools <br>
> and it works reasonably well.<br>
> However, it does have one annoying corner case. There's no easy way to <br>
> pass an option which has a comma in it. E.g. if I want to pass <br>
> `-Wl,something,something`. Perhaps we could use sed-like approach and <br>
> allow changing the separator. E.g. `s/a/b/` == `s@a@b@`.<br>
><br>
> --Artem<br>
><br>
><br>
><br>
>><br>
>> Compared to the old options, they are more concise and more readable.<br>
>><br>
>><br>
>><br>
>> The main difference is the delimiter. To me option 2 is more <br>
>> attractive since it does not need quotations for most cases.<br>
>><br>
>><br>
>><br>
>> Can we reach an agreement on option 2?<br>
>><br>
>><br>
>><br>
>> Thanks.<br>
>><br>
>><br>
>><br>
>> Sam<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> *From:* Artem Belevich <<a href="mailto:tra@google.com" target="_blank">tra@google.com</a>><br>
>> *Sent:* Tuesday, December 15, 2020 2:13 PM<br>
>> *To:* Ben Boeckel <<a href="mailto:ben.boeckel@kitware.com" target="_blank">ben.boeckel@kitware.com</a>><br>
>> *Cc:* Doerfert, Johannes <<a href="mailto:jdoerfert@anl.gov" target="_blank">jdoerfert@anl.gov</a>>; Liu, Yaxun (Sam) < <br>
>> <a href="mailto:Yaxun.Liu@amd.com" target="_blank">Yaxun.Liu@amd.com</a>>; Lieberman, Ron <<a href="mailto:Ron.Lieberman@amd.com" target="_blank">Ron.Lieberman@amd.com</a>>; <br>
>> <a href="mailto:a.bataev@hotmail.com" target="_blank">a.bataev@hotmail.com</a>; Chan, SiuChi <<a href="mailto:siuchi.chan@amd.com" target="_blank">siuchi.chan@amd.com</a>>; Searles, <br>
>> Mark < <a href="mailto:Mark.Searles@amd.com" target="_blank">Mark.Searles@amd.com</a>>; cfe-dev (<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>) < <br>
>> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
>> *Subject:* Re: [cfe-dev] [RFC] Unified offloading option for <br>
>> CUDA/HIP/OpenMP<br>
>><br>
>><br>
>><br>
>> [CAUTION: External Email]<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> On Tue, Dec 15, 2020 at 10:23 AM Ben Boeckel <br>
>> <<a href="mailto:ben.boeckel@kitware.com" target="_blank">ben.boeckel@kitware.com</a>><br>
>> wrote:<br>
>><br>
>> On Mon, Dec 14, 2020 at 14:04:43 -0800, Artem Belevich via cfe-dev wrote:<br>
>>> It all may be an utter overkill, too. WDYT?<br>
>> Note that tools such as ccache and sccache generally need to be able <br>
>> to understand what's going on (I believe distcc and other distributed <br>
>> compilation tools also generally need to know too), so making it <br>
>> sensible enough for interpretation based on just the flags to be <br>
>> possible should be considered.<br>
>><br>
>><br>
>><br>
>> I think this is somewhat orthogonal to how we specify per-target options.<br>
>> Such a tool almost never knows about all possible compiler options <br>
>> and has to pass through the unknown options as-is.  However, any form of 'nested'<br>
>> options specified on the command line will have a chance to confuse <br>
>> such tool. E.g. if I want to pass '-E' to some sub-tool for a <br>
>> particular offload-target, ccache, not being aware that it's not a <br>
>> top-level compilation option, may interpret it as an attempt to preprocess the TU.<br>
>><br>
>><br>
>><br>
>> I wonder if it would make sense to just move all this per-target <br>
>> option complexity into an external response file. As far as existing <br>
>> tools are concerned, it would look like <br>
>> `--offload-options=target-opts.file` without affecting tool's general <br>
>> idea what this compilation is about to do, and the external file <br>
>> would allow us to be as flexible as we need to be to specify per-target options. It could be just a flat list of pairs `-Xarch_...<br>
>> optA`.  Or we could use YAML.<br>
>><br>
>><br>
>><br>
>> That approach, however, has its own issues and would still need to be <br>
>> optional. If it's the only way to specify offload options, that will <br>
>> complicate other use cases as now they would have to deal with <br>
>> temporary files.<br>
>><br>
>><br>
>><br>
>> Maybe a slightly modified variant of jdoefert@'s idea would work better:<br>
>><br>
>>>>>     -offload="amd -march=gfx906 -fno-vectorize" -fopenmp<br>
>><br>
>><br>
>> Implement it in a way similar to -Wl,optA,optB,optC and extend it to <br>
>> match an offload scope glob/regex.<br>
>><br>
>> E.g. `-offload=<offload-pattern>,optA,optB,optC`.<br>
>><br>
>> As far as the external tools are concerned, it's just one option to <br>
>> pass though. At the same time it should be flexible enough to apply <br>
>> the options to subset of offload targets in a human-manageable way.<br>
>><br>
>><br>
>><br>
>> --<br>
>><br>
>> --Artem Belevich<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>