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

Rafael EspĂ­ndola via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 24 06:15:26 PST 2016

On 23 February 2016 at 19:54, Owen Anderson via llvm-commits
<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.


More information about the llvm-commits mailing list