[prev in list] [next in list] [prev in thread] [next in thread]
List: cfe-dev
Subject: Re: [cfe-dev] [RFC][OpenMP][CUDA] Unified Offloading Support in Clang Driver
From: Samuel F Antao via cfe-dev <cfe-dev () lists ! llvm ! org>
Date: 2016-02-25 20:51:51
Message-ID: CAK4VZWBXKCusgPOEORJt6ROmr7ZZB3ivX0LpuPaNHs5E5qGKeA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi Jonas,
2016-02-25 15:39 GMT-05:00 Hahnfeld, Jonas via cfe-dev <
cfe-dev@lists.llvm.org>:
> Hi Samuel,
>
>
>
> *From:* samuelfantao@gmail.com [mailto:samuelfantao@gmail.com] *On Behalf
> Of *Samuel F Antao
> *Sent:* Thursday, February 25, 2016 8:55 PM
> *To:* Hahnfeld, Jonas
> *Cc:* Samuel F Antao; cfe-dev@lists.llvm.org; Alexey Bataev; John McCall
> *Subject:* Re: [cfe-dev] [RFC][OpenMP][CUDA] Unified Offloading Support
> in Clang Driver
>
>
>
> Hi Jonas,
>
>
>
>
>
>
>
> 2016-02-25 10:51 GMT-05:00 Hahnfeld, Jonas via cfe-dev <
> cfe-dev@lists.llvm.org>:
>
> Hi Samuel,
>
>
>
> Thanks for your work, I would really much like to see OpenMP offloading
> implemented in clang!
>
> I can't judge the necessary changes to the driver infrastructure but will
> rather focus on an end-user view…
>
>
>
> *From:* samuelfantao@gmail.com [mailto:samuelfantao@gmail.com] *On Behalf
> Of *Samuel F Antao
> *Sent:* Thursday, February 25, 2016 1:02 AM
> *To:* cfe-dev@lists.llvm.org
> *Cc:* Alexey Bataev; Hal Finkel; John McCall; echristo@gmail.com;
> tra@google.com; Hahnfeld, Jonas
> *Subject:* [RFC][OpenMP][CUDA] Unified Offloading Support in Clang Driver
>
>
>
> […]
>
> g) Reflect the offloading programming model in the naming of the
> save-temps files.
>
> Given that the same action is interpreted by different toolchains, if
> using save-temps the resulting file could be append with the programming
> model name by the target triple so that files don't get overwritten.
>
>
>
> E.g. for OpenMP one would get a.bc and a-openmp-<triple>.bc if the driver
> is invoked with 'clang -c -save-temps a.c'.
>
> So these temporary files would all be unbundled so that they can be worked
> with as before? Or do you intend to save the bundled file as well?
> a-openmp-<triple>.bc might get you into troubles if you are using the same
> triple for host and device…
>
>
>
> All the intermediate files would be saved as today, only with the extra
> suffix to avoid conflicts. The bundled file is the output requested by the
> user so it would be saved regardless of the save-temps option.
>
>
>
> You are right, we should also use "host" and "device" to avoid problems
> when the same triple is used. I think I was proposing that already in
> D9888, just forgot to mention it here. Sorry about that.
>
>
>
>
>
> h) Use special options -target-offload=<triple> to specify offloading
> targets and delimit options meant for a toolchain.
>
> To avoid the proliferation of driver (and possibly frontend) options that
> are specific for a programming model I propose a new option that would
> specify an offloading device and have all the options following it
> processed for its toolchain. This would allow using the already existing
> options like -mcpu or -L/-l to tune the implementation for a given machine
> or provide linking commands that only make sense for the device.
>
>
>
> As an hypothetical example, lets assume we wanted to compile code that
> uses both CUDA for a nvptx64 device, OpenMP for an x86_64 device, and a
> powerpc64le host, one could invoke the driver as:
>
>
>
> clang -target powerpc64le-ibm-linux-gnu <more host options>
>
> -target-offload=nvptx64-nvidia-cuda -fcuda -mcpu sm_35 <more options for
> the nvptx toolchain>
>
> -target-offload=x86_64-pc-linux-gnu -fopenmp <more options for the x86_64
> toolchain>
>
> -target-offload=host <more options for the host>
>
> -target-offload=all <options for all toolchains>
>
>
>
> -fcuda or -fopenmp (or any other flag specifying a programming model)
> associated with an offload target would specify the programming model to be
> used for that target, and an error would be emitted if no programming model
> flag is found. I am also proposing having as special target-offload devices
> "host" and "all" to provide a convenient way for the user to pass options
> for all toolchains or to the host.
>
> Would you have to specify ‘-fopenmp' twice if you want to use OpenMP on
> the host as well? I'm asking because I'm interpreting your proposal that
> ‘-target-offload' consumes all following options only for this specific
> target…
>
>
>
> Yes. However I'm open to have a behavior that infers it based on the host
> options or input files (like *.cu in CUDA). However, if two different
> programming models are used in the same compilation unit, it has to be
> explicitly specified.
>
>
>
> That's true. I'm fine about specifying it explicitly in the first
> implementation, maybe we can later on think about some "magic guessing" if
> only one model is provided.
>
Yes. I'd also like to hear the feedback of the CUDA developers about this
to understand what are they users' expectations. I think that one probably
wants to at least do an initial guess for the CUDA file extensions.
Thanks,
Samuel
>
>
> Thanks,
>
> Jonas
>
>
>
>
>
> Thanks!
>
> Samuel
>
>
>
> […]
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
[Attachment #5 (text/html)]
<div dir="ltr">Hi Jonas,<br><div class="gmail_extra"><br><div \
class="gmail_quote">2016-02-25 15:39 GMT-05:00 Hahnfeld, Jonas via cfe-dev <span \
dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" \
target="_blank">cfe-dev@lists.llvm.org</a>></span>:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p \
class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi \
Samuel,<u></u><u></u></span></p><p class="MsoNormal"><u></u> <u></u></p><div \
style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div><div \
style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0cm 0cm"><p \
class="MsoNormal"><b><span lang="DE" \
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span \
lang="DE" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> \
<a href="mailto:samuelfantao@gmail.com" target="_blank">samuelfantao@gmail.com</a> \
[mailto:<a href="mailto:samuelfantao@gmail.com" \
target="_blank">samuelfantao@gmail.com</a>] <b>On Behalf Of </b>Samuel F \
Antao<br><b>Sent:</b> Thursday, February 25, 2016 8:55 PM<br><b>To:</b> Hahnfeld, \
Jonas<br><b>Cc:</b> Samuel F Antao; <a href="mailto:cfe-dev@lists.llvm.org" \
target="_blank">cfe-dev@lists.llvm.org</a>; Alexey Bataev; John \
McCall<br><b>Subject:</b> Re: [cfe-dev] [RFC][OpenMP][CUDA] Unified Offloading \
Support in Clang Driver<u></u><u></u></span></p></div></div><p \
class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">Hi \
Jonas,<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p \
class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> \
<u></u></p><div><div><div class="h5"><p class="MsoNormal">2016-02-25 10:51 GMT-05:00 \
Hahnfeld, Jonas via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" \
target="_blank">cfe-dev@lists.llvm.org</a>>:<u></u><u></u></p><div><div><p \
class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi \
Samuel,</span><u></u><u></u></p><p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> \
</span><u></u><u></u></p><p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks \
for your work, I would really much like to see OpenMP offloading implemented in \
clang!</span><u></u><u></u></p><p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I \
can't judge the necessary changes to the driver infrastructure but will rather focus \
on an end-user view…</span><u></u><u></u></p><p class="MsoNormal"> \
<u></u><u></u></p><div style="border:none;border-left:solid blue 1.5pt;padding:0cm \
0cm 0cm 4.0pt"><div><div style="border:none;border-top:solid #b5c4df \
1.0pt;padding:3.0pt 0cm 0cm 0cm"><p class="MsoNormal"><b><span \
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span \
style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> <a \
href="mailto:samuelfantao@gmail.com" target="_blank">samuelfantao@gmail.com</a> \
[mailto:<a href="mailto:samuelfantao@gmail.com" \
target="_blank">samuelfantao@gmail.com</a>] <b>On Behalf Of </b>Samuel F \
Antao<br><b>Sent:</b> Thursday, February 25, 2016 1:02 AM<br><b>To:</b> <a \
href="mailto:cfe-dev@lists.llvm.org" \
target="_blank">cfe-dev@lists.llvm.org</a><br><b>Cc:</b> Alexey Bataev; Hal Finkel; \
John McCall; <a href="mailto:echristo@gmail.com" \
target="_blank">echristo@gmail.com</a>; <a href="mailto:tra@google.com" \
target="_blank">tra@google.com</a>; Hahnfeld, Jonas<br><b>Subject:</b> \
[RFC][OpenMP][CUDA] Unified Offloading Support in Clang \
Driver</span><u></u><u></u></p></div></div><p class="MsoNormal"> \
<u></u><u></u></p><div><p class="MsoNormal"><span \
style="color:#1f497d">[…]</span><u></u><u></u></p><p class="MsoNormal">g) Reflect \
the offloading programming model in the naming of the save-temps \
files.<u></u><u></u></p><p class="MsoNormal">Given that the same action is \
interpreted by different toolchains, if using save-temps the resulting file could be \
append with the programming model name by the target triple so that files don't get \
overwritten.<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p \
class="MsoNormal">E.g. for OpenMP one would get a.bc and a-openmp-<triple>.bc \
if the driver is invoked with 'clang -c -save-temps a.c'.<u></u><u></u></p><p \
class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">So \
these temporary files would all be unbundled so that they can be worked with as \
before? Or do you intend to save the bundled file as \
well?<br>a-openmp-<triple>.bc might get you into troubles if you are using the \
same triple for host and \
device…</span><u></u><u></u></p></div></div></div></div><div><p \
class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">All the \
intermediate files would be saved as today, only with the extra suffix to avoid \
conflicts. The bundled file is the output requested by the user so it would be saved \
regardless of the save-temps option.<u></u><u></u></p></div><div><p \
class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">You are right, \
we should also use "host" and "device" to avoid problems when the \
same triple is used. I think I was proposing that already in D9888, just forgot to \
mention it here. Sorry about that.<u></u><u></u></p></div><div><p class="MsoNormal"> \
<u></u><u></u></p></div><blockquote style="border:none;border-left:solid #cccccc \
1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm"><div><div><div \
style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div><p \
class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">h) Use special options \
-target-offload=<triple> to specify offloading targets and delimit options \
meant for a toolchain.<u></u><u></u></p><p class="MsoNormal">To avoid the \
proliferation of driver (and possibly frontend) options that are specific for a \
programming model I propose a new option that would specify an offloading device and \
have all the options following it processed for its toolchain. This would allow using \
the already existing options like -mcpu or -L/-l to tune the implementation for a \
given machine or provide linking commands that only make sense for the \
device.<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p \
class="MsoNormal">As an hypothetical example, lets assume we wanted to compile code \
that uses both CUDA for a nvptx64 device, OpenMP for an x86_64 device, and a \
powerpc64le host, one could invoke the driver as:<u></u><u></u></p><p \
class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">clang -target \
powerpc64le-ibm-linux-gnu <more host options><u></u><u></u></p><p \
class="MsoNormal">-target-offload=nvptx64-nvidia-cuda -fcuda -mcpu sm_35 <more \
options for the nvptx toolchain><u></u><u></u></p><p \
class="MsoNormal">-target-offload=x86_64-pc-linux-gnu -fopenmp <more options for \
the x86_64 toolchain><u></u><u></u></p><p class="MsoNormal">-target-offload=host \
<more options for the host><u></u><u></u></p><p \
class="MsoNormal">-target-offload=all <options for all \
toolchains><u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p \
class="MsoNormal">-fcuda or -fopenmp (or any other flag specifying a programming \
model) associated with an offload target would specify the programming model to be \
used for that target, and an error would be emitted if no programming model flag is \
found. I am also proposing having as special target-offload devices "host" and "all" \
to provide a convenient way for the user to pass options for all toolchains or to the \
host.<u></u><u></u></p><p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Would \
you have to specify ‘-fopenmp' twice if you want to use OpenMP on the host as well? \
I'm asking because I'm interpreting your proposal that ‘-target-offload' consumes \
all following options only for this specific \
target…</span><u></u><u></u></p></div></div></div></div></blockquote><div><p \
class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Yes. However \
I'm open to have a behavior that infers it based on the host options or input \
files (like *.cu in CUDA). However, if two different programming models are used in \
the same compilation unit, it has to be explicitly \
specified.<u></u><u></u></p></div></div></div><div><p class="MsoNormal"><span \
style="color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">That's \
true. I'm fine about specifying it explicitly in the first implementation, maybe we \
can later on think about some "magic guessing" if only one model is \
provided.</span></p></div></div></div></div></div></div></div></blockquote><div><br></div><div>Yes. \
I'd also like to hear the feedback of the CUDA developers about this to \
understand what are they users' expectations. I think that one probably wants to \
at least do an initial guess for the CUDA file extensions. \
</div><div><br></div><div>Thanks,</div><div>Samuel</div><div> </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><div \
style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm \
4.0pt"><div><div><div><div><p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p><p \
class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> \
<u></u></span></p><p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks,<u></u><u></u></span></p><p \
class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Jonas<u></u><u></u></span></p><p \
class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> \
<u></u></span></p><p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> \
<u></u></span></p></div><span class=""><div><p \
class="MsoNormal">Thanks!<u></u><u></u></p></div><div><p \
class="MsoNormal">Samuel<u></u><u></u></p></div><div><p class="MsoNormal"> \
<u></u><u></u></p></div><blockquote style="border:none;border-left:solid #cccccc \
1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm"><div><div><div \
style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div><p \
class="MsoNormal"><span \
style="color:#1f497d">[…]</span><u></u><u></u></p></div></div></div></div><p \
class="MsoNormal" style="margin-bottom:12.0pt"><br>_______________________________________________<br>cfe-dev \
mailing list<br><a href="mailto:cfe-dev@lists.llvm.org" \
target="_blank">cfe-dev@lists.llvm.org</a><br><a \
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" \
target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><u></u><u></u></p></blockquote></span></div><p \
class="MsoNormal"><u></u> \
<u></u></p></div></div></div></div></div><br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" \
target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br> \
<br></blockquote></div><br></div></div>
[Attachment #6 (text/plain)]
_______________________________________________
cfe-dev mailing list
cfe-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic