[cfe-dev] Clang 3.5 Release Pre-Pre-Pre-Announcement

[Reid Kleckner]

On Tue, May 20, 2014 at 5:10 PM, Alp Toker <alp at nuanti.com> wrote:

>
> On 21/05/2014 02:31, Reid Kleckner wrote:
>
>  On Tue, May 20, 2014 at 3:54 PM, Alp Toker <alp at nuanti.com <mailto:
>> alp at nuanti.com>> wrote:
>>
>> It's an interesting idea, but I'm pretty opposed to this approach.
>>
>> 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.
>>
>
> There's not much exported data compared to all the symbol exports, so
> there wouldn't be much cost in annotating these if needed.
>
> 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.


We export data between individual LLVM libraries, so it works as long as
the desired library granularity lumps together most of LLVM.

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.
>>
>
> LTO also requires a full build so by that same argument, LTO would be a
> non-starter?
>
> This is a technique for producing optimal release shared library / DLL
> builds, not for day-to-day development in your debug build.
>
> 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.
>
> (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.)


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.  :)

 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.
>>
>
> Logical to whom? That's only one of several supported build configurations.
>
> 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?


Yes, there is a burden to annotations.  It's a tradeoff to consider.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140520/622ec0ef/attachment.html>