[PATCH] D17347: Use LLVM_LIBRARY_VISIBILITY to prevent LLVM dynamic libraries from export symbols for SROA internals.

Owen Anderson via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 24 09:43:21 PST 2016

> On Feb 24, 2016, at 6:15 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> On 23 February 2016 at 19:54, Owen Anderson via llvm-commits
> <llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>> wrote:
>> On Feb 23, 2016, at 4:31 PM, Owen Anderson via llvm-commits
>> <llvm-commits at lists.llvm.org> wrote:
>> On Feb 23, 2016, at 3:19 PM, Justin Bogner <mail at justinbogner.com> wrote:
>> This, on the other hand, seems like a fair bit of boilerplate for not
>> much gain. These are private methods and are used by run(), so hiding
>> them won't really help us dead strip more or anything like that, and I
>> don't really see why passes should be special compared to other LLVM
>> classes in this regard.
>> The way I see it, if it's worth hiding the private members here, why
>> wouldn't we do something to generally hide private members in most or
>> all of LLVM?
>> I would very much like to hide them everywhere in LLVM.
>> For context, a libLLVM.dylib built against TOT, with externalized and
>> internal symbols stripped, is 34MB.   That binary exports 18629 symbols, and
>> the symbol table consumes more than 1MB of space in the binary.  In addition
>> to reclaiming that binary space, I am also very interested in reducing the
>> launch time of applications linking against that dylib, which grows with the
>> number of exported symbols.
> Long term I think the only way to fix this and keep it fixed is to
> start building with -fvisibility-hidden and annotating what we want to
> export instead of the other way around.

I suspect you’re right from a technical perspective, but from an interpersonal perspective, agreeing on what we want to export is probably harder than agreeing on things that we definitely don’t want to export.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160224/79d6b5bc/attachment.html>

More information about the llvm-commits mailing list