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

[Alp Toker]

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