<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 20, 2014 at 5:10 PM, Alp Toker <span dir="ltr"><<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On 21/05/2014 02:31, Reid Kleckner wrote:<div class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, May 20, 2014 at 3:54 PM, Alp Toker <<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a> <mailto:<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>>> wrote:<br><br>
It's an interesting idea, but I'm pretty opposed to this approach.<br>
<br>
First, this approach doesn't work for exported data.  You need annotations to import data, and I can say from experience that we do this in LLVM.<br>
</blockquote>
<br></div>
There's not much exported data compared to all the symbol exports, so there wouldn't be much cost in annotating these if needed.<br>
<br>
But it's generally not a good idea to export data like that in defined interface anyway. I'd be surprised if there's much of that going on between LLVM / clang that can't be detected from symbols or tidied up.</blockquote>
<div><br></div><div>We export data between individual LLVM libraries, so it works as long as the desired library granularity lumps together most of LLVM.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Third, suppose we want to build LLVMSupport.dll.  Now we need to build LLVMSupport.lib, then everything that uses LLVMSupport.dll, and then scrape imports from all those static archives or object files.  This is a *huge* web of dependencies.  Now building llvm-as.exe which dynamically links LLVMSupport.dll depends on building clangSema.lib.  That's a non-starter.<br>

</blockquote>
<br></div>
LTO also requires a full build so by that same argument, LTO would be a non-starter?<br>
<br>
This is a technique for producing optimal release shared library / DLL builds, not for day-to-day development in your debug build.<br>
<br>
To take the LTO analogy further, using annotations for linker hints is kind of like trying to annotate your entire source tree with __const__ and __pure__ attributes for readonly/readnone.<br>
<br>
(Except it's more painful because the set of exports and imports changes all the time based on build configuration, platform and which modules happen to be using which functions changing day to day.)</blockquote><div>
<br></div><div>I've never considered doing LTO on a binary that isn't mostly static.  I suppose there are reasons to want to do LTO on a minimal set of DSOs, but it's not what I'm interested in.  One of the benefits of doing this is precisely a faster developer build.  :)</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If we want to support DSOs exporting a C++ interface, IMO we should define the DSO boundary up front and use annotations.  I think the logical DSO boundaries would be LLVMSupport, LLVM, and Clang.<br>
</blockquote>
<br></div>
Logical to whom? That's only one of several supported build configurations.<br>
<br>
For our use case, for example, we'd also need libclang.so so we'd introduce a *different* set of export macros than yours into the source code. Ditto if someone wants another configuration. And who's going to maintain all these annotations, individual committers?</blockquote>
<div><br></div><div>Yes, there is a burden to annotations.  It's a tradeoff to consider.</div></div></div></div>