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

[Rafael Avila de Espindola]

A pre tool does sound somewhat tempting. An issue with it that I just realized is that to link foo.dll we have to find all symbols from foo's objects that are used from another library. That is, we would have to pretty much build every .o before we could link any .dll :-(

We had in the past a tool to compute the dependencies that llvm-confg prints but moved to writing them explicitly because it was a horrible build serialization point.

Do you have an example for why the "worst case macro" would not work on windows?

Thanks,
Rafael

Sent from my iPhone

> On May 20, 2014, at 18:54, Alp Toker <alp at nuanti.com> wrote:
> 
> 
> On 19/05/2014 04:41, Rafael Espíndola wrote:
>>> I don't think maintaining import/export annotations in the source code is
>>> viable in LLVM.
>>> 
>>> We'd be looking at hundreds of macros like EXPORT_IF_HAVE_CLANG and
>>> IMPORT_IF_MODULAR_BUILD, EXPORT_IF_NOT_MONOLITHIC_LLVMCLANG attached to
>>> functions and classes throughout LLVM. Yuck :-(
>> Well, we can always start with the most conservative case, no? Just a
>> LLVM_EXPORT that gets added if the symbol is needed in *any*
>> configuration. That would be better than what we have now for ELF and
>> would make it possible to get dll builds on windows.
> 
> That would only provide (fairly unsatisfactory) results with ELF visibility, but with import/exports it's not going to work out at all except maybe for one of the supported build configurations.
> 
> That's not a great cost/benefit ratio for lots of annotations in the source.
> 
>> 
>>> Excessive exports would prevent optimisations and inlining without any clear
>>> way to prune them as the code changes. LTO would have to export all these
>>> functions just in case something might be using them.
>> That is the current situation on ELF/MachO :-(
>> 
>>> The only way to detect when new exports are needed would be to observe build
>>> bot breakage and add them incrementally until the bots turn green. Or to
>>> keep a shared build matching the DLL configuration.
>>> 
>>> It's really burdensome to have to modify the original *definition* every
>>> time you want to use a class or function. You'll no longer be able to
>>> develop and test a local clang branch against upstream LLVM, which will
>>> discourage people from developing against ToT.
>>> 
>>> And finally, the risk of breaking the build will be high enough to tip the
>>> balance in favour of copy-and-pasting the necessary code from LLVM core into
>>> clang in order to use it. It's not like we don't already have a
>>> copy-and-paste problem and this would legitimise the practice.
>>> 
>>> TLDR; We _really_ want to calculate these dependencies at build time with
>>> LLVMBuild instead of annotating the source.
>> Is there a convenient way to feed this to link.exe?
> 
> We can pass in exports through a /def file, similar to exports with other linkers.
> 
> To calculate the exports, someone will have to write a script/tool that collects undefined symbols, then goes through visible symbols in other modules to derive the export lists.
> 
> That'll generate minimal export lists, tuned for each platform and configuration, permitting optimal dead stripping and optimisation. And it'll save us from the burden of annotating loads and loads of definitions in the source that only work for a few setups.
> 
> Alp.
> 
>> 
>> Cheers,
>> Rafael
> 
> -- 
> http://www.nuanti.com
> the browser experts
>