<div dir="ltr">FWIW I always thought it was a little silly that Clang produces .o files for LTO that aren't the native object file format.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jul 6, 2014 at 6:57 PM, Peter Collingbourne <span dir="ltr"><<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Over in [1] we've been discussing adding support in LTO for an object<br>
file-based on-disk module format. Rafael suggested that I send a proposal<br>
to this list; this is that proposal.<br>
<br>
As motivation, consider a compiler that needs to store metadata in the<br>
LTO object file that may need to be read by future compilation steps,<br>
such as the "export data" used by some Go compilers [2]. Such metadata<br>
might also need to be read by external tools which do not know about LLVM,<br>
so a good choice of file format would be something relatively stable and<br>
well understood, readable without depending on LLVM and compatible with the<br>
non-LTO scenario. This lends itself to the platform's native object file<br>
format being a good candidate for the outermost file format, such that the<br>
metadata and IR are stored in separate sections.<br>
<br>
The basic proposal is that as an alternative on-disk representation for IR, we<br>
also support native object files (i.e. ELF/COFF/Mach-O) with a section named<br>
'.llvmbc' containing the bitcode in the same format that we are using now,<br>
and no other (allocatable) sections. The actual support needed in LLVM would<br>
be limited to consumers, i.e. LTO infrastructure: linker plugins, llvm-ar,<br>
llvm-nm etc. We would not necessarily need to teach other bitcode consumers<br>
(e.g. llvm-dis) about this format or add any producers to the tree, but<br>
it may be useful as a matter of convenience to do so.<br>
<br>
We can also consider extending this format by generating code into the<br>
object file, such as for functions which we believe at compile time to<br>
be cold, or for all functions if we want the decisions to be made at link<br>
time. This may be beneficial for C/C++ compilation as it may allow us to<br>
parallelize/deduplicate the code generation work for at least some functions.<br>
<br>
Thanks,<br>
<span class="HOEnZb"><font color="#888888">--<br>
Peter<br>
<br>
[1] <a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140630/224359.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140630/224359.html</a><br>
[2] <a href="http://golang.org/doc/install/gccgo#Imports" target="_blank">http://golang.org/doc/install/gccgo#Imports</a><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</font></span></blockquote></div><br></div>