Add API/ABI export annotations to the LLVM build

Description of the project: Currently, all libraries inside LLVM export all their symbols publicly. When linking statically against them, the linker will remove unused symbols and this is not a problem.

When the libraries are built as shared libraries however, the number of exported symbols is very large and symbols that are meant to be internal spill into the public ABI of the shared

In this project, we’d like to change the default visibility of library symbols to “hidden”, add an annotation macro to LLVM and use the macro to gradually move the entire library in this direction. This will eventually enable building the shared on Windows as well.

In practice, this means adding -fvisibility=hidden to individual libraries and annotating exported symbols with the LLVM export annotation.

We would like this work to be as unintrusive into other developer’s workflow as possible, so starting with a small internal library would be beneficial, e.g. one of the LLVM targets or IR passes.

For further reading, there is a Discourse thread avaiable that discusses the idea behind this proposal: Supporting LLVM_BUILD_LLVM_DYLIB on Windows
as well as the linked Phabricator review with a patch implementing the functionality: ⚙ D109192 [WIP/DNM] Support: introduce public API annotation support
None of this work has been committed yet but can be used as a starting
point for this proposal.

Desirable results: At least one internal library fully switched to the new approach and the necessary CMake work to change the other libraries (and finally the as well.

Desirable skills: Build systems, CMake, LLVM

Mentors: Timm Bäder (@tbaeder), Tom Stellard (@tstellar)

Project type: Medium

The intent is for this change to apply to all libraries in the llvm-project, both LLVM/Clang related and target/runtime libraries? IIRC libc++ already has non-public symbols w/hidden? (probably libc++abi too, then?).

@androm3da This change is only for libraries like,, etc. The runtime libraries like libc++ wouldn’t be part of this proposal.