<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>