<div dir="ltr">Hi Jonas<div class="gmail_extra"><br><div class="gmail_quote">2016-02-25 15:29 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"><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">I suppose a) would then fail at runtime and fallback to the host version? That would be fine.</span></p></div></div></blockquote><div><br></div><div>Correct. The host code has already the offloading machinery in place, so there is no way around.</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><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">IMO the main usage of b) would be with object files which would work.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Maybe it’s enough to notify the user by producing textual files that fail the “normal” tools?</span></p></div></div></blockquote><div><br></div><div>I think so. For me the most important thing about the text formats is to have something that is easy to read and edit so one can hack something here and there, and I think the bundler assures that. I assume to interface with other toolchains, the objects files and libraries would more commonly used. </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><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">Greetings<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"><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:35 PM<br><b>To:</b> Hahnfeld, Jonas<br><b>Cc:</b> Samuel F Antao; Alexey Bataev; Hal Finkel; John McCall; Eric Christopher; Artem Belevich; <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br><b>Subject:</b> Re: [cfe-dev] [RFC][OpenMP][CUDA] Generic Offload File Bundler Tool<u></u><u></u></span></p></div></div><div><div class="h5"><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">Thanks for the feedback.<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">2016-02-25 2:46 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 this detailed explanation on how you plan to do this.</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I really much like the idea of bundling and only giving back one single file to the user. This should make it easier to use offloading techniques.</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">I have one question but don’t know all formats in depth:</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Given that the separation is done by respective comments in that format, a tool would concatenate all bundles if it doesn’t know about the bundling, right?</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">(Imagine a scenario where one object file is compiled with offloading enabled and is afterwards linked into a “plain” executable…)</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Are there any “tricks” that could be employed to make the “old” / “normal” tools fall back to the host bundle or a “default” triple?</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">For example starting a comment section after the first bundle which the clang-offoad-bundler knows about, ignores and correctly extracts the other bundles, but that hides them for other tools?</span><u></u><u></u></p></div></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Good point. So, lets say we want to link two objects (doesn't matter the phases each file requires), one is a bundle and the other is not. I can see two possible scenarios.<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><p class="MsoNormal">a) You link them through clang with the target-offload information:<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">In that case we could create empty files for the devices in the bundler tool, if it detects the input is not a bundler. A cons would be that the host bundle has always to be provided first, which is not something hard to enforce in the driver.<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><p class="MsoNormal">b) You provide the two files directly to ld, or some other compiler, or you do not pass offloding options that are consistent with the bundle:<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">For binary formats (at least the ones I am used to work with: ELF, BC), making sure the host code always shows up first in the bundler and the bundler header appears in the bottom of the file instead of the top (is not an header anymore) would just work.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">For text formats a way to do it is guard all the device code with comments. It would make things harder if you want to edit it though.<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><p class="MsoNormal">a) and b) could be easily accommodated in the current design. Thoughts?<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Thanks again,<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><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,</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Jonas</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 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 1:15 AM<br><b>To:</b> Alexey Bataev; Hal Finkel; John McCall; Eric Christopher; Artem Belevich; Hahnfeld, Jonas; <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br><b>Subject:</b> [RFC][OpenMP][CUDA] Generic Offload File Bundler Tool</span><u></u><u></u></p></div></div><div><div><p class="MsoNormal"> <u></u><u></u></p><div><p><span style="font-size:9.5pt">Hi all,</span><u></u><u></u></p><p><span style="font-size:9.5pt"> </span><u></u><u></u></p><p><span style="font-size:9.5pt">Programming models that support offloading require different toolchains involved in the compilation process. Usually, one toolchain for host and as many toolchains as different devices one wants to offload to is required. If separate compilation is used this means that for a single source file one may get multiple output files.</span><u></u><u></u></p><p><span style="font-size:9.5pt">Also, one of the goals of programming models that support offloading (e.g. OpenMP, CUDA) is to enable users to offload with little effort, by annotating the code with a few pragmas or attributes. It is also desirable that we can save users the trouble of changing their existent applications' build system to deal all the different files for the different toolchains. So having the compiler always return a single file instead of one for the host and each target even if the user is doing separate compilation would be in my view a very welcomed feature.</span><u></u><u></u></p><p><span style="font-size:9.5pt">I am proposing a tool that I am naming clang-offload-bundler (happy to change the name if required) that is used to bundle files associated with the same user source file but different targets, or to unbundle a file into separate files associated with different targets. A tentative implementation of what is proposed in this RFC is posted in <a href="http://reviews.llvm.org/D13909" target="_blank">http://reviews.llvm.org/D13909</a>.</span><u></u><u></u></p><p><span style="font-size:9.5pt">This RFC complements the RFC related with offloading driver changes in [RFC][OpenMP][CUDA] Unified Offloading Support in Clang Driver.</span><u></u><u></u></p><p><span style="font-size:9.5pt">Let me know your thoughts. Any feedback is very welcomed!</span><u></u><u></u></p><p><span style="font-size:9.5pt">Thanks!</span><u></u><u></u></p><p><span style="font-size:9.5pt">Samuel</span><u></u><u></u></p><p><span style="font-size:9.5pt">================</span><u></u><u></u></p><p><span style="font-size:9.5pt">Proposal Description</span><u></u><u></u></p><p><span style="font-size:9.5pt">================</span><u></u><u></u></p><p><span style="font-size:9.5pt">a) Bundler/Unbundler behavior:</span><u></u><u></u></p><p><span style="font-size:9.5pt">This tool could be invoked with the commands:</span><u></u><u></u></p><p><span style="font-size:9.5pt">clang-offload-bundler -targets=device1ID,device2ID -type=ii -inputs=a.device1.ii,a.device2.ii -outputs=a.ii</span><u></u><u></u></p><p><span style="font-size:9.5pt">or</span><u></u><u></u></p><p><span style="font-size:9.5pt">clang-offload-bundler -targets=device1ID,device2ID -type=ii -outputs=a.device1.ii,a.device2.ii -inputs=a.ii -unbundle</span><u></u><u></u></p><p><span style="font-size:9.5pt">In “bundling mode” the tool takes as input multiple files and produce a single one whereas in “unbundling mode” (activated with the -unbundle flag) the opposite is true. In the bundled files, the content of the input files are stored "as is” and associated with an ID that is provided with the -targets option. The ID can be anything that uniquely identifes a bundle, e.g a combination of the device triple and programming model name.</span><u></u><u></u></p><p><span style="font-size:9.5pt">The order of the IDs in the -targets options should be consistent with the order of the input (bundling) or output file (unbundling). </span><u></u><u></u></p><p><span style="font-size:9.5pt">In unbundling mode, the input file is always expected to have the format of a bundler. The device IDs are used to retrieve the right content from the bundler and produce the output files in the order the user requested.</span><u></u><u></u></p><p><span style="font-size:9.5pt"> </span><u></u><u></u></p><p><span style="font-size:9.5pt">b) Bundled file format.</span><u></u><u></u></p><p><span style="font-size:9.5pt">The bundled file should be agnostic of the format of the input file so that it can easily cover all the formats produced in clang. It should however distinguish text formats from binary formats. That distinction is made through the -type option whose possible values are the same as in Types.def.</span><u></u><u></u></p><p><span style="font-size:9.5pt">For text formats the -type option also allows the tool to understand how a comment is implemented in that format so that the deviceID associated with a bundle is encoded as comment. These comments would work as separators between bundles so the user can conveniently read/edit the bundler if he feels like it without bothering about bundler format.</span><u></u><u></u></p><p><span style="font-size:9.5pt">For binary files, the bundler would have an header that specify the offsets of the different bundlers.</span><u></u><u></u></p><p><span style="font-size:9.5pt">I propose the following for the bundler format (this is the format I employed in <a href="http://reviews.llvm.org/D13909" target="_blank">http://reviews.llvm.org/D13909</a>):</span><u></u><u></u></p><p><span style="font-size:9.5pt">b-i) Format for binary bundlers:</span><u></u><u></u></p><p><span style="font-size:9.5pt">// "OFFLOAD_BUNDLER_MAGIC_STR" (ASCII encoding of the string)</span><u></u><u></u></p><p><span style="font-size:9.5pt">//</span><u></u><u></u></p><p><span style="font-size:9.5pt">// NumberOfOffloadBundles (8-byte integer)</span><u></u><u></u></p><p><span style="font-size:9.5pt">//</span><u></u><u></u></p><p><span style="font-size:9.5pt">// OffsetOfBundle1 (8-byte integer)</span><u></u><u></u></p><p><span style="font-size:9.5pt">// SizeOfBundle1 (8-byte integer)</span><u></u><u></u></p><p><span style="font-size:9.5pt">// NumberOfBytesInTripleOfBundle1 (8-byte integer)</span><u></u><u></u></p><p><span style="font-size:9.5pt">// TripleOfBundle1 (byte length defined before)</span><u></u><u></u></p><p><span style="font-size:9.5pt">//</span><u></u><u></u></p><p><span style="font-size:9.5pt">// ...</span><u></u><u></u></p><p><span style="font-size:9.5pt">//</span><u></u><u></u></p><p><span style="font-size:9.5pt">// OffsetOfBundleN (8-byte integer)</span><u></u><u></u></p><p><span style="font-size:9.5pt">// SizeOfBundleN (8-byte integer)</span><u></u><u></u></p><p><span style="font-size:9.5pt">// NumberOfBytesInTripleOfBundleN (8-byte integer)</span><u></u><u></u></p><p><span style="font-size:9.5pt">// TripleOfBundleN (byte length defined before)</span><u></u><u></u></p><p><span style="font-size:9.5pt">//</span><u></u><u></u></p><p><span style="font-size:9.5pt">// Bundle1</span><u></u><u></u></p><p><span style="font-size:9.5pt">// ...</span><u></u><u></u></p><p><span style="font-size:9.5pt">// BundleN</span><u></u><u></u></p><p><span style="font-size:9.5pt"> </span><u></u><u></u></p><p><span style="font-size:9.5pt">b-ii) Format for text bundlers:</span><u></u><u></u></p><p><span style="font-size:9.5pt">// "Comment OFFLOAD_BUNDLER_MAGIC_STR__START__ triple"</span><u></u><u></u></p><p><span style="font-size:9.5pt">// Bundle 1</span><u></u><u></u></p><p><span style="font-size:9.5pt">// "Comment OFFLOAD_BUNDLER_MAGIC_STR__END__ triple"</span><u></u><u></u></p><p><span style="font-size:9.5pt">// ...</span><u></u><u></u></p><p><span style="font-size:9.5pt">// "Comment OFFLOAD_BUNDLER_MAGIC_STR__START__ triple"</span><u></u><u></u></p><p><span style="font-size:9.5pt">// Bundle N</span><u></u><u></u></p><p><span style="font-size:9.5pt">// "Comment OFFLOAD_BUNDLER_MAGIC_STR__END__ triple”</span><u></u><u></u></p><p><span style="font-size:9.5pt"> </span><u></u><u></u></p><p><span style="font-size:9.5pt">============</span><u></u><u></u></p><p><span style="font-size:9.5pt">Call For Action</span><u></u><u></u></p><p><span style="font-size:9.5pt">============</span><u></u><u></u></p><p><span style="font-size:9.5pt">Please review this proposal if you are concerned with support of offloading models, or any other use case that may require multiple file generation by the driver, and provide your feedback. Our goal is to reach an agreement in the community and proceed with implementation.</span><u></u><u></u></p><p><span style="font-size:9.5pt"> </span><u></u><u></u></p><p><span style="font-size:9.5pt">================= </span><u></u><u></u></p><p><span style="font-size:9.5pt">Implementation Plan</span><u></u><u></u></p><p><span style="font-size:9.5pt">=================</span><u></u><u></u></p><p><span style="font-size:9.5pt">1. Upon reaching the agreement on the proposal, we (IBM compiler team) will start to submit patches implementing the bundler tool including the required changes for the build system. Code review would be much appreciated!</span><u></u><u></u></p><p><span style="font-size:9.5pt">2. The implementation will be articulated with the ongoing developments in the clang driver given that would be (at least initially) the major client of this tool, and where several tests could be implemented.</span><u></u><u></u></p></div></div></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></div><p class="MsoNormal"><u></u> <u></u></p></div></div></div></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>