<div dir="ltr">Hi all,<div><br></div><div>I decided a take shot on a possible implementation for the part of this proposal that I think is more consensual (i.e. the part that does not relate with the bundling). I posted three patches (<a href="http://reviews.llvm.org/D18170">http://reviews.llvm.org/D18170</a>, <a href="http://reviews.llvm.org/D18171">http://reviews.llvm.org/D18171</a>, <a href="http://reviews.llvm.org/D18172">http://reviews.llvm.org/D18172</a>) with a possible implementation, so that we have something more concrete to discuss. Let me know your thoughts.  </div><div><br></div><div>Going back to the bundling discussion:</div><div><br></div><div>I agree with Justin when he says that supporting all possible combinations of host-device bundling, each with a custom format adds a lot of complexity and does not necessarily helps the user. Therefore, I think reasonable to have intermediate files bundled in some already existent format (say tar) that is agnostic of the programming model. Actually, that was my motivation when I proposed the custom format in the bundler.</div><div><br></div><div>When I look at all the different concerns I think that a possible solution is to have a bundler with three operation modes:</div><div> i) "Embed": it generates a host object that contains the device image and properly defines the symbols a programming model requires. Therefore it can be linked with host objects successfully. This file is never exposed to the user unless save-temps is used.</div><div>ii) "Bundle": Combines host and device object using, by default, a format easy to interact with that is agnostic of the programming model.</div><div>iii) "Unbundle": The inverse of ii), it assumes the input uses that default format.</div><div><br></div><div>Using a header compatible with tar is not something hard to do, having the bundler tool as part of clang ensures that it works across operating systems too. At the same time, this leaves room to have custom-format bundling activated with options for the cases (would have to be evaluated one by one) that would greatly benefit of interoperability. </div><div><br></div><div>Does this sound reasonable?</div><div><br></div><div>Thanks!</div><div>Samuel</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-03-10 13:59 GMT-05:00 Justin Lebar 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"><span class="">> Justin, is this convincing enough?<br>
<br>
</span>Okay, okay.  Uncle.<br>
<br>
There are two things here that I find convincing.<br>
<br>
1) Although we're not going to be compatible with the details of some,<br>
if not all, other compilers' formats, we can at least be compatible<br>
with the spirit by using object files as opposed to tar.<br>
<br>
2) The postscript in Andrey's e-mail:<br>
<span class=""><br>
> Re: objdump doesn't understand ELF format with code for multiple targets. The same is true for fat executable files as well, isn't? So if we need to teach objdump how to recognize fat files, we already have this problem.<br>
<br>
</span>It's probably much more important that objdump work on executables<br>
than on object files, since if you have object files, you can probably<br>
recompile with -save-temps, but if you only have an executable, you<br>
don't necessarily have access to intermediate files, or even a<br>
compiler for the relevant architecture, much less the specific<br>
compiler which generated the executable.<br>
<br>
Shoving device code into the host *executable* seems unavoidable.  I'm<br>
still not thrilled with doing the same for object files -- it still<br>
feels like we're using ELF when we actually want an archive format --<br>
but (1) makes it less bad.<br>
<br>
-Justin<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Mar 9, 2016 at 5:59 AM, Andrey Bokhanko<br>
<<a href="mailto:andreybokhanko@gmail.com">andreybokhanko@gmail.com</a>> wrote:<br>
> All,<br>
><br>
> I asked Intel GCC guys who implemented OpenMP offloading support in GCC, and<br>
> as they told me, GCC also employs option #4 from Hal's list -- it puts both<br>
> host and target code in a single ELF file. "Code" in GCC case is always<br>
> GCC's IR (Gimple), though -- they require GCC invocation from linker in<br>
> order to produce a multi-target executable. This makes GCC non-interoperable<br>
> with any other offloading compiler and effectively produces its own<br>
> standard.<br>
><br>
> Thus, prior art from:<br>
> * nvcc<br>
> * Pathscale<br>
> * GCC<br>
> * ICC<br>
><br>
> indicates only one direction -- compiler driver produces a single object<br>
> file with target code embedded in data section.<br>
><br>
> Justin, is this convincing enough? I don't see any good reasons why clang<br>
> should go against what every other compiler on the planet does.<br>
><br>
> Re: objdump doesn't understand ELF format with code for multiple targets.<br>
> The same is true for fat executable files as well, isn't? So if we need to<br>
> teach objdump how to recognize fat files, we already have this problem.<br>
><br>
> Yours,<br>
> Andrey<br>
> =====<br>
> Software Engineer<br>
> Intel Compiler Team<br>
><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">_______________________________________________<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>
</div></div></blockquote></div><br></div>