[llvm-dev] Why are LLVM releases statically linked against LLVM libraries?

David Chisnall via llvm-dev llvm-dev at lists.llvm.org
Sun Sep 3 03:06:34 PDT 2017

On 3 Sep 2017, at 02:41, Will Dietz via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> I can speculate the reasons from a technical standpoint and by
> inferring from commit history...
> but curious if there's a better answer to be had?

There’s a fairly noticeably performance improvement from static linking.  I think last time I benchmarked it, building FreeBSD with dynamically linked clang took around 20% longer than building with statically linked clang.  It’s less clear how this differs when you have multiple parts of the toolchain sharing LLVM libraries (clang, lld, perhaps other compilers).  There was some discussion (I don’t remember the conclusions) of switching the tools in the FreeBSD base system to use a dynamic libLLVM.so, because there’s a pretty noticeable difference in binary size between static and dynamic clang + lldb + lld, and it’s even greater if you start shipping libClang or libTooling-based tools.

Some back-of-the-envelope approximations indicate that you probably won’t win back the performance from sharing, because both clang and lld have working sets that are far greater than last-level caches on most systems and so the only wins would be from sharing page-table entries (which only XNU does reliably) and from sharing i-cache (which in C++ is unlikely, because the LLVM libraries are pretty big and we’re unlikely to be in the same bits of the code for long enough for it to matter.


More information about the llvm-dev mailing list