Support: introduce public API annotation support

[tstellar]

Summary

This provides a model for annotating the "public" interfaces of a module
in LLVM. This is motivated by the desire to have the ability to build
LLVM libraries in the shared mode to enable extraction of the shared
content between the tools.

Unlike Unix platforms, Windows has a more stringent requirement of
annotating the "dll-interface" when building a shared library. All of
the public APIs should be marked by the appropriate *_API macro. The
annotation indicates what APIs are public but are expected to live in
the dynamic library (DLL/dylib/so) that the macro is associated with.

The longer term desire here is to evolve this to support creating a
small set of libraries. Because there is a cost associated with the
call across the image boundary (GOT+PLT/IAT), the intent is to minimise
the number of libraries. The separation of the libraries should prefer
to split along the following disjoint sets:

• minimal set of interfaces required for llvm-ar (archiver/librarian)
• minimal set of interfaces required for lld (linker)
• minimal set of interfaces required for clang (compiler)

The reasoning behind this split set is that these tools are executed the
most, and minimising the penalty for these three sets is crucial for
keeping the penalty to dynamic linking (and LTO) low. Keeping the
number of libraries low reduces the complexity in distribution and
should also help reduce the overall size of the toolchain distribution.

[compnerd]

This is a preliminary patch which is incomplete. I wanted to put this up earlier rather than later because I suspect that this is going to require a few iterations while we figure out the exact details of the style that we want to use (e.g. *_API vs *_ABI vs *_EXPORT), location of the annotation, and the style of the annotation (e.g. LLVMSupport_API inline vs prefix vs LLVMSupport_API(return type)). Additionally, the API surface to audit is fairly large, so snapshotting is helpful.

[tschuett]

It is completely up to you, but for me Support is kind of redundant or the wrong kind of information. I would expect something like LLVM_PUBLIC_API.

[compnerd]

In D109192#2980913, @tschuett wrote:

It is completely up to you, but for me Support is kind of redundant or the wrong kind of information. I would expect something like LLVM_PUBLIC_API.

LLVM_PUBLIC_API is not feasible IMO as there will be a macro per dynamic library that we end up with and each must have a separate spelling [1]. I suppose I can do a bit of macro expansion magic to do something like:

LLVM_PUBLIC_API(LLVMSupport)
LLVM_PUBLIC_API(LLVM)
LLVM_PUBLIC_API(LLVMObject)

where the optional parameter is the name of the dynamic object that serves as the home (assuming that we end up with LLVMSupport.dll, libLLVM.dylib and libLLVMObject.so in the fictional world).

[1] The separate spelling is required for cases where multiple libraries are in an address space. Consider the following:

Library A: A_API
Library B: B_API
The executable see:

int A_API f(void);
int B_API g(void);
int main() {
  return f() + g();
}

What happens if B also depends on A and we use the same macro? It will see int LLVM_PUBLIC_API f(void); but it is defining the "public API" so it will incorrectly mark f as being local.

[fodinabor]

Thanks for working on this!
In general looks good to me, I'd opt for all CAPS macros, though, so e.g. LLVM_SUPPORT_API. The return variant LLVM_SUPPORT_API(retTy) is only beneficial when needing something like extern "C" retTy __stdcall iirc and is less ideal for marking classes as exported.
A parameterized version LLVM_API(LLVMSupport) would be fine for me as well, although I don't see any benefit.

[compnerd]

In D109192#2981682, @fodinabor wrote:

Thanks for working on this!
In general looks good to me, I'd opt for all CAPS macros, though, so e.g. LLVM_SUPPORT_API. The return variant LLVM_SUPPORT_API(retTy) is only beneficial when needing something like extern "C" retTy __stdcall iirc and is less ideal for marking classes as exported.

Sure, I can switch it to LLVM_SUPPORT_API just as well. That is the easy part of the change. The difficult part is the auditing of the interfaces.

Correct, the return variant is useful for the extra decoration. While not particularly useful for the classes, it does allow writing the decorations more naturally when expanded:

class __declspec(dllexport) exported { }; on Windows
__attribute__((__visibility__("default"))) class exported { }; on other platforms

The places where it is however useful is is on variable and function declarations. Exported functions really should be decorated with extern "C", but that is something that I don't think we should conflate with the work here. The goal here is to minimally attribute enough of LLVM with dll interface/visibility and switch to hidden visibility on non-Windows platforms while enabling a build where the core of LLVM can be a shared library.

A parameterized version LLVM_API(LLVMSupport) would be fine for me as well, although I don't see any benefit.

I agree, it isn't particularly useful (and it is more complicated). That was a suggestion to @tschuett's comment that we aim for a single macro rather than a library specific macro.

[compnerd]

One question that remains is the spelling of the macro. Do we want to go with API or ABI? I think that there is an argument to be made that ABI is more precise - this marks how you call into the library not just how you use it. When a function is moved beyond the module boundary, while the API will not change, the ABI of the module would. This of course pedantic, but these items are important to nail down correctly early as these are fairly large scale invasive changes.

[hans]

In D109192#2982429, @compnerd wrote:

One question that remains is the spelling of the macro. Do we want to go with API or ABI? I think that there is an argument to be made that ABI is more precise - this marks how you call into the library not just how you use it. When a function is moved beyond the module boundary, while the API will not change, the ABI of the module would. This of course pedantic, but these items are important to nail down correctly early as these are fairly large scale invasive changes.

I've seen *API macros used for this in other libraries, but I don't think I've ever seen the *ABI variant.

[tschuett]

Again up to you, but my understanding of LLVM is to get something working and then iterate on it. Most of your work went into SupportMacros.h. The decision for API vs. ABI has less entropy.

[compnerd]

• use LLVM_SUPPORT_ABI as per feedback
• remove changes to the implementation to make it easier to iterate
• change tactics to target llvm-tblgen first

This gets close to being able to build llvm-tblgen (8 unresolved externals).

[compnerd]

Some additional questions:

• should we be encouraging of exporting entire classes or should we be more judicious in the visibility (e.g. attribute members)? I'm not 100% certain that this works for non-dll-interface targets.

I'm more convinced now that we should introduce an option to introduce this behaviour. The new option can opt into building the shared library components. Perhaps something like LLVM_EXPERIMENTAL_SHARED_LIBRARY_COMPONENTS is a good option name?

[rnk]

In D109192#2982723, @compnerd wrote:

Some additional questions:

• should we be encouraging of exporting entire classes or should we be more judicious in the visibility (e.g. attribute members)? I'm not 100% certain that this works for non-dll-interface targets.

I think you can give entire classes default visibility, and that will apply to all members. I think we should annotate classes because it will reduce the total number of annotations, and that will reduce the churn. For large, key classes that have too many private methods (Sema, ASTContext?) we can go back later and export only the public APIs, or something like that.

I'm more convinced now that we should introduce an option to introduce this behaviour. The new option can opt into building the shared library components. Perhaps something like LLVM_EXPERIMENTAL_SHARED_LIBRARY_COMPONENTS is a good option name?

I agree this new thing shouldn't become the default build config. How close is this to BUILD_SHARED_LIBS vs LLVM_ENABLE_DYLIB? Can we repurpose one of those?

---

Going in a completely different direction, why even start by splitting out Support as its own shared library? We already have the single-DSO build config, why not improve that by adding annotations and using -fvisibility=hidden?

llvm/lib/Support/AArch64TargetParser.cpp

27

Is this necessary? In general, you shouldn't have to annotate the definitions so long as the previous declaration was annotated. I don't see any compilers that warn about this:
https://gcc.godbolt.org/z/E7T1c9z81

llvm/lib/Support/CMakeLists.txt

104

As I understand it, this makes the support library always shared. I don't think that gives people using the traditional static build a pathway to transition. What I had in mind was making this conditional on LLVM_BUILD_DYLIB or whatever we're calling it, the one that builds libLLVM.so, the one all the Linux distros use.

I think our long term goal should be to align the default LLVM cmake build configuration with the one that distributors are using. The fact that most devs don't use the most commonly distributed LLVM build configuration leads to surprises like the ones from earlier this year:
https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic
https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi5_WeNTG1B-suOES=[e-mail]/

[compnerd]

In D109192#2982999, @rnk wrote:

In D109192#2982723, @compnerd wrote:

Some additional questions:

• should we be encouraging of exporting entire classes or should we be more judicious in the visibility (e.g. attribute members)? I'm not 100% certain that this works for non-dll-interface targets.

I think you can give entire classes default visibility, and that will apply to all members. I think we should annotate classes because it will reduce the total number of annotations, and that will reduce the churn. For large, key classes that have too many private methods (Sema, ASTContext?) we can go back later and export only the public APIs, or something like that.

This is sort of the direction that I had in mind. The problem is, there are cases where I cannot get the desired behaviour correct. Doing those where it doesn't just work seems like an easier path and one that could be refined later. Its a bit unfortunate, but seems like a decent trade off.

I'm more convinced now that we should introduce an option to introduce this behaviour. The new option can opt into building the shared library components. Perhaps something like LLVM_EXPERIMENTAL_SHARED_LIBRARY_COMPONENTS is a good option name?

I agree this new thing shouldn't become the default build config. How close is this to BUILD_SHARED_LIBS vs LLVM_ENABLE_DYLIB? Can we repurpose one of those?

I think that BUILD_SHARED_LIBS is desirable, and LLVM_ENABLE_DYLIB should go away. That said, I think that the ideal thing here is to have a different configuration that is less granular than BUILD_SHARED_LIBS. That would correspond to LLVMTools, LLVMCompiler and depending on the delta, a potential third library. These three would give us a nice hybrid approach to dynamic and static linking. It would be dynamic for buckets of use (bintuils, clang, and possibly lld if it makes LLVMTools too large) but statically linking large components of LLVM to enable us to take advantage of LTO and DCE amongst that set. It would try to minimise the cost of the GOT/PLT and IAT so that we don't introduce an extremely heavy penalty for these libraries.

---

Going in a completely different direction, why even start by splitting out Support as its own shared library? We already have the single-DSO build config, why not improve that by adding annotations and using -fvisibility=hidden?

I don't really care if we keep LLVMSupport as a separate library or not in the end. The point here is to work through a representative set to setup such a configuration. This gives us a good pattern to apply and tries to iron out the issues that this brings up in a smaller context. The -fvisbility=hidden (and -fvisibility-inlines-hidden) is a requirement for this so we do not continually regress. One of the hacks in this patch is the unconditional application of that to LLVMSupport (which I will remove as this patch gets closer to a final form). I don't think that the single DSO configuration is ideal either, we would still have an unnecessarily large overhead for tooling. I think that the ideal split would be a library sufficient for the binutils, a second library that has everything else that is needed for clang.

[aganea]

In D109192#2983041, @compnerd wrote:

In D109192#2982999, @rnk wrote:

In D109192#2982723, @compnerd wrote:

Some additional questions:

• should we be encouraging of exporting entire classes or should we be more judicious in the visibility (e.g. attribute members)? I'm not 100% certain that this works for non-dll-interface targets.

I think you can give entire classes default visibility, and that will apply to all members. I think we should annotate classes because it will reduce the total number of annotations, and that will reduce the churn. For large, key classes that have too many private methods (Sema, ASTContext?) we can go back later and export only the public APIs, or something like that.

This is sort of the direction that I had in mind. The problem is, there are cases where I cannot get the desired behaviour correct. Doing those where it doesn't just work seems like an easier path and one that could be refined later. Its a bit unfortunate, but seems like a decent trade off.

There's a 2^16 symbol limit per DLL on Windows, so exporting entire classes would potentially reach that limit much faster. From past experience, we started our DLL targets with class annotations, only to reach that limit, and fall back to function-only annotation later. It's a bit more tedious to mark functions independently, but also avoids the performance issues mentionned below. Exporting an entire class could introduce, by inadvertance, indirections at the caller site.
There's a also build time cost for exporting (too) many symbols, but maybe that less of a concern here (because it would only affect LLVM developers using this specific configuration).

Regarding the API boundaries, or how to wisely chose those boundaries: I am wondering if there's a way to make use of the whole program analysis, to find the performance-critical paths. Any function in that path shouldn't be exported, to avoid the DLL thunk indirection I was mentionning. Ideally we should only export "high level" functions and keep performance-critical code internal.

I am also wondering how does this fit with the llvm-busybox proposal? That goes in a completly different direction, by coalescing all of llvm/clang/lld in a single executable. We could simply go along those lines: a single DLL per "project" (clang, llvm, lld) with the existing bintools as executable wrappers on the top of that. Is that the single-DSO config that @rnk mentions? Doing that seems almost a no-brainer in terms of defining the API boundaries.

[mstorsjo]

In D109192#2983146, @aganea wrote:

There's a 2^16 symbol limit per DLL on Windows, so exporting entire classes would potentially reach that limit much faster.

FWIW, in mingw configurations, the existing dylib setup works (as mingw toolchains fall back to exporting all symbols if there's no dllexports). libLLVM is cutting it quite close though, it currently ends up at 58000 symbols, so not many to spare (and this with only X86, ARM and AArch64 targets enabled, I think it ends up too many if all targets are enabled, and if building with asserts enabled, there's a couple more too).

[compnerd]

In D109192#2983153, @mstorsjo wrote:

In D109192#2983146, @aganea wrote:

There's a 2^16 symbol limit per DLL on Windows, so exporting entire classes would potentially reach that limit much faster.

FWIW, in mingw configurations, the existing dylib setup works (as mingw toolchains fall back to exporting all symbols if there's no dllexports). libLLVM is cutting it quite close though, it currently ends up at 58000 symbols, so not many to spare (and this with only X86, ARM and AArch64 targets enabled, I think it ends up too many if all targets are enabled, and if building with asserts enabled, there's a couple more too).

That is both good and bad. Its good to know that we are able to get a build with everything exported, though I think that we will want to be able to include all the targets, and might be too close to that limit. However, I suspect that splitting up LLVM.dll into LLVM.dll and LLVMSupport.dll we might be able to scrape through.

[compnerd]

In D109192#2983146, @aganea wrote:

In D109192#2983041, @compnerd wrote:

In D109192#2982999, @rnk wrote:

In D109192#2982723, @compnerd wrote:

Some additional questions:

• should we be encouraging of exporting entire classes or should we be more judicious in the visibility (e.g. attribute members)? I'm not 100% certain that this works for non-dll-interface targets.

I think you can give entire classes default visibility, and that will apply to all members. I think we should annotate classes because it will reduce the total number of annotations, and that will reduce the churn. For large, key classes that have too many private methods (Sema, ASTContext?) we can go back later and export only the public APIs, or something like that.

This is sort of the direction that I had in mind. The problem is, there are cases where I cannot get the desired behaviour correct. Doing those where it doesn't just work seems like an easier path and one that could be refined later. Its a bit unfortunate, but seems like a decent trade off.

There's a 2^16 symbol limit per DLL on Windows, so exporting entire classes would potentially reach that limit much faster. From past experience, we started our DLL targets with class annotations, only to reach that limit, and fall back to function-only annotation later. It's a bit more tedious to mark functions independently, but also avoids the performance issues mentionned below. Exporting an entire class could introduce, by inadvertance, indirections at the caller site.

Yes, though, my reasoning for not wanting to annotate the non-inline functions only is less the churn and more the worry about the difference wrt vftable emission. Although, now that I think about it, IIRC, MS ABI will always universally emit the vftable and so this point is moot - we should fallback to the anchors for the vtable emission for itanium targets. Although, I think we might want to consider creating a macro for this now and eliding the anchor for MS ABI - that would save us a potentially large set of unnecessary exported symbols that do nothing on Windows.

There's a also build time cost for exporting (too) many symbols, but maybe that less of a concern here (because it would only affect LLVM developers using this specific configuration).

I think that there is another aspect beyond build time costs - it inhibits potential optimizations with LTO. Anything that can be fully internalized is a win in terms of potential LTO and DCE options.

Regarding the API boundaries, or how to wisely chose those boundaries: I am wondering if there's a way to make use of the whole program analysis, to find the performance-critical paths. Any function in that path shouldn't be exported, to avoid the DLL thunk indirection I was mentionning. Ideally we should only export "high level" functions and keep performance-critical code internal.

That would be nice to do as a follow up I think. I don't think that I could take that on, but would love to see it happen.

I am also wondering how does this fit with the llvm-busybox proposal? That goes in a completly different direction, by coalescing all of llvm/clang/lld in a single executable. We could simply go along those lines: a single DLL per "project" (clang, llvm, lld) with the existing bintools as executable wrappers on the top of that. Is that the single-DSO config that @rnk mentions? Doing that seems almost a no-brainer in terms of defining the API boundaries.

I don't think that the multicall binary is particularly great, but, yes, this will solve the problem of the size at least - all of the tools should be effectively in a single DLL. The frontends would be tiny. I am not hardset on the original idea of 2/3 DLLs for LLVM and 1/2 DLLs for clang. I could be convinced that 2 DLLs for LLVM (Support and LLVM) and 1 for clang is a decent enough split. My intuition is that 3 for LLVM and 1/2 for Clang would be a pretty good compromise (LLVMSupport, LLVMTooling, LLVMCompiler for LLVM and potentially just Clang for clang).

[compnerd]

Further progress; gets through most of the build of clang.

[compnerd]

llvm/lib/Support/CMakeLists.txt

104

You are correct, and this hunk is not something we can check in. However, it is the fastest way to burn through the annotations. Once we have the annotations correct, tweaking the build to match the correct behaviour is a simpler task.

[compnerd]

Rebase to the current main branch; further extend the annotations for building the unittests.

[MaskRay]

Thanks for working on this! I agree that LLVM_*_ABI is a better name because it is related to what interfaces other libraries can use.

In D109192#2983041, @compnerd wrote:

In D109192#2982999, @rnk wrote:

In D109192#2982723, @compnerd wrote:

Some additional questions:

• should we be encouraging of exporting entire classes or should we be more judicious in the visibility (e.g. attribute members)? I'm not 100% certain that this works for non-dll-interface targets.

I think you can give entire classes default visibility, and that will apply to all members. I think we should annotate classes because it will reduce the total number of annotations, and that will reduce the churn. For large, key classes that have too many private methods (Sema, ASTContext?) we can go back later and export only the public APIs, or something like that.

This is sort of the direction that I had in mind. The problem is, there are cases where I cannot get the desired behaviour correct. Doing those where it doesn't just work seems like an easier path and one that could be refined later. Its a bit unfortunate, but seems like a decent trade off.

I'm more convinced now that we should introduce an option to introduce this behaviour. The new option can opt into building the shared library components. Perhaps something like LLVM_EXPERIMENTAL_SHARED_LIBRARY_COMPONENTS is a good option name?

I agree this new thing shouldn't become the default build config. How close is this to BUILD_SHARED_LIBS vs LLVM_ENABLE_DYLIB? Can we repurpose one of those?

I think that BUILD_SHARED_LIBS is desirable, and LLVM_ENABLE_DYLIB should go away. That said, I think that the ideal thing here is to have a different configuration that is less granular than BUILD_SHARED_LIBS. That would correspond to LLVMTools, LLVMCompiler and depending on the delta, a potential third library. These three would give us a nice hybrid approach to dynamic and static linking. It would be dynamic for buckets of use (bintuils, clang, and possibly lld if it makes LLVMTools too large) but statically linking large components of LLVM to enable us to take advantage of LTO and DCE amongst that set. It would try to minimise the cost of the GOT/PLT and IAT so that we don't introduce an extremely heavy penalty for these libraries.

Why should LLVM_ENABLE_DYLIB go away? To reduce the number of configurations when the few-dylibs scheme is adopted more?
Other than that, I don't see any downside.

---

Going in a completely different direction, why even start by splitting out Support as its own shared library? We already have the single-DSO build config, why not improve that by adding annotations and using -fvisibility=hidden?

I don't really care if we keep LLVMSupport as a separate library or not in the end. The point here is to work through a representative set to setup such a configuration. This gives us a good pattern to apply and tries to iron out the issues that this brings up in a smaller context. The -fvisbility=hidden (and -fvisibility-inlines-hidden) is a requirement for this so we do not continually regress. One of the hacks in this patch is the unconditional application of that to LLVMSupport (which I will remove as this patch gets closer to a final form). I don't think that the single DSO configuration is ideal either, we would still have an unnecessarily large overhead for tooling. I think that the ideal split would be a library sufficient for the binutils, a second library that has everything else that is needed for clang.

llvm/include/llvm/Support/LLVMSupportExports.h

13

For flexibility, maybe give user a choice to redefine LLVM_*_ABI. Some users may want to customize this to hidden to enable better internalization (LTO,DCE) and linker GC.

llvm/lib/Support/CMakeLists.txt

289

-fvisibility=hidden implies -fvisibility-inlines-hidden

[fodinabor]

The missing symbols on Linux are: DebugFlag, isCurrentDebugType, Error::fatalUncheckedError and vtables of cl::opt, ErrorList and cl::OptionValue<std::string>.

llvm/include/llvm/ADT/APInt.h

72 ↗

(On Diff #370750)

Linux needs LLVM_SUPPORT_ABI LLVM_NODISCARD

Same with APSInt

llvm/include/llvm/ADT/SmallVector.h

92 ↗

(On Diff #370750)

missing class after template
two lines below as well

As the external functions are already marked LLVM_SUPPORT_ABI I'm not sure we need the annotation here anyways?
Otherwise, the LLVM_SUPPORT_ABI here should only be added for Linux, and the annotation has to be added to the explicit instantiation in SmallVector.cpp as well (for both Win / Linux)

llvm/include/llvm/Support/LLVMSupportExports.h

31

typo

llvm/include/llvm/Support/YAMLTraits.h

21 ↗

(On Diff #370750)

U typo, in MD5.h as well.

llvm/lib/Support/Windows/Threading.inc

27 ↗

(On Diff #370750)

same changes required for Unix/Threading.inc to silence the warnings there

[compnerd]

• builds clang, clang-tools-extra, lld
• cleans up C4910
• TODO clean up CMakeLists.txt hack
• C4251 remains to be sorted out (/wd4251 recommended on Windows)

Statistics:

• ~4K exports from LLVMSupport
• 32 anchors exported (unnecessary

I'd like to remove the anchors globally in a subsequent change, introduce a DECLARE_LLVM_KEY_FUNCTION and DECLARE_LLVM_KEY_FUNCTION(type) macro which would remove the anchors on Windows

• 364 symbols are being over-exported (private CXXMethodDecls/Variables)

I'd like to fix this subsequently as there is a cost associated with this on Windows - IAT relocation will be paid on them but will never be used and we cannot selectively mark them for late binding

[compnerd]

llvm/include/llvm/Support/LLVMSupportExports.h

13

Wait, we want to give the user the flexibility to *not* define that? I intend to make -fvisibility=hidden the only option once the annotations are complete. I want to simply globally set:

set(CMAKE_C_VISIBILITY_PRESET hidden)
set(CMAKE_CXX_VISIBILITY_PRESET hidden)
set(CMAKE_C_VISIBILITY_INLINES_HIDDEN YES)
set(CMAKE_CXX_VISIBILITY_INLINES_HIDDEN YES)

Everything in LLVM should be internalized unless you are doing a shared library build, where the annotations will expose the necessary interfaces.

Is there a use case that I am not considering?

[compnerd]

In D109192#2983824, @MaskRay wrote:

I think that BUILD_SHARED_LIBS is desirable, and LLVM_ENABLE_DYLIB should go away. That said, I think that the ideal thing here is to have a different configuration that is less granular than BUILD_SHARED_LIBS. That would correspond to LLVMTools, LLVMCompiler and depending on the delta, a potential third library. These three would give us a nice hybrid approach to dynamic and static linking. It would be dynamic for buckets of use (bintuils, clang, and possibly lld if it makes LLVMTools too large) but statically linking large components of LLVM to enable us to take advantage of LTO and DCE amongst that set. It would try to minimise the cost of the GOT/PLT and IAT so that we don't introduce an extremely heavy penalty for these libraries.

Why should LLVM_ENABLE_DYLIB go away? To reduce the number of configurations when the few-dylibs scheme is adopted more?
Other than that, I don't see any downside.

Because the LLVM build system is far too complex. Once we have the annotations, I don't see why we should continue to use custom build system logic versus the CMake standard BUILD_SHARED_LIBS. That would allow the few dylib scheme to be adopted and reduce the complexity in the build system and homogenise the distribution and development builds hopefully.

[jrtc27]

In D109192#2983869, @compnerd wrote:

In D109192#2983824, @MaskRay wrote:

I think that BUILD_SHARED_LIBS is desirable, and LLVM_ENABLE_DYLIB should go away. That said, I think that the ideal thing here is to have a different configuration that is less granular than BUILD_SHARED_LIBS. That would correspond to LLVMTools, LLVMCompiler and depending on the delta, a potential third library. These three would give us a nice hybrid approach to dynamic and static linking. It would be dynamic for buckets of use (bintuils, clang, and possibly lld if it makes LLVMTools too large) but statically linking large components of LLVM to enable us to take advantage of LTO and DCE amongst that set. It would try to minimise the cost of the GOT/PLT and IAT so that we don't introduce an extremely heavy penalty for these libraries.

Why should LLVM_ENABLE_DYLIB go away? To reduce the number of configurations when the few-dylibs scheme is adopted more?
Other than that, I don't see any downside.

Because the LLVM build system is far too complex. Once we have the annotations, I don't see why we should continue to use custom build system logic versus the CMake standard BUILD_SHARED_LIBS. That would allow the few dylib scheme to be adopted and reduce the complexity in the build system and homogenise the distribution and development builds hopefully.

The whole point of the option though is to make incremental builds faster which is really helpful for development. I'd be against removing that as all my development builds use it.

[compnerd]

• correct order of LLVM_NODISCARD and LLVM_SUPPORT_ABI
• annotate kInvalidFile

[compnerd]

• force a vtable instantiation to create an anchor for the for opt specializations
• more tweaks for Windows path (clang-test and llvm-test now build)

[compnerd]

• correct declaration for cl::opt extern template instantiations
• adjust ABI breaking check handling

[compnerd]

correct typo in CommandLine.cpp

[compnerd]

annotate some types for MLIR from flang

[compnerd]

check-mlir should build now

[jrtc27]

As before: what's the strategy for downstreams that modify these libraries? Has this been done entirely by hand, or is there some kind of script they can use to automate annotating their own additions?

[compnerd]

In D109192#2984222, @jrtc27 wrote:

As before: what's the strategy for downstreams that modify these libraries? Has this been done entirely by hand, or is there some kind of script they can use to automate annotating their own additions?

Before?

Yes, this has been done by hand. I'm not sure if I can get a perfect result through automation (https://github.com/compnerd/libtool), but I'm looking into that as an option. At least for the standalone functions, its relatively easy to get the desired behaviour correct. But, in general, for downstream repositories, this will likely require the usual porting and an additional audit of their changes.

[compnerd]

I should mention that this doesn't matter to the downstream projects at the end of the day - they aren't compelled to enable the shared library mode - static linking will be unimpacted.

[jrtc27]

In D109192#2984249, @compnerd wrote:

I should mention that this doesn't matter to the downstream projects at the end of the day - they aren't compelled to enable the shared library mode - static linking will be unimpacted.

We have significant downstream changes, and we regularly build with shared libraries for development, only static linking in our release builds. This will affect us and having to chase down a bunch of functions with LLVM_SUPPORT_ABI does not fill me with joy. Yes, static linking is great for releases, but it sucks for development, full per-component shared libraries make things much faster, please don't just dismiss it.

[compnerd]

• annotate Errno.h functions
• change StringRef to decorate explicit functions, fixing flang builds

[compnerd]

In D109192#2984252, @jrtc27 wrote:

In D109192#2984249, @compnerd wrote:

I should mention that this doesn't matter to the downstream projects at the end of the day - they aren't compelled to enable the shared library mode - static linking will be unimpacted.

We have significant downstream changes, and we regularly build with shared libraries for development, only static linking in our release builds. This will affect us and having to chase down a bunch of functions with LLVM_SUPPORT_ABI does not fill me with joy. Yes, static linking is great for releases, but it sucks for development, full per-component shared libraries make things much faster, please don't just dismiss it.

Well, per-component would be significantly worse - LLVM_SUPPORT_ABI marks what just LLVMSupport exports. You would need a separate macro per component if you do a shared library build with a per-component shared library. Doing a set 2-3 libraries means that there are only 2-3 macros that need to be contended with and its easier to identify which module the function resides in. That also means that it is more viable to find LTO/DCE optimizations.

[jrtc27]

In D109192#2984255, @compnerd wrote:

In D109192#2984252, @jrtc27 wrote:

In D109192#2984249, @compnerd wrote:

I should mention that this doesn't matter to the downstream projects at the end of the day - they aren't compelled to enable the shared library mode - static linking will be unimpacted.

We have significant downstream changes, and we regularly build with shared libraries for development, only static linking in our release builds. This will affect us and having to chase down a bunch of functions with LLVM_SUPPORT_ABI does not fill me with joy. Yes, static linking is great for releases, but it sucks for development, full per-component shared libraries make things much faster, please don't just dismiss it.

Well, per-component would be significantly worse - LLVM_SUPPORT_ABI marks what just LLVMSupport exports. You would need a separate macro per component if you do a shared library build with a per-component shared library. Doing a set 2-3 libraries means that there are only 2-3 macros that need to be contended with and its easier to identify which module the function resides in. That also means that it is more viable to find LTO/DCE optimizations.

I don't care about efficiency downstream, I just don't want it to be broken. If you break per-component shared libraries you force me to change my workflow and have slower incremental builds. If I have to go chasing down build errors because our additions need exporting in order for the monolithic shared build to work then I get grumpy at the busywork. If there's strong technical justification for the latter, fine, but please do it in as least disruptive a way as possible (i.e. with as much automation as possible, and in one go rather than spread across 10s of commits). I see no technical justification for the former, that would just be breaking workflows that you personally don't use.

[compnerd]

In D109192#2984273, @jrtc27 wrote:

In D109192#2984255, @compnerd wrote:

In D109192#2984252, @jrtc27 wrote:

In D109192#2984249, @compnerd wrote:

I should mention that this doesn't matter to the downstream projects at the end of the day - they aren't compelled to enable the shared library mode - static linking will be unimpacted.

We have significant downstream changes, and we regularly build with shared libraries for development, only static linking in our release builds. This will affect us and having to chase down a bunch of functions with LLVM_SUPPORT_ABI does not fill me with joy. Yes, static linking is great for releases, but it sucks for development, full per-component shared libraries make things much faster, please don't just dismiss it.

Well, per-component would be significantly worse - LLVM_SUPPORT_ABI marks what just LLVMSupport exports. You would need a separate macro per component if you do a shared library build with a per-component shared library. Doing a set 2-3 libraries means that there are only 2-3 macros that need to be contended with and its easier to identify which module the function resides in. That also means that it is more viable to find LTO/DCE optimizations.

I don't care about efficiency downstream, I just don't want it to be broken. If you break per-component shared libraries you force me to change my workflow and have slower incremental builds. If I have to go chasing down build errors because our additions need exporting in order for the monolithic shared build to work then I get grumpy at the busywork. If there's strong technical justification for the latter, fine, but please do it in as least disruptive a way as possible (i.e. with as much automation as possible, and in one go rather than spread across 10s of commits). I see no technical justification for the former, that would just be breaking workflows that you personally don't use.

Well, it may be that your downstream project doesn't care about efficiency, but every project has a differing set of needs and makes different tradeoffs. This is an issue for LLVM, and impacting performance of the compiler to make a particular workflow possible is not valid justification. There are technical grounds for preferring the semi-monolithic library for the tooling and the compiler.

[compnerd]

Expose LLVMParseCommandLineOptions

[jrtc27]

In D109192#2984294, @compnerd wrote:

In D109192#2984273, @jrtc27 wrote:

In D109192#2984255, @compnerd wrote:

In D109192#2984252, @jrtc27 wrote:

In D109192#2984249, @compnerd wrote:

I should mention that this doesn't matter to the downstream projects at the end of the day - they aren't compelled to enable the shared library mode - static linking will be unimpacted.

We have significant downstream changes, and we regularly build with shared libraries for development, only static linking in our release builds. This will affect us and having to chase down a bunch of functions with LLVM_SUPPORT_ABI does not fill me with joy. Yes, static linking is great for releases, but it sucks for development, full per-component shared libraries make things much faster, please don't just dismiss it.

Well, per-component would be significantly worse - LLVM_SUPPORT_ABI marks what just LLVMSupport exports. You would need a separate macro per component if you do a shared library build with a per-component shared library. Doing a set 2-3 libraries means that there are only 2-3 macros that need to be contended with and its easier to identify which module the function resides in. That also means that it is more viable to find LTO/DCE optimizations.

I don't care about efficiency downstream, I just don't want it to be broken. If you break per-component shared libraries you force me to change my workflow and have slower incremental builds. If I have to go chasing down build errors because our additions need exporting in order for the monolithic shared build to work then I get grumpy at the busywork. If there's strong technical justification for the latter, fine, but please do it in as least disruptive a way as possible (i.e. with as much automation as possible, and in one go rather than spread across 10s of commits). I see no technical justification for the former, that would just be breaking workflows that you personally don't use.

Well, it may be that your downstream project doesn't care about efficiency, but every project has a differing set of needs and makes different tradeoffs. This is an issue for LLVM, and impacting performance of the compiler to make a particular workflow possible is not valid justification. There are technical grounds for preferring the semi-monolithic library for the tooling and the compiler.

Preferring != requiring. Of course if there's sufficient technical justification for removing that option then fine, but that's for the community to decide, not you.

[lebedev.ri]

FWIW, i personally think that the current set of libs BUILD_SHARED_LIBS produces should not change, it's intentional that way, to both be fast and fine-grained.
And LLVM_BUILD_DYLIB is also intentionally producing a huge monolithic library, so that only a single library needs to be dlopened for speed reasons.
IIRC someone from MLIR also wanted to do something about library restructurization, i would suggest to talk to them.

All that being said, if either BUILD_SHARED_LIBS or LLVM_BUILD_DYLIB is being changed from what they are now,
i think this requires an RFC to llvm-dev with precise explanation of what why and how,
and why it's okay to regress existing granularity/speed/performance expectations.

[compnerd]

In D109192#2984318, @lebedev.ri wrote:

FWIW, i personally think that the current set of libs BUILD_SHARED_LIBS produces should not change, it's intentional that way, to both be fast and fine-grained.
And LLVM_BUILD_DYLIB is also intentionally producing a huge monolithic library, so that only a single library needs to be dlopened for speed reasons.
IIRC someone from MLIR also wanted to do something about library restructurization, i would suggest to talk to them.

All that being said, if either BUILD_SHARED_LIBS or LLVM_BUILD_DYLIB is being changed from what they are now,
i think this requires an RFC to llvm-dev with precise explanation of what why and how,
and why it's okay to regress existing granularity/speed/performance expectations.

This change has no impact on what BUILD_SHARED_LIBS does. It does however fix the current problem that LLVMSupport on WIndows when built as a shared library has no public functions and on ELF and MachO targets exports everything. Instead, this will explicitly control the public surface of the library's interface when built as a shared library.

There are similar changes that will be needed to support building LLVM as a shared library, but that is a separate larger change and I have no intention of merging that change into this change.

[MaskRay]

If I am to summarize the state. The currently ELF build models are:

• default: libLLVMSupport.a
• -DBUILD_SHARED_LIBS=on: libLLVMSupport.so
• -DLLVM_LINK_LLVM_DYLIB=on: libLLVM-14git.so

MSVC dynamic linking doesn't work.

From

• minimal set of interfaces required for llvm-ar (archiver/librarian)
• minimal set of interfaces required for lld (linker)
• minimal set of interfaces required for clang (compiler)

it seems that the intention is to have libLLVM{foo,bar,qux}.so as the end state? And that is a controversial point among at least @compnerd, @jrtc27, and me.

I think the main purpose of this patch is to introduce these source file annotations (LLVM_SUPPORT_ABI #include "llvm/Support/LLVMSupportExports.h") which will be the backbone of whatever dynamic linking mode we end up doing.
And we should ensure all parties are satisfied with the solution.
If you remove the behavior changing CMake changes, I will give a strong support.

Specifically, any risky CMake or visibility annotation changes should be dropped from this starting point patch. More concretely,

• #define LLVM_SUPPORT_ABI is acceptable since it is clearly a no-op.
• #define LLVM_SUPPORT_ABI __attribute__((visibility("protected"))) can be risky and is thus unacceptable
• Changing -DBUILD_SHARED_LIBS=on behavior is unacceptable (this presumably doesn't work on MSVC, so changing MSVC is fine). MinGW seems to support this config, so don't change its behavior (CC @mstorsjo)
• Changing -DLLVM_LINK_LLVM_DYLIB=on behavior is unacceptable (this doesn't work on MSVC, so changing MSVC is fine)

---

Currently there is a hacking change in lib/Support/CMakeLists.txt: add_llvm_component_library(LLVMSupport SHARED
This breaks the regular libLLVMSupport.a build, so it should be fixed.

The libLLVM{foo,bar,qux}.so design is related to the Windows DLL limitation about 64k exported symbols.
To reduce platform differences (ELF/Mach-O vs PE/COFF), @compnerd wants the libLLVM{foo,bar,qux}.so design to be the way forward and the monolithic libLLVM-14git.so scheme to be dropped.
I agree with @lebedev.ri that such change needs to discussed on llvm-dev.
The libLLVM-14git.so scheme is adopted by multiple major Linux distributions with many LLVM dependent packages.
Such a split should not be taken lightly.

FWIW For my https://github.com/MaskRay/ccls/blob/master/CMakeLists.txt#L95 , I'll need to adjust

if(LLVM_LINK_LLVM_DYLIB)
  target_link_libraries(ccls PRIVATE LLVM)

Other packages may need similar adaptation as well.
Personally I consider that ELF/Mach-O changing libLLVM-14git.so to cater to Windows DLL limitation unfortunate, but I can be convinced if the split argument (platform difference, maintenance cost consideration) is sufficiently strong.

[compnerd]

In D109192#2984321, @MaskRay wrote:

If I am to summarize the state. The currently ELF build models are:

• default: libLLVMSupport.a
• -DBUILD_SHARED_LIBS=on: libLLVMSupport.so
• -DLLVM_LINK_LLVM_DYLIB=on: libLLVM-14git.so

Windows dynamic linking doesn't work.

From

• minimal set of interfaces required for llvm-ar (archiver/librarian)
• minimal set of interfaces required for lld (linker)
• minimal set of interfaces required for clang (compiler)

it seems that the intention is to have libLLVM{foo,bar,qux}.so as the end state? And that is a controversial point among at least @compnerd, @jrtc27, and me.

I think the main purpose of this patch is to introduce these source file annotations (LLVM_SUPPORT_ABI #include "llvm/Support/LLVMSupportExports.h") which will be the backbone of whatever dynamic linking mode we end up doing.
And we should ensure all parties are satisfied with the solution.
If you remove the behavior changing CMake changes, I will give a strong support.

More to introduce the model for the annotations. The annotations are module dependent, that is each module must introduce its own decoration and the function must have a clear owner defined, which is why LLVMSupport is a good basis for the conceptual change - the intent is that the functions in LLVMSupport are owned by LLVMSupport and thus will be annotated with the LLVM_SUPPORT_ABI.

Specifically, any risky CMake or visibility annotation should be dropped from this starting point.

I think that this we disagree on. I think that the visibility handling needs to be part of this - otherwise the behaviour becomes too complicated to reason about. The default beahviour on Windows is that the symbol is dso_local and the default behaviour on ELF and MachO targets is *not* dso_local. This means that we have different defaults and any future change will need to contend with this. By changing the visibility for LLVMSupport when building LLVMSupport as a shared library to hidden visibility, we should get consistent behaviour across the board and make it easier to reason through for changes.

E.g.

• #define LLVM_SUPPORT_ABI is acceptable since it is clearly a no-op.
• #define LLVM_SUPPORT_ABI __attribute__((visibility("protected"))) can be risky and is thus unacceptable
• Changing -DBUILD_SHARED_LIBS=on behavior is unacceptable (this presumably doesn't work on Windows, so changing Windows is fine)
• Changing -DLLVM_LINK_LLVM_DYLIB=on behavior is unacceptable (this doesn't work on Windows, so changing Windows is fine)

---

Currently there is a hacking change in lib/Support/CMakeLists.txt: add_llvm_component_library(LLVMSupport SHARED
This breaks the regular libLLVMSupport.a build, so it should be fixed.

Yes, and I even commented as such that it is unacceptable, but is done to allow for quick turnaround on testing. Once the pre-commit checks have verified that it is happy with the build, this will be changed to restore the build of LLVMSupport to the way that it is handled today.

The libLLVM{foo,bar,qux}.so design is related to the Windows DLL limitation about 64k exported symbols.
To reduce platform differences (ELF/Mach-O vs PE/COFF), @compnerd wants the libLLVM{foo,bar,qux}.so design to be the way forward and the monolithic libLLVM-14git.so scheme to be dropped.
I agree with @lebedev.ri that such change needs to discussed on llvm-dev.
The libLLVM-14git.so scheme is adopted by multiple major Linux distributions with many LLVM dependent packages.
Such a split should not be taken lightly.

Yes I do expect that we are going to hit the limit of the exported symbols and thus its very likely to require that split. However, I cannot say with certainty that will happen until we get to that point. Once LLVMSupport changes are baked enough to demonstrate the pattern, the changes to allow building LLVM as a library can be tested to see what the current limitation is. The more fragmented the build, the worse it is for optimizations and size reduction possibilities. It also makes distribution more complicated.

FWIW For my https://github.com/MaskRay/ccls/blob/master/CMakeLists.txt#L95 , I'll need to adjust

if(LLVM_LINK_LLVM_DYLIB)
  target_link_libraries(ccls PRIVATE LLVM)

Other packages may need similar adaptation as well.
Personally I consider that ELF/Mach-O changing libLLVM-14git.so to cater to Windows DLL limitation unfortunate, but I can be convinced if the split argument (platform difference, maintenance cost consideration) is sufficiently strong.

I don't think that it is "catering" nor "unfortunate". There are tradeoffs in software engineering, and this is one of them. There are similar issues where LLVM is doing things that are non-optimal and other platforms suffer from them. An example is the use of the anchor key functions which are meaningless on some platforms.

The current state of the shared library build is another example of the "unfortunate" results of supporting ELF targets (I say this as a counterpoint to your argument that it is unfortunate that ELF must do something different, I tend to care about ELF targets just as much as PE/COFF targets).

Platforms are different, and software engineering requires that you evaluate different tradeoffs. There is a rich design space for structuring binaries, and choices aren't inherently unfortunate. They are evaluating with different weights being ascribed to different features, and that results in different choices.

Keeping LLVM friendly to a variety of platforms with contributors developing and testing on a different set of platforms means that it is best to have it behave as consistently as possible. This reduces the likelihood of someone unintentionally regressing a system other than the one that they are developing on.

[compnerd]

rebase

[compnerd]

The c-index-test failure is interesting. libclang will link against LLVMPasses and have the enable-ml-inliner option and thus register it. c-index-tool itself links against LLVMPasses and thus registers the option again, resulting in the duplicate registration.

[echristo]

Hi Saleem,

I think I understand where you're going, but I think this deserves a writeup and consideration on llvm-dev with your desired endpoint for the source base and what changes to both current and future development will need to happen with some benefits and costs outlined. Might want to include a "support story" for the project along these lines as well - or at least be clear that this doesn't change or affect what long term APIs we are willing to support.

Thoughts?

[compnerd]

In D109192#2990039, @echristo wrote:

Hi Saleem,

I think I understand where you're going, but I think this deserves a writeup and consideration on llvm-dev with your desired endpoint for the source base and what changes to both current and future development will need to happen with some benefits and costs outlined. Might want to include a "support story" for the project along these lines as well - or at least be clear that this doesn't change or affect what long term APIs we are willing to support.

Thoughts?

I think that is inline with what I had expected. I actually asked @rnk about his thoughts on this as well, and he was of the opinion that this wouldn't be a big surprise and to send out a proposed change first. I wanted to get through LLVMSupport to the point that it would be possible to show what an approach for enabling a shared library build that could support all the platforms would look like. I don't have any concerns with sending out a small write up of what the changes once at least the Windows pre-commit CI is green. I already had expected to have to do that subsequently as I don't expect to tackle LLVM in a single change. I had expected this to serve as a preparatory change to discuss the necessary changes for permitting LLVM_ENABLE_DYLIB builds on Windows.

[arichardson]

llvm/include/llvm/Support/LLVMSupportExports.h

13

If we need to add this for every library, it seems like the header should be generated?

Maybe we could even re-use https://cmake.org/cmake/help/latest/module/GenerateExportHeader.html?

[rnk]

llvm/include/llvm/Support/LLVMSupportExports.h

13

CMake is the official build system for LLVM, so maybe this should not weigh on the project priorities, but there are two unofficial build systems in-tree that would have to replicate this functionality (Bazel & gn).

I think we should strive to keep the build system as simple as possible, even if it has ways to help us reduce boilerplate code. Most LLVM developers are not CMake experts, but we can all read and reason about C++ and C pre-processor directives.

I believe there are ways to factor out the selection of the appropriate attribute using token pasting.

[compnerd]

llvm/include/llvm/Support/LLVMSupportExports.h

13

We would in order to support BUILD_SHARED_LIBS universally. However, my goal is not to enable BUILD_SHARED_LIBS but rather allow LLVM_BUILD_LLVM_DYLIB which builds a single shared library. LLVMSupport is a good target to demonstrate what is needed without having to implement the full coverage for all of LLVM without actually reaching some consensus. That said, I would certainly be interested in having LLVMSupport as a shared library as well.

[fortsnek9348]

This comment was removed by fortsnek9348.

[tstellar]

After talking with @compnerd on Discord, I'm planning on helping to push this
patch through. At this point my goal is just to annotate the ABI functions and
not make any changes to how -DBUILD_SHARED_LIBS=ON or -DLLVM_LINK_LLVM_DYLIB=ON
behave. We can make changes to those configurations in a future patch (if we
want to).

My plan is to:

1. Annotate all the ABI functions in the LLVM support library with LLVM_SUPPORT_ABI macro (this patch), and use this an example for how to do the rest of the annotations.
2. Annotate the rest of the LLVM ABI functions using a different macro (e.g. LLVM_ABI)
3. Annotate the C ABI with a third macro (e.g. LLVM_C_ABI).
4. Annotate the clang C++ ABI with another macro (e.g. CLANG_CPP_ABI).
5. Do an analysis of which ABI functions usage inside and outside of the tree, and remove unused functions from the public ABI (i.e. mark them as visibility hidden).

For this patch, I've rebased it on main and made a few changes:

• Add ABI annotations to classes and remove them from class member functions.

This will make the patch smaller and easier to maintain. We can always revisit
this in the future once we have the complete set of ABIs annotated.

• Use default visibility instead of protected visibility on Linux.

• Drop the add_llvm_component_library(LLVMSupport SHARED change.

[nikic]

In D109192#4407274, @tstellar wrote:

After talking with @compnerd on Discord, I'm planning on helping to push this
patch through. At this point my goal is just to annotate the ABI functions and
not make any changes to how -DBUILD_SHARED_LIBS=ON or -DLLVM_LINK_LLVM_DYLIB=ON
behave. We can make changes to those configurations in a future patch (if we
want to).

My plan is to:

1. Annotate all the ABI functions in the LLVM support library with LLVM_SUPPORT_ABI macro (this patch), and use this an example for how to do the rest of the annotations.
2. Annotate the rest of the LLVM ABI functions using a different macro (e.g. LLVM_ABI)

Why do we need/want to annotate the support library with a different macro from everything else? Isn't LLVMSupport part of libLLVM just like the rest?

We already have the LLVM_EXTERNAL_VISIBILITY and LLVM_LIBRARY_VISIBILITY macros. LLVM_EXTERNAL_VISIBILITY is used in the places that already use the -fvisibility=hidden default, namely the backend. LLVM_LIBRARY_VISIBILTY is used in a few places that want to explicitly exclude symbols in code that still uses default visibilty.

I would have expected that this would annotate symbols using the existing LLVM_EXTERNAL_VISIBILITY macro (and LLVM_LIBRARY_VISIBILITY could be retired once everything uses -fvisibility=hidden).

llvm/include/llvm/Support/LLVMSupportExports.h

14

What is the LLVM_SUPPORT_STATIC variable for? I don't see it defined anywhere.

[compnerd]

In D109192#4443741, @nikic wrote:

In D109192#4407274, @tstellar wrote:

After talking with @compnerd on Discord, I'm planning on helping to push this
patch through. At this point my goal is just to annotate the ABI functions and
not make any changes to how -DBUILD_SHARED_LIBS=ON or -DLLVM_LINK_LLVM_DYLIB=ON
behave. We can make changes to those configurations in a future patch (if we
want to).

My plan is to:

1. Annotate all the ABI functions in the LLVM support library with LLVM_SUPPORT_ABI macro (this patch), and use this an example for how to do the rest of the annotations.
2. Annotate the rest of the LLVM ABI functions using a different macro (e.g. LLVM_ABI)

Why do we need/want to annotate the support library with a different macro from everything else? Isn't LLVMSupport part of libLLVM just like the rest?

LLVMSupport is used very commonly as a support library outside of LLVM.

We already have the LLVM_EXTERNAL_VISIBILITY and LLVM_LIBRARY_VISIBILITY macros. LLVM_EXTERNAL_VISIBILITY is used in the places that already use the -fvisibility=hidden default, namely the backend. LLVM_LIBRARY_VISIBILTY is used in a few places that want to explicitly exclude symbols in code that still uses default visibilty.

I would have expected that this would annotate symbols using the existing LLVM_EXTERNAL_VISIBILITY macro (and LLVM_LIBRARY_VISIBILITY could be retired once everything uses -fvisibility=hidden).

Visibility and DLL Storage are technically different and provide subtly different things. LLVM_EXTERNAL_VISIBILITY does not take the library into account nor does it take into account the static vs dynamic linking nature and thus would not be sufficient for the purposes of DLL Storage.

[rnk]

In D109192#4443741, @nikic wrote:

Why do we need/want to annotate the support library with a different macro from everything else? Isn't LLVMSupport part of libLLVM just like the rest?

We already have the LLVM_EXTERNAL_VISIBILITY and LLVM_LIBRARY_VISIBILITY macros. LLVM_EXTERNAL_VISIBILITY is used in the places that already use the -fvisibility=hidden default, namely the backend. LLVM_LIBRARY_VISIBILTY is used in a few places that want to explicitly exclude symbols in code that still uses default visibilty.

I would have expected that this would annotate symbols using the existing LLVM_EXTERNAL_VISIBILITY macro (and LLVM_LIBRARY_VISIBILITY could be retired once everything uses -fvisibility=hidden).

For DLL import/export annotations, we need to have distinct macros for every DLL we plan to make. The question then becomes, do we need libLLVMSupport.dll?

Building Support as a DLL is by far the most conventional and straightforward approach. There are many tools (FileCheck, llvm-tblgen) that use Support but not all of LLVM, and they need to be built first.

The alternative is that we place dllexport annotations across the Support APIs, but then we come up with some creative build rules to produce a special static Support library for all of the tools that don't or can't link to the main LLVM DSO. This approach has the risk of leading users into accidentally linking both libraries, which then results in linker errors or silent ODR violations with duplicated global state. We can avoid all this if we are willing to tolerate the complexity of using different ABI annotations in Support headers.

Personally, I think in the long run, having a separate support DLL will be the least confusing approach and will have the fewest surprises. However, I'm speaking as someone who contributed to the implementation of dllexport semantics in clang, so I am probably much more familiar with them than the average LLVM developer.

[tstellar]

Given that my plan right now is just to annotate the ABI and not create any new shared objects, should we still use a separate annotation for Support or should we just use the same annotation for the whole library and then specialize it later?

[nikic]

In D109192#4444582, @rnk wrote:

In D109192#4443741, @nikic wrote:

Why do we need/want to annotate the support library with a different macro from everything else? Isn't LLVMSupport part of libLLVM just like the rest?

We already have the LLVM_EXTERNAL_VISIBILITY and LLVM_LIBRARY_VISIBILITY macros. LLVM_EXTERNAL_VISIBILITY is used in the places that already use the -fvisibility=hidden default, namely the backend. LLVM_LIBRARY_VISIBILTY is used in a few places that want to explicitly exclude symbols in code that still uses default visibilty.

I would have expected that this would annotate symbols using the existing LLVM_EXTERNAL_VISIBILITY macro (and LLVM_LIBRARY_VISIBILITY could be retired once everything uses -fvisibility=hidden).

For DLL import/export annotations, we need to have distinct macros for every DLL we plan to make. The question then becomes, do we need libLLVMSupport.dll?

Building Support as a DLL is by far the most conventional and straightforward approach. There are many tools (FileCheck, llvm-tblgen) that use Support but not all of LLVM, and they need to be built first.

The alternative is that we place dllexport annotations across the Support APIs, but then we come up with some creative build rules to produce a special static Support library for all of the tools that don't or can't link to the main LLVM DSO. This approach has the risk of leading users into accidentally linking both libraries, which then results in linker errors or silent ODR violations with duplicated global state. We can avoid all this if we are willing to tolerate the complexity of using different ABI annotations in Support headers.

Personally, I think in the long run, having a separate support DLL will be the least confusing approach and will have the fewest surprises. However, I'm speaking as someone who contributed to the implementation of dllexport semantics in clang, so I am probably much more familiar with them than the average LLVM developer.

So I think I understand why we need a separate ABI macro and can't reuse the existing VISIBILTY ones, but I'm still not clear on why Support is special. Currently (if we ignore BUILD_SHARED_LIBS, which is orthogonal to this) we only support a single libLLVM dylib. Cases that cannot link the dylib for some reason will link against static libraries instead. (Things like tablegen I assume, but also things like llvm-exegesis that use private symbols.)

Is this about some hypothetical future extension where we split up libLLVM.so into smaller libraries (something I am somewhat skeptical about) or is there some Windows idiosyncrasy that requires the special treatment of the Support library?

[tstellar]

I'm leaning towards not having a separate macro for LLVMSupport and just using the LLVM_ABI macro for LLVMSupport and everything else.

[nikic]

In D109192#4474895, @tstellar wrote:

I'm leaning towards not having a separate macro for LLVMSupport and just using the LLVM_ABI macro for LLVMSupport and everything else.

I agree. We should have one macro for each currently existing dylib -- which is just the one for LLVM. If we want to introduce additional dylibs in the future, we should split the macro at that point in time.

[tstellar]

• Use generic LLVM_ABI macro instead of LLVM_SUPPORT_ABI
• Rebase

[rnk]

If we're not making a separate DLL for LLVM support, that sounds fine to me.

I'm worried that by limiting scope here, we're just deferring the discovery and resolution of problems that @compnerd already grappled with in his attempt to make LLVM DLLs, but it's also good to be incremental and get things moving.

[tstellar]

In D109192#4486226, @rnk wrote:

If we're not making a separate DLL for LLVM support, that sounds fine to me.

I'm worried that by limiting scope here, we're just deferring the discovery and resolution of problems that @compnerd already grappled with in his attempt to make LLVM DLLs, but it's also good to be incremental and get things moving.

I've got a WIP patch to add annotations to the rest of the ABI, I can merge that into this one if you think that's better.

[rnk]

In D109192#4486728, @tstellar wrote:

In D109192#4486226, @rnk wrote:

If we're not making a separate DLL for LLVM support, that sounds fine to me.

I'm worried that by limiting scope here, we're just deferring the discovery and resolution of problems that @compnerd already grappled with in his attempt to make LLVM DLLs, but it's also good to be incremental and get things moving.

I've got a WIP patch to add annotations to the rest of the ABI, I can merge that into this one if you think that's better.

Either approach seems fine to me.

[mstorsjo]

Even if this is approved, make sure that it actually successfully builds in Windows configs (last time I tried an earlier version of this patch it broke the build very severely). The premerge CI doesn't seem to have succeeded in applying the patch to even try building it.

llvm/include/llvm/Support/AArch64TargetParser.h

 //===----------------------------------------------------------------------===//
 
 #ifndef LLVM_SUPPORT_AARCH64TARGETPARSER_H
 #define LLVM_SUPPORT_AARCH64TARGETPARSER_H
 
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/ARMTargetParser.h"
+#include "llvm/Support/LLVMSupportExports.h"
 #include <vector>
 
 // FIXME:This should be made into class design,to avoid dupplication.
 namespace llvm {
 
 class Triple;
 
 namespace AArch64 {

 
 const ArchKind ArchKinds[] = {
 #define AARCH64_ARCH(NAME, ID, CPU_ATTR, SUB_ARCH, ARCH_ATTR, ARCH_FPU, ARCH_BASE_EXT) \
     ArchKind::ID,
 #include "AArch64TargetParser.def"
 };
 
 // FIXME: These should be moved to TargetTuple once it exists
-bool getExtensionFeatures(uint64_t Extensions,
+bool LLVMSupport_API getExtensionFeatures(uint64_t Extensions,
+                                          std::vector<StringRef> &Features);
+bool LLVMSupport_API getArchFeatures(ArchKind AK,
                                      std::vector<StringRef> &Features);
-bool getArchFeatures(ArchKind AK, std::vector<StringRef> &Features);
 
-StringRef getArchName(ArchKind AK);
-unsigned getArchAttr(ArchKind AK);
-StringRef getCPUAttr(ArchKind AK);
-StringRef getSubArch(ArchKind AK);
-StringRef getArchExtName(unsigned ArchExtKind);
-StringRef getArchExtFeature(StringRef ArchExt);
+StringRef LLVMSupport_API getArchName(ArchKind AK);
+unsigned LLVMSupport_API getArchAttr(ArchKind AK);
+StringRef LLVMSupport_API getCPUAttr(ArchKind AK);
+StringRef LLVMSupport_API getSubArch(ArchKind AK);
+StringRef LLVMSupport_API getArchExtName(unsigned ArchExtKind);
+StringRef LLVMSupport_API getArchExtFeature(StringRef ArchExt);
 
 // Information by Name
-unsigned getDefaultFPU(StringRef CPU, ArchKind AK);
-uint64_t getDefaultExtensions(StringRef CPU, ArchKind AK);
-StringRef getDefaultCPU(StringRef Arch);
-ArchKind getCPUArchKind(StringRef CPU);
+unsigned LLVMSupport_API getDefaultFPU(StringRef CPU, ArchKind AK);
+uint64_t LLVMSupport_API getDefaultExtensions(StringRef CPU, ArchKind AK);
+StringRef LLVMSupport_API getDefaultCPU(StringRef Arch);
+ArchKind LLVMSupport_API getCPUArchKind(StringRef CPU);
 
 // Parser
-ArchKind parseArch(StringRef Arch);
-ArchExtKind parseArchExt(StringRef ArchExt);
-ArchKind parseCPUArch(StringRef CPU);
+ArchKind LLVMSupport_API parseArch(StringRef Arch);
+ArchExtKind LLVMSupport_API parseArchExt(StringRef ArchExt);
+ArchKind LLVMSupport_API parseCPUArch(StringRef CPU);
+
 // Used by target parser tests
-void fillValidCPUArchList(SmallVectorImpl<StringRef> &Values);
+void LLVMSupport_API fillValidCPUArchList(SmallVectorImpl<StringRef> &Values);
 
-bool isX18ReservedByDefault(const Triple &TT);
+bool LLVMSupport_API isX18ReservedByDefault(const Triple &TT);
 
 struct ParsedBranchProtection {
   StringRef Scope;
   StringRef Key;
   bool BranchTargetEnforcement;
 };
 
-bool parseBranchProtection(StringRef Spec, ParsedBranchProtection &PBP,
+bool LLVMSupport_API parseBranchProtection(StringRef Spec,
+                                           ParsedBranchProtection &PBP,
                                            StringRef &Err);
 
 } // namespace AArch64
 } // namespace llvm
 
 #endif

llvm/include/llvm/Support/ARMTargetParser.h

 //===----------------------------------------------------------------------===//
 
 #ifndef LLVM_SUPPORT_ARMTARGETPARSER_H
 #define LLVM_SUPPORT_ARMTARGETPARSER_H
 
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/ARMBuildAttributes.h"
+#include "llvm/Support/LLVMSupportExports.h"
 #include <vector>
 
 namespace llvm {
 
 class Triple;
 
 namespace ARM {
 
#define ARM_ARCH(NAME, ID, CPU_ATTR, SUB_ARCH, ARCH_ATTR, ARCH_FPU,            \
    CPU_ATTR,     sizeof(CPU_ATTR) - 1,                                         \
    SUB_ARCH,     sizeof(SUB_ARCH) - 1,                                         \
    ARCH_FPU,     ARCH_BASE_EXT,                                                \
    ArchKind::ID, ARCH_ATTR},
 #include "llvm/Support/ARMTargetParser.def"
 };
 
 // Information by ID
-StringRef getFPUName(unsigned FPUKind);
-FPUVersion getFPUVersion(unsigned FPUKind);
-NeonSupportLevel getFPUNeonSupportLevel(unsigned FPUKind);
-FPURestriction getFPURestriction(unsigned FPUKind);
+StringRef LLVMSupport_API getFPUName(unsigned FPUKind);
+FPUVersion LLVMSupport_API getFPUVersion(unsigned FPUKind);
+NeonSupportLevel LLVMSupport_API getFPUNeonSupportLevel(unsigned FPUKind);
+FPURestriction LLVMSupport_API getFPURestriction(unsigned FPUKind);
 
 // FIXME: These should be moved to TargetTuple once it exists
-bool getFPUFeatures(unsigned FPUKind, std::vector<StringRef> &Features);
-bool getHWDivFeatures(uint64_t HWDivKind, std::vector<StringRef> &Features);
-bool getExtensionFeatures(uint64_t Extensions,
+bool LLVMSupport_API getFPUFeatures(unsigned FPUKind,
+                                    std::vector<StringRef> &Features);
+bool LLVMSupport_API getHWDivFeatures(uint64_t HWDivKind,
+                                      std::vector<StringRef> &Features);
+bool LLVMSupport_API getExtensionFeatures(uint64_t Extensions,
                                           std::vector<StringRef> &Features);
 
-StringRef getArchName(ArchKind AK);
-unsigned getArchAttr(ArchKind AK);
-StringRef getCPUAttr(ArchKind AK);
-StringRef getSubArch(ArchKind AK);
-StringRef getArchExtName(uint64_t ArchExtKind);
-StringRef getArchExtFeature(StringRef ArchExt);
-bool appendArchExtFeatures(StringRef CPU, ARM::ArchKind AK, StringRef ArchExt,
+StringRef LLVMSupport_API getArchName(ArchKind AK);
+unsigned LLVMSupport_API getArchAttr(ArchKind AK);
+StringRef LLVMSupport_API getCPUAttr(ArchKind AK);
+StringRef LLVMSupport_API getSubArch(ArchKind AK);
+StringRef LLVMSupport_API getArchExtName(uint64_t ArchExtKind);
+StringRef LLVMSupport_API getArchExtFeature(StringRef ArchExt);
+bool LLVMSupport_API appendArchExtFeatures(StringRef CPU, ARM::ArchKind AK,
+                                           StringRef ArchExt,
                                            std::vector<StringRef> &Features,
                                            unsigned &ArgFPUKind);
 
 // Information by Name
-unsigned getDefaultFPU(StringRef CPU, ArchKind AK);
-uint64_t getDefaultExtensions(StringRef CPU, ArchKind AK);
-StringRef getDefaultCPU(StringRef Arch);
-StringRef getCanonicalArchName(StringRef Arch);
-StringRef getFPUSynonym(StringRef FPU);
-StringRef getArchSynonym(StringRef Arch);
+unsigned LLVMSupport_API getDefaultFPU(StringRef CPU, ArchKind AK);
+uint64_t LLVMSupport_API getDefaultExtensions(StringRef CPU, ArchKind AK);
+StringRef LLVMSupport_API getDefaultCPU(StringRef Arch);
+StringRef LLVMSupport_API getCanonicalArchName(StringRef Arch);
+StringRef LLVMSupport_API getFPUSynonym(StringRef FPU);
+StringRef LLVMSupport_API getArchSynonym(StringRef Arch);
 
 // Parser
-uint64_t parseHWDiv(StringRef HWDiv);
-unsigned parseFPU(StringRef FPU);
-ArchKind parseArch(StringRef Arch);
-uint64_t parseArchExt(StringRef ArchExt);
-ArchKind parseCPUArch(StringRef CPU);
-ISAKind parseArchISA(StringRef Arch);
-EndianKind parseArchEndian(StringRef Arch);
-ProfileKind parseArchProfile(StringRef Arch);
-unsigned parseArchVersion(StringRef Arch);
-
-void fillValidCPUArchList(SmallVectorImpl<StringRef> &Values);
-StringRef computeDefaultTargetABI(const Triple &TT, StringRef CPU);
+uint64_t LLVMSupport_API parseHWDiv(StringRef HWDiv);
+unsigned LLVMSupport_API parseFPU(StringRef FPU);
+ArchKind LLVMSupport_API parseArch(StringRef Arch);
+uint64_t LLVMSupport_API parseArchExt(StringRef ArchExt);
+ArchKind LLVMSupport_API parseCPUArch(StringRef CPU);
+ISAKind LLVMSupport_API parseArchISA(StringRef Arch);
+EndianKind LLVMSupport_API parseArchEndian(StringRef Arch);
+ProfileKind LLVMSupport_API parseArchProfile(StringRef Arch);
+unsigned LLVMSupport_API parseArchVersion(StringRef Arch);
+
+void LLVMSupport_API fillValidCPUArchList(SmallVectorImpl<StringRef> &Values);
+StringRef LLVMSupport_API computeDefaultTargetABI(const Triple &TT,
+                                                  StringRef CPU);
 
 } // namespace ARM
 } // namespace llvm
 
 #endif

llvm/include/llvm/Support/Atomic.h

 // New code should always rely on the std::atomic facilities in C++11.
 //
 //===----------------------------------------------------------------------===//
 
 #ifndef LLVM_SUPPORT_ATOMIC_H
 #define LLVM_SUPPORT_ATOMIC_H
 
 #include "llvm/Support/DataTypes.h"
+#include "llvm/Support/LLVMSupportExports.h"
 
 // Windows will at times define MemoryFence.
 #ifdef MemoryFence
 #undef MemoryFence
 #endif
 
 namespace llvm {
-  namespace sys {
-    void MemoryFence();
+void LLVMSupport_API MemoryFence();
 
 #ifdef _MSC_VER
-    typedef long cas_flag;
 #else
-    typedef uint32_t cas_flag;
 #endif
-    cas_flag CompareAndSwap(volatile cas_flag* ptr,
-                            cas_flag new_value,
-                            cas_flag old_value);
-  }
-}
+
+cas_flag LLVMSupport_API CompareAndSwap(volatile cas_flag *ptr,
+                                        cas_flag new_value, cas_flag old_value);
+} // namespace sys
+} // namespace llvm
 
 #endif

llvm/include/llvm/Support/AutoConvert.h

 //===- AutoConvert.h - Auto conversion between ASCII/EBCDIC -----*- C++ -*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 //
 // This file contains functions used for auto conversion between
 // ASCII/EBCDIC codepages specific to z/OS.
 //
 //===----------------------------------------------------------------------===//i
 
 #ifndef LLVM_SUPPORT_AUTOCONVERT_H
 #define LLVM_SUPPORT_AUTOCONVERT_H
 
+#include "llvm/Support/LLVMSupportExports.h"
+
 #ifdef __MVS__
 #define CCSID_IBM_1047 1047
 #define CCSID_UTF_8 1208
 #include <system_error>
 
 namespace llvm {
 
 /// \brief Disable the z/OS enhanced ASCII auto-conversion for the file
 /// descriptor.
-std::error_code disableAutoConversion(int FD);
+std::error_code LLVMSupport_API disableAutoConversion(int FD);
 
 /// \brief Query the z/OS enhanced ASCII auto-conversion status of a file
 /// descriptor and force the conversion if the file is not tagged with a
 /// codepage.
-std::error_code enableAutoConversion(int FD);
+std::error_code LLVMSupport_API enableAutoConversion(int FD);
 
 /// \brief Set the tag information for a file descriptor.
-std::error_code setFileTag(int FD, int CCSID, bool Text);
+std::error_code LLVMSupport_API setFileTag(int FD, int CCSID, bool Text);
 
 } // namespace llvm
 
 #endif // __MVS__
 
 #endif // LLVM_SUPPORT_AUTOCONVERT_H

llvm/include/llvm/Support/BinaryStream.h

 //===- BinaryStream.h - Base interface for a stream of data -----*- C++ -*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #ifndef LLVM_SUPPORT_BINARYSTREAM_H
 #define LLVM_SUPPORT_BINARYSTREAM_H
 
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/BitmaskEnum.h"
 #include "llvm/Support/BinaryStreamError.h"
 #include "llvm/Support/Endian.h"
 #include "llvm/Support/Error.h"
+#include "llvm/Support/LLVMSupportExports.h"
 #include <cstdint>
 
 namespace llvm {
 
 enum BinaryStreamFlags {
   BSF_None = 0,
   BSF_Write = 1,  // Stream supports writing.
   BSF_Append = 2, // Writing can occur at offset == length.
   LLVM_MARK_AS_BITMASK_ENUM(/* LargestValue = */ BSF_Append)
 };
 
 /// An interface for accessing data in a stream-like format, but which
 /// discourages copying.  Instead of specifying a buffer in which to copy
 /// data on a read, the API returns an ArrayRef to data owned by the stream's
 /// implementation.  Since implementations may not necessarily store data in a
 /// single contiguous buffer (or even in memory at all), in such cases a it may
 /// be necessary for an implementation to cache such a buffer so that it can
 /// return it.
-class BinaryStream {
+class LLVMSupport_API BinaryStream {
 public:
   virtual ~BinaryStream() = default;
 
   virtual llvm::support::endianness getEndian() const = 0;
 
   /// Given an offset into the stream and a number of bytes, attempt to
   /// read the bytes and set the output ArrayRef to point to data owned by the
   /// stream.
protected:
   }
 };
 
 /// A BinaryStream which can be read from as well as written to.  Note
 /// that writing to a BinaryStream always necessitates copying from the input
 /// buffer to the stream's backing store.  Streams are assumed to be buffered
 /// so that to be portable it is necessary to call commit() on the stream when
 /// all data has been written.
-class WritableBinaryStream : public BinaryStream {
+class LLVMSupport_API WritableBinaryStream : public BinaryStream {
 public:
   ~WritableBinaryStream() override = default;
 
   /// Attempt to write the given bytes into the stream at the desired
   /// offset. This will always necessitate a copy.  Cannot shrink or grow the
   /// stream, only writes into existing allocated space.
   virtual Error writeBytes(uint32_t Offset, ArrayRef<uint8_t> Data) = 0;
 

llvm/include/llvm/Support/BinaryStreamError.h

 //===- BinaryStreamError.h - Error extensions for Binary Streams *- C++ -*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #ifndef LLVM_SUPPORT_BINARYSTREAMERROR_H
 #define LLVM_SUPPORT_BINARYSTREAMERROR_H
 
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/Error.h"
+#include "llvm/Support/LLVMSupportExports.h"
 
 #include <string>
 
 namespace llvm {
 enum class stream_error_code {
   unspecified,
   stream_too_short,
   invalid_array_size,
   invalid_offset,
   filesystem_error
 };
 
 /// Base class for errors originating when parsing raw PDB files
-class BinaryStreamError : public ErrorInfo<BinaryStreamError> {
+class LLVMSupport_API BinaryStreamError : public ErrorInfo<BinaryStreamError> {
 public:
   static char ID;
   explicit BinaryStreamError(stream_error_code C);
   explicit BinaryStreamError(StringRef Context);
   BinaryStreamError(stream_error_code C, StringRef Context);
 
   void log(raw_ostream &OS) const override;
   std::error_code convertToErrorCode() const override;

llvm/include/llvm/Support/BinaryStreamReader.h

 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/Alignment.h"
 #include "llvm/Support/BinaryStreamArray.h"
 #include "llvm/Support/BinaryStreamRef.h"
 #include "llvm/Support/ConvertUTF.h"
 #include "llvm/Support/Endian.h"
 #include "llvm/Support/Error.h"
+#include "llvm/Support/LLVMSupportExports.h"
 #include "llvm/Support/type_traits.h"
 #include <type_traits>
 
 namespace llvm {
 
 /// Provides read only access to a subclass of `BinaryStream`.  Provides
 /// bounds checking and helpers for writing certain common data types such as
 /// null-terminated strings, integers in various flavors of endianness, etc.
 /// Can be subclassed to provide reading of custom datatypes, although no
 /// are overridable.
-class BinaryStreamReader {
+class LLVMSupport_API BinaryStreamReader {
 public:
   BinaryStreamReader() = default;
   explicit BinaryStreamReader(BinaryStreamRef Ref);
   explicit BinaryStreamReader(BinaryStream &Stream);
   explicit BinaryStreamReader(ArrayRef<uint8_t> Data,
                               llvm::support::endianness Endian);
   explicit BinaryStreamReader(StringRef Data, llvm::support::endianness Endian);
 

llvm/include/llvm/Support/BinaryStreamRef.h

 //===- BinaryStreamRef.h - A copyable reference to a stream -----*- C++ -*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #ifndef LLVM_SUPPORT_BINARYSTREAMREF_H
 #define LLVM_SUPPORT_BINARYSTREAMREF_H
 
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/Support/BinaryStream.h"
 #include "llvm/Support/BinaryStreamError.h"
 #include "llvm/Support/Error.h"
+#include "llvm/Support/LLVMSupportExports.h"
 #include <algorithm>
 #include <cstdint>
 #include <memory>
 
 namespace llvm {
 
 /// Common stuff for mutable and immutable StreamRefs.
-template <class RefType, class StreamType> class BinaryStreamRefBase {
+template <class RefType, class StreamType> class LLVMSupport_API BinaryStreamRefBase {
 protected:
   BinaryStreamRefBase() = default;
   explicit BinaryStreamRefBase(StreamType &BorrowedImpl)
       : BorrowedImpl(&BorrowedImpl), ViewOffset(0) {
     if (!(BorrowedImpl.getFlags() & BSF_Append))
       Length = BorrowedImpl.getLength();
   }
 

 
 /// BinaryStreamRef is to BinaryStream what ArrayRef is to an Array.  It
 /// provides copy-semantics and read only access to a "window" of the underlying
 /// BinaryStream. Note that BinaryStreamRef is *not* a BinaryStream.  That is to
 /// say, it does not inherit and override the methods of BinaryStream.  In
 /// general, you should not pass around pointers or references to BinaryStreams
 /// and use inheritance to achieve polymorphism.  Instead, you should pass
 /// around BinaryStreamRefs by value and achieve polymorphism that way.
-class BinaryStreamRef
+class LLVMSupport_API BinaryStreamRef
     : public BinaryStreamRefBase<BinaryStreamRef, BinaryStream> {
   friend BinaryStreamRefBase<BinaryStreamRef, BinaryStream>;
   friend class WritableBinaryStreamRef;
   BinaryStreamRef(std::shared_ptr<BinaryStream> Impl, uint32_t ViewOffset,
                   Optional<uint32_t> Length)
       : BinaryStreamRefBase(Impl, ViewOffset, Length) {}
 
 public:
struct BinarySubstreamRef {
   split(uint32_t Off) const {
     return std::make_pair(keep_front(Off), drop_front(Off));
   }
 
   uint32_t size() const { return StreamData.getLength(); }
   bool empty() const { return size() == 0; }
 };
 
-class WritableBinaryStreamRef
+class LLVMSupport_API WritableBinaryStreamRef
     : public BinaryStreamRefBase<WritableBinaryStreamRef,
                                  WritableBinaryStream> {
   friend BinaryStreamRefBase<WritableBinaryStreamRef, WritableBinaryStream>;
   WritableBinaryStreamRef(std::shared_ptr<WritableBinaryStream> Impl,
                           uint32_t ViewOffset, Optional<uint32_t> Length)
       : BinaryStreamRefBase(Impl, ViewOffset, Length) {}
 
   Error checkOffsetForWrite(uint32_t Offset, uint32_t DataSize) const {

llvm/include/llvm/Support/BinaryStreamWriter.h

 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/BinaryStreamArray.h"
 #include "llvm/Support/BinaryStreamError.h"
 #include "llvm/Support/BinaryStreamRef.h"
 #include "llvm/Support/Endian.h"
 #include "llvm/Support/Error.h"
+#include "llvm/Support/LLVMSupportExports.h"
 #include <cstdint>
 #include <type_traits>
 #include <utility>
 
 namespace llvm {
 
 /// Provides write only access to a subclass of `WritableBinaryStream`.
 /// Provides bounds checking and helpers for writing certain common data types
 /// such as null-terminated strings, integers in various flavors of endianness,
 /// etc.  Can be subclassed to provide reading and writing of custom datatypes,
 /// although no methods are overridable.
-class BinaryStreamWriter {
+class LLVMSupport_API BinaryStreamWriter {
 public:
   BinaryStreamWriter() = default;
   explicit BinaryStreamWriter(WritableBinaryStreamRef Ref);
   explicit BinaryStreamWriter(WritableBinaryStream &Stream);
   explicit BinaryStreamWriter(MutableArrayRef<uint8_t> Data,
                               llvm::support::endianness Endian);
 
   BinaryStreamWriter(const BinaryStreamWriter &Other)

llvm/include/llvm/Support/BlockFrequency.h

 //
 //===----------------------------------------------------------------------===//
 
 #ifndef LLVM_SUPPORT_BLOCKFREQUENCY_H
 #define LLVM_SUPPORT_BLOCKFREQUENCY_H
 
 #include "llvm/Support/BranchProbability.h"
 #include "llvm/Support/DataTypes.h"
+#include "llvm/Support/LLVMSupportExports.h"
 
 namespace llvm {
 
 class raw_ostream;
 
 // This class represents Block Frequency as a 64-bit value.
-class BlockFrequency {
+class LLVMSupport_API BlockFrequency {
   uint64_t Frequency;
 
 public:
   BlockFrequency(uint64_t Freq = 0) : Frequency(Freq) { }
 
   /// Returns the maximum possible frequency, the saturation value.
   static uint64_t getMaxFrequency() { return -1ULL; }
 
public:
   bool operator>=(BlockFrequency RHS) const {
     return Frequency >= RHS.Frequency;
   }
 
   bool operator==(BlockFrequency RHS) const {
     return Frequency == RHS.Frequency;
   }
 };
 
 }
 
 #endif

llvm/include/llvm/Support/COM.h

 //===- llvm/Support/COM.h ---------------------------------------*- C++ -*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 /// \file
 ///
 /// Provides a library for accessing COM functionality of the Host OS.
 ///
 //===----------------------------------------------------------------------===//
 
 #ifndef LLVM_SUPPORT_COM_H
 #define LLVM_SUPPORT_COM_H
 
+#include "llvm/Support/LLVMSupportExports.h"
+
 namespace llvm {
 namespace sys {
 
 enum class COMThreadingMode { SingleThreaded, MultiThreaded };
 
-class InitializeCOMRAII {
+class LLVMSupport_API InitializeCOMRAII {
 public:
   explicit InitializeCOMRAII(COMThreadingMode Threading,
                              bool SpeedOverMemory = false);
   ~InitializeCOMRAII();
 
 private:
   InitializeCOMRAII(const InitializeCOMRAII &) = delete;
   void operator=(const InitializeCOMRAII &) = delete;
 };
 }
 }
 
 #endif

llvm/include/llvm/Support/CachePruning.h

 // various policies.
 //
 //===----------------------------------------------------------------------===//
 
 #ifndef LLVM_SUPPORT_CACHEPRUNING_H
 #define LLVM_SUPPORT_CACHEPRUNING_H
 
 #include "llvm/ADT/Optional.h"
+#include "llvm/Support/LLVMSupportExports.h"
 #include <chrono>
 
 namespace llvm {
 
 template <typename T> class Expected;
 class StringRef;
 
 /// Policy for the pruneCache() function. A default constructed
struct CachePruningPolicy {
   uint64_t MaxSizeFiles = 1000000;
 };
 
 /// Parse the given string as a cache pruning policy. Defaults are taken from a
 /// default constructed CachePruningPolicy object.
 /// For example: "prune_interval=30s:prune_after=24h:cache_size=50%"
 /// which means a pruning interval of 30 seconds, expiration time of 24 hours
 /// and maximum cache size of 50% of available disk space.
-Expected<CachePruningPolicy> parseCachePruningPolicy(StringRef PolicyStr);
+Expected<CachePruningPolicy>
+    LLVMSupport_API parseCachePruningPolicy(StringRef PolicyStr);
 
 /// Peform pruning using the supplied policy, returns true if pruning
 /// occurred, i.e. if Policy.Interval was expired.
 ///
 /// As a safeguard against data loss if the user specifies the wrong directory
 /// as their cache directory, this function will ignore files not matching the
 /// pattern "llvmcache-*".
-bool pruneCache(StringRef Path, CachePruningPolicy Policy);
+bool LLVMSupport_API pruneCache(StringRef Path, CachePruningPolicy Policy);
 
 } // namespace llvm
 
 #endif

llvm/include/llvm/Support/Chrono.h

 //===- llvm/Support/Chrono.h - Utilities for Timing Manipulation-*- C++ -*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #ifndef LLVM_SUPPORT_CHRONO_H
 #define LLVM_SUPPORT_CHRONO_H
 
 #include "llvm/Support/Compiler.h"
 #include "llvm/Support/FormatProviders.h"
+#include "llvm/Support/LLVMSupportExports.h"
 
 #include <chrono>
 #include <ctime>
 
 namespace llvm {
 
 class raw_ostream;
 

 toTimePoint(std::time_t T, uint32_t nsec) {
   using namespace std::chrono;
   return time_point_cast<nanoseconds>(system_clock::from_time_t(T))
     + nanoseconds(nsec);
 }
 
 } // namespace sys
 
+LLVMSupport_API
 raw_ostream &operator<<(raw_ostream &OS, sys::TimePoint<> TP);
 
 /// Format provider for TimePoint<>
 ///
 /// The options string is a strftime format string, with extensions:
 ///   - %L is millis: 000-999
 ///   - %f is micros: 000000-999999
 ///   - %N is nanos: 000000000 - 999999999

llvm/include/llvm/Support/CodeGenCoverage.h

 //== llvm/Support/CodeGenCoverage.h ------------------------------*- C++ -*-==//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 /// \file This file provides rule coverage tracking for tablegen-erated CodeGen.
 //===----------------------------------------------------------------------===//
 
 #ifndef LLVM_SUPPORT_CODEGENCOVERAGE_H
 #define LLVM_SUPPORT_CODEGENCOVERAGE_H
 
 #include "llvm/ADT/BitVector.h"
+#include "llvm/Support/LLVMSupportExports.h"
 
 namespace llvm {
 class LLVMContext;
 class MemoryBuffer;
 
-class CodeGenCoverage {
+class LLVMSupport_API CodeGenCoverage {
 protected:
   BitVector RuleCoverage;
 
 public:
   using const_covered_iterator = BitVector::const_set_bits_iterator;
 
   CodeGenCoverage();
 

llvm/include/llvm/Support/CommandLine.h

 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallPtrSet.h"
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/StringMap.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/Twine.h"
 #include "llvm/ADT/iterator_range.h"
 #include "llvm/Support/ErrorHandling.h"
+#include "llvm/Support/LLVMSupportExports.h"
 #include "llvm/Support/ManagedStatic.h"
 #include "llvm/Support/raw_ostream.h"
 #include <cassert>
 #include <climits>
 #include <cstddef>
 #include <functional>
 #include <initializer_list>
 #include <string>

 //
 // If EnvVar is not nullptr, command-line options are also parsed from the
 // environment variable named by EnvVar.  Precedence is given to occurrences
 // from argv.  This precedence is currently implemented by parsing argv after
 // the environment variable, so it is only implemented correctly for options
 // that give precedence to later occurrences.  If your program supports options
 // that give precedence to earlier occurrences, you will need to extend this
 // function to support it correctly.
-bool ParseCommandLineOptions(int argc, const char *const *argv,
-                             StringRef Overview = "",
-                             raw_ostream *Errs = nullptr,
-                             const char *EnvVar = nullptr,
-                             bool LongOptionsUseDoubleDash = false);
+bool LLVMSupport_API ParseCommandLineOptions(
+    int argc, const char *const *argv, StringRef Overview = "",
+    raw_ostream *Errs = nullptr, const char *EnvVar = nullptr,
 
 // Function pointer type for printing version information.
 using VersionPrinterTy = std::function<void(raw_ostream &)>;
 
 ///===---------------------------------------------------------------------===//
 /// SetVersionPrinter - Override the default (LLVM specific) version printer
 ///                     used to print out the version when --version is given
 ///                     on the command line. This allows other systems using the
 ///                     CommandLine utilities to print their own version string.
-void SetVersionPrinter(VersionPrinterTy func);
+void LLVMSupport_API SetVersionPrinter(VersionPrinterTy func);
 
 ///===---------------------------------------------------------------------===//
 /// AddExtraVersionPrinter - Add an extra printer to use in addition to the
 ///                          default one. This can be called multiple times,
 ///                          and each time it adds a new function to the list
 ///                          which will be called after the basic LLVM version
 ///                          printing is complete. Each can then add additional
 ///                          information specific to the tool.
-void AddExtraVersionPrinter(VersionPrinterTy func);
+void LLVMSupport_API AddExtraVersionPrinter(VersionPrinterTy func);
 
 // PrintOptionValues - Print option values.
 // With -print-options print the difference between option values and defaults.
 // With -print-all-options print all option values.
 // (Currently not perfect, but best-effort.)
-void PrintOptionValues();
+void LLVMSupport_API PrintOptionValues();
 
 // Forward declaration - AddLiteralOption needs to be up here to make gcc happy.
 class Option;
 
 /// Adds a new option for parsing and provides the option it refers to.
 ///
 /// \param O pointer to the option
 /// \param Name the string name for the option to handle during parsing
 ///
 /// Literal options are used by some parsers to register special option values.
 /// This is how the PassNameParser registers pass names for opt.
-void AddLiteralOption(Option &O, StringRef Name);
+void LLVMSupport_API AddLiteralOption(Option &O, StringRef Name);
 
 //===----------------------------------------------------------------------===//
 // Flags permitted to be passed to command line arguments
 //
 
 enum NumOccurrencesFlag { // Flags for the number of occurrences allowed
   Optional = 0x00,        // Zero or One occurrence
   ZeroOrMore = 0x01,      // Zero or more occurrences allowed
enum MiscFlags {             // Miscellaneous flags to adjust argument
 
   // Default option
   DefaultOption = 0x10
 };
 
 //===----------------------------------------------------------------------===//
 // Option Category class
 //
-class OptionCategory {
+class LLVMSupport_API OptionCategory {
 private:
   StringRef const Name;
   StringRef const Description;
 
   void registerCategory();
 
 public:
   OptionCategory(StringRef const Name,
                  StringRef const Description = "")
       : Name(Name), Description(Description) {
     registerCategory();
   }
 
   StringRef getName() const { return Name; }
   StringRef getDescription() const { return Description; }
 };
 
 // The general Option Category (used as default category).
 OptionCategory &getGeneralCategory();
 
 //===----------------------------------------------------------------------===//
 // SubCommand class
 //
-class SubCommand {
+class LLVMSupport_API SubCommand {
 private:
   StringRef Name;
   StringRef Description;
 
 protected:
   void registerSubCommand();
   void unregisterSubCommand();
 
public:
   SmallVector<Option *, 4> PositionalOpts;
   SmallVector<Option *, 4> SinkOpts;
   StringMap<Option *> OptionsMap;
 
   Option *ConsumeAfterOpt = nullptr; // The ConsumeAfter option if it exists.
 };
 
 // A special subcommand representing no subcommand
-extern ManagedStatic<SubCommand> TopLevelSubCommand;
+extern ManagedStatic<SubCommand> LLVMSupport_API TopLevelSubCommand;
 
 // A special subcommand that can be used to put an option into all subcommands.
-extern ManagedStatic<SubCommand> AllSubCommands;
+extern ManagedStatic<SubCommand> LLVMSupport_API AllSubCommands;
 
 //===----------------------------------------------------------------------===//
 // Option Base class
 //
-class Option {
+class LLVMSupport_API Option {
   friend class alias;
 
   // handleOccurrences - Overriden by subclasses to handle the value passed into
   // an argument.  Should return true if there was an error processing the
   // argument and the program should exit.
   //
   virtual bool handleOccurrence(unsigned pos, StringRef ArgName,
                                 StringRef Arg) = 0;

llvm/include/llvm/Support/Compression.h

 //===-- llvm/Support/Compression.h ---Compression----------------*- C++ -*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 //
 // This file contains basic functions for compression/uncompression.
 //
 //===----------------------------------------------------------------------===//
 
 #ifndef LLVM_SUPPORT_COMPRESSION_H
 #define LLVM_SUPPORT_COMPRESSION_H
 
 #include "llvm/Support/DataTypes.h"
+#include "llvm/Support/LLVMSupportExports.h"
 
 namespace llvm {
 template <typename T> class SmallVectorImpl;
 class Error;
 class StringRef;
 
 namespace zlib {
 
 static constexpr int NoCompression = 0;
 static constexpr int BestSpeedCompression = 1;
 static constexpr int DefaultCompression = 6;
 static constexpr int BestSizeCompression = 9;
 
-bool isAvailable();
+bool LLVMSupport_API isAvailable();
 
-Error compress(StringRef InputBuffer, SmallVectorImpl<char> &CompressedBuffer,
+Error LLVMSupport_API compress(StringRef InputBuffer,
+                               SmallVectorImpl<char> &CompressedBuffer,
                                int Level = DefaultCompression);
 
-Error uncompress(StringRef InputBuffer, char *UncompressedBuffer,
+Error LLVMSupport_API uncompress(StringRef InputBuffer,
+                                 char *UncompressedBuffer,
                                  size_t &UncompressedSize);
 
-Error uncompress(StringRef InputBuffer,
+Error LLVMSupport_API uncompress(StringRef InputBuffer,
                                  SmallVectorImpl<char> &UncompressedBuffer,
                                  size_t UncompressedSize);
 
-uint32_t crc32(StringRef Buffer);
+uint32_t LLVMSupport_API crc32(StringRef Buffer);
 
 }  // End of namespace zlib
 
 } // End of namespace llvm
 
 #endif

llvm/include/llvm/Support/Error.h

 #include "llvm/ADT/Twine.h"
 #include "llvm/Config/abi-breaking.h"
 #include "llvm/Support/AlignOf.h"
 #include "llvm/Support/Compiler.h"
 #include "llvm/Support/Debug.h"
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/ErrorOr.h"
 #include "llvm/Support/Format.h"
+#include "llvm/Support/LLVMSupportExports.h"
 #include "llvm/Support/raw_ostream.h"
 #include <algorithm>
 #include <cassert>
 #include <cstdint>
 #include <cstdlib>
 #include <functional>
 #include <memory>
 #include <new>
 #include <string>
 #include <system_error>
 #include <type_traits>
 #include <utility>
 #include <vector>
 
 namespace llvm {
 
 class ErrorSuccess;
 
 /// Base class for error info classes. Do not extend this directly: Extend
 /// the ErrorInfo template subclass instead.
-class ErrorInfoBase {
+class LLVMSupport_API ErrorInfoBase {
 public:
   virtual ~ErrorInfoBase() = default;
 
   /// Print an error message to an output stream.
   virtual void log(raw_ostream &OS) const = 0;
 
   /// Return the error message as a string.
   virtual std::string message() const {

 ///
 /// class MyError : public ErrorInfo<MyError> {
 ///   ....
 /// };
 ///
 /// This class provides an implementation of the ErrorInfoBase::kind
 /// method, which is used by the Error RTTI system.
 template <typename ThisErrT, typename ParentErrT = ErrorInfoBase>
-class ErrorInfo : public ParentErrT {
+class LLVMSupport_API ErrorInfo : public ParentErrT {
 public:
   using ParentErrT::ParentErrT; // inherit constructors
 
   static const void *classID() { return &ThisErrT::ID; }
 
   const void *dynamicClassID() const override { return &ThisErrT::ID; }
 
   bool isA(const void *const ClassID) const override {

llvm/include/llvm/Support/LLVMSupportExports.h

+//===--- SupportMacros.h - ABI Macro Definitions ----------------*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef LLVM_SUPPORT_LLVMSupport_EXPORTS_H
+#define LLVM_SUPPORT_LLVMSupport_EXPORTS_H
+
+#if defined(__ELF__)
+# if defined(LLVMSupport_STATIC)
+#   define LLVMSupport_API
+# else
+#   if defined(LLVMSupport_EXPORTS)
+#     define LLVMSupport_API __attribute__((__visibility__("protected")))
+#   else
+#     define LLVMSupport_API __attribute__((__visibility__("default")))
+#   endif
+# endif
+#elif defined(__MACH__) || defined(__WASM__)
+# if defined(LLVMSupport_STATIC)
+#   define LLVMSupport_API
+# else
+#   define LLVMSupport_API __attribute__((__visibility__("default")))
+# endif
+#else
+# if defined(_DLL)
+#   if defined(LLVMSupport_EXPORTS)
+#     define LLVMSupport_API __declspec(dllexport)
+#   else
+#     define LLVMSupport_API __declspec(dllimport)
+#   endif
+# else
+#   define LLVMSupport_API
+# endif
+#endif
+
+#endif

llvm/include/llvm/Support/circular_raw_ostream.h

 //===-- llvm/Support/circular_raw_ostream.h - Buffered streams --*- C++ -*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 //
 // This file contains raw_ostream implementations for streams to do circular
 // buffering of their output.
 //
 //===----------------------------------------------------------------------===//
 
 #ifndef LLVM_SUPPORT_CIRCULAR_RAW_OSTREAM_H
 #define LLVM_SUPPORT_CIRCULAR_RAW_OSTREAM_H
 
+#include "llvm/Support/LLVMSupportExports.h"
 #include "llvm/Support/raw_ostream.h"
 
 namespace llvm {
   /// circular_raw_ostream - A raw_ostream which *can* save its data
   /// to a circular buffer, or can pass it through directly to an
   /// underlying stream if specified with a buffer of zero.
   ///
-  class circular_raw_ostream : public raw_ostream {
+  class LLVMSupport_API circular_raw_ostream : public raw_ostream {
   public:
     /// TAKE_OWNERSHIP - Tell this stream that it owns the underlying
     /// stream and is responsible for cleanup, memory management
     /// issues, etc.
     ///
     static constexpr bool TAKE_OWNERSHIP = true;
 
     /// REFERENCE_ONLY - Tell this stream it should not manage the

llvm/lib/Support/AArch64TargetParser.cpp

 using namespace llvm;
 
 static unsigned checkArchVersion(llvm::StringRef Arch) {
   if (Arch.size() >= 2 && Arch[0] == 'v' && std::isdigit(Arch[1]))
     return (Arch[1] - 48);
   return 0;
 }
 
-unsigned AArch64::getDefaultFPU(StringRef CPU, AArch64::ArchKind AK) {
+unsigned LLVMSupport_API AArch64::getDefaultFPU(StringRef CPU,
+                                                AArch64::ArchKind AK) {
   if (CPU == "generic")
     return AArch64ARCHNames[static_cast<unsigned>(AK)].DefaultFPU;
 
   return StringSwitch<unsigned>(CPU)
 #define AARCH64_CPU_NAME(NAME, ID, DEFAULT_FPU, IS_DEFAULT, DEFAULT_EXT)       \
   .Case(NAME, ARM::DEFAULT_FPU)
 #include "../../include/llvm/Support/AArch64TargetParser.def"
   .Default(ARM::FK_INVALID);
 }
 
-uint64_t AArch64::getDefaultExtensions(StringRef CPU, AArch64::ArchKind AK) {
+uint64_t LLVMSupport_API AArch64::getDefaultExtensions(StringRef CPU,
+                                                       AArch64::ArchKind AK) {
   if (CPU == "generic")
     return AArch64ARCHNames[static_cast<unsigned>(AK)].ArchBaseExtensions;
 
   return StringSwitch<uint64_t>(CPU)
 #define AARCH64_CPU_NAME(NAME, ID, DEFAULT_FPU, IS_DEFAULT, DEFAULT_EXT)       \
   .Case(NAME, AArch64ARCHNames[static_cast<unsigned>(ArchKind::ID)]            \
                       .ArchBaseExtensions |                                    \
                   DEFAULT_EXT)
 #include "../../include/llvm/Support/AArch64TargetParser.def"
   .Default(AArch64::AEK_INVALID);
 }
 
-AArch64::ArchKind AArch64::getCPUArchKind(StringRef CPU) {
+AArch64::ArchKind LLVMSupport_API AArch64::getCPUArchKind(StringRef CPU) {
   if (CPU == "generic")
     return ArchKind::ARMV8A;
 
   return StringSwitch<AArch64::ArchKind>(CPU)
 #define AARCH64_CPU_NAME(NAME, ID, DEFAULT_FPU, IS_DEFAULT, DEFAULT_EXT)       \
   .Case(NAME, ArchKind::ID)
 #include "../../include/llvm/Support/AArch64TargetParser.def"
   .Default(ArchKind::INVALID);
 }
 
-bool AArch64::getExtensionFeatures(uint64_t Extensions,
-                                   std::vector<StringRef> &Features) {
+bool LLVMSupport_API AArch64::getExtensionFeatures(
+    uint64_t Extensions, std::vector<StringRef> &Features) {
   if (Extensions == AArch64::AEK_INVALID)
     return false;
 
   if (Extensions & AEK_FP)
     Features.push_back("+fp-armv8");
   if (Extensions & AEK_SIMD)
     Features.push_back("+neon");
   if (Extensions & AEK_CRC)
bool LLVMSupport_API AArch64::getExtensionFeatures(
   if (Extensions & AArch64::AEK_SMEF64)
     Features.push_back("+sme-f64");
   if (Extensions & AArch64::AEK_SMEI64)
     Features.push_back("+sme-i64");
 
   return true;
 }
 
-bool AArch64::getArchFeatures(AArch64::ArchKind AK,
-                              std::vector<StringRef> &Features) {
+bool LLVMSupport_API AArch64::getArchFeatures(
+    AArch64::ArchKind AK, std::vector<StringRef> &Features) {
   if (AK == ArchKind::ARMV8_1A)
     Features.push_back("+v8.1a");
   if (AK == ArchKind::ARMV8_2A)
     Features.push_back("+v8.2a");
   if (AK == ArchKind::ARMV8_3A)
     Features.push_back("+v8.3a");
   if (AK == ArchKind::ARMV8_4A)
     Features.push_back("+v8.4a");
   if (AK == ArchKind::ARMV8_5A)
     Features.push_back("+v8.5a");
   if (AK == AArch64::ArchKind::ARMV8_6A)
     Features.push_back("+v8.6a");
   if (AK == AArch64::ArchKind::ARMV8_7A)
     Features.push_back("+v8.7a");
   if(AK == AArch64::ArchKind::ARMV8R)
     Features.push_back("+v8r");
 
   return AK != ArchKind::INVALID;
 }
 
-StringRef AArch64::getArchName(AArch64::ArchKind AK) {
+StringRef LLVMSupport_API AArch64::getArchName(AArch64::ArchKind AK) {
   return AArch64ARCHNames[static_cast<unsigned>(AK)].getName();
 }
 
-StringRef AArch64::getCPUAttr(AArch64::ArchKind AK) {
+StringRef LLVMSupport_API AArch64::getCPUAttr(AArch64::ArchKind AK) {
   return AArch64ARCHNames[static_cast<unsigned>(AK)].getCPUAttr();
 }
 
-StringRef AArch64::getSubArch(AArch64::ArchKind AK) {
+StringRef LLVMSupport_API AArch64::getSubArch(AArch64::ArchKind AK) {
   return AArch64ARCHNames[static_cast<unsigned>(AK)].getSubArch();
 }
 
-unsigned AArch64::getArchAttr(AArch64::ArchKind AK) {
+unsigned LLVMSupport_API AArch64::getArchAttr(AArch64::ArchKind AK) {
   return AArch64ARCHNames[static_cast<unsigned>(AK)].ArchAttr;
 }
 
-StringRef AArch64::getArchExtName(unsigned ArchExtKind) {
+StringRef LLVMSupport_API AArch64::getArchExtName(unsigned ArchExtKind) {
   for (const auto &AE : AArch64ARCHExtNames)
     if (ArchExtKind == AE.ID)
       return AE.getName();
   return StringRef();
 }
 
-StringRef AArch64::getArchExtFeature(StringRef ArchExt) {
+StringRef LLVMSupport_API AArch64::getArchExtFeature(StringRef ArchExt) {
   if (ArchExt.startswith("no")) {
     StringRef ArchExtBase(ArchExt.substr(2));
     for (const auto &AE : AArch64ARCHExtNames) {
       if (AE.NegFeature && ArchExtBase == AE.getName())
         return StringRef(AE.NegFeature);
     }
   }
 
   for (const auto &AE : AArch64ARCHExtNames)
     if (AE.Feature && ArchExt == AE.getName())
       return StringRef(AE.Feature);
   return StringRef();
 }
 
-StringRef AArch64::getDefaultCPU(StringRef Arch) {
+StringRef LLVMSupport_API AArch64::getDefaultCPU(StringRef Arch) {
   ArchKind AK = parseArch(Arch);
   if (AK == ArchKind::INVALID)
     return StringRef();
 
   // Look for multiple AKs to find the default for pair AK+Name.
   for (const auto &CPU : AArch64CPUNames)
     if (CPU.ArchID == AK && CPU.Default)
       return CPU.getName();
 
   // If we can't find a default then target the architecture instead
   return "generic";
 }
 
-void AArch64::fillValidCPUArchList(SmallVectorImpl<StringRef> &Values) {
+void LLVMSupport_API
+AArch64::fillValidCPUArchList(SmallVectorImpl<StringRef> &Values) {
   for (const auto &Arch : AArch64CPUNames) {
     if (Arch.ArchID != ArchKind::INVALID)
       Values.push_back(Arch.getName());
   }
 }
 
-bool AArch64::isX18ReservedByDefault(const Triple &TT) {
+bool LLVMSupport_API AArch64::isX18ReservedByDefault(const Triple &TT) {
   return TT.isAndroid() || TT.isOSDarwin() || TT.isOSFuchsia() ||
          TT.isOSWindows();
 }
 
 // Allows partial match, ex. "v8a" matches "armv8a".
-AArch64::ArchKind AArch64::parseArch(StringRef Arch) {
+AArch64::ArchKind LLVMSupport_API AArch64::parseArch(StringRef Arch) {
   Arch = ARM::getCanonicalArchName(Arch);
   if (checkArchVersion(Arch) < 8)
     return ArchKind::INVALID;
 
   StringRef Syn = ARM::getArchSynonym(Arch);
   for (const auto &A : AArch64ARCHNames) {
     if (A.getName().endswith(Syn))
       return A.ID;
   }
   return ArchKind::INVALID;
 }
 
-AArch64::ArchExtKind AArch64::parseArchExt(StringRef ArchExt) {
+AArch64::ArchExtKind LLVMSupport_API AArch64::parseArchExt(StringRef ArchExt) {
   for (const auto &A : AArch64ARCHExtNames) {
     if (ArchExt == A.getName())
       return static_cast<ArchExtKind>(A.ID);
   }
   return AArch64::AEK_INVALID;
 }
 
-AArch64::ArchKind AArch64::parseCPUArch(StringRef CPU) {
+AArch64::ArchKind LLVMSupport_API AArch64::parseCPUArch(StringRef CPU) {
   for (const auto &C : AArch64CPUNames) {
     if (CPU == C.getName())
       return C.ArchID;
   }
   return ArchKind::INVALID;
 }
 
 // Parse a branch protection specification, which has the form
 //   standard | none | [bti,pac-ret[+b-key,+leaf]*]
 // Returns true on success, with individual elements of the specification
 // returned in `PBP`. Returns false in error, with `Err` containing
 // an erroneous part of the spec.
-bool AArch64::parseBranchProtection(StringRef Spec, ParsedBranchProtection &PBP,
+bool LLVMSupport_API AArch64::parseBranchProtection(StringRef Spec,
+                                                    ParsedBranchProtection &PBP,
                                                     StringRef &Err) {
   PBP = {"none", "a_key", false};
   if (Spec == "none")
     return true; // defaults are ok
 
   if (Spec == "standard") {
     PBP.Scope = "non-leaf";
     PBP.BranchTargetEnforcement = true;
     return true;

llvm/lib/Support/ARMTargetParser.cpp

 
 static StringRef getHWDivSynonym(StringRef HWDiv) {
   return StringSwitch<StringRef>(HWDiv)
       .Case("thumb,arm", "arm,thumb")
       .Default(HWDiv);
 }
 
 // Allows partial match, ex. "v7a" matches "armv7a".
-ARM::ArchKind ARM::parseArch(StringRef Arch) {
+ARM::ArchKind LLVMSupport_API ARM::parseArch(StringRef Arch) {
   Arch = getCanonicalArchName(Arch);
   StringRef Syn = getArchSynonym(Arch);
   for (const auto &A : ARCHNames) {
     if (A.getName().endswith(Syn))
       return A.ID;
   }
   return ArchKind::INVALID;
 }
 
 // Version number (ex. v7 = 7).
-unsigned ARM::parseArchVersion(StringRef Arch) {
+unsigned LLVMSupport_API ARM::parseArchVersion(StringRef Arch) {
   Arch = getCanonicalArchName(Arch);
   switch (parseArch(Arch)) {
   case ArchKind::ARMV2:
   case ArchKind::ARMV2A:
     return 2;
   case ArchKind::ARMV3:
   case ArchKind::ARMV3M:
     return 3;
case ArchKind::ARMV8_1MMainline:
     return 8;
   case ArchKind::INVALID:
     return 0;
   }
   llvm_unreachable("Unhandled architecture");
 }
 
 // Profile A/R/M
-ARM::ProfileKind ARM::parseArchProfile(StringRef Arch) {
+ARM::ProfileKind LLVMSupport_API ARM::parseArchProfile(StringRef Arch) {
   Arch = getCanonicalArchName(Arch);
   switch (parseArch(Arch)) {
   case ArchKind::ARMV6M:
   case ArchKind::ARMV7M:
   case ArchKind::ARMV7EM:
   case ArchKind::ARMV8MMainline:
   case ArchKind::ARMV8MBaseline:
   case ArchKind::ARMV8_1MMainline:
ARM::ProfileKind LLVMSupport_API ARM::parseArchProfile(StringRef Arch) {
   case ArchKind::IWMMXT2:
   case ArchKind::XSCALE:
   case ArchKind::INVALID:
     return ProfileKind::INVALID;
   }
   llvm_unreachable("Unhandled architecture");
 }
 
-StringRef ARM::getArchSynonym(StringRef Arch) {
+StringRef LLVMSupport_API ARM::getArchSynonym(StringRef Arch) {
   return StringSwitch<StringRef>(Arch)
       .Case("v5", "v5t")
       .Case("v5e", "v5te")
       .Case("v6j", "v6")
       .Case("v6hl", "v6k")
       .Cases("v6m", "v6sm", "v6s-m", "v6-m")
       .Cases("v6z", "v6zk", "v6kz")
       .Cases("v7", "v7a", "v7hl", "v7l", "v7-a")
return StringSwitch<StringRef>(Arch)
       .Case("v8.7a", "v8.7-a")
       .Case("v8r", "v8-r")
       .Case("v8m.base", "v8-m.base")
       .Case("v8m.main", "v8-m.main")
       .Case("v8.1m.main", "v8.1-m.main")
       .Default(Arch);
 }
 
-bool ARM::getFPUFeatures(unsigned FPUKind, std::vector<StringRef> &Features) {
-
+bool LLVMSupport_API ARM::getFPUFeatures(unsigned FPUKind,
+                                         std::vector<StringRef> &Features) {
   if (FPUKind >= FK_LAST || FPUKind == FK_INVALID)
     return false;
 
   static const struct FPUFeatureNameInfo {
     const char *PlusName, *MinusName;
     FPUVersion MinVersion;
     FPURestriction MaxRestriction;
   } FPUFeatureInfoList[] = {
for (const auto &Info: NeonFeatureInfoList) {
     else
       Features.push_back(Info.MinusName);
   }
 
   return true;
 }
 
 // Little/Big endian
-ARM::EndianKind ARM::parseArchEndian(StringRef Arch) {
+ARM::EndianKind LLVMSupport_API ARM::parseArchEndian(StringRef Arch) {
   if (Arch.startswith("armeb") || Arch.startswith("thumbeb") ||
       Arch.startswith("aarch64_be"))
     return EndianKind::BIG;
 
   if (Arch.startswith("arm") || Arch.startswith("thumb")) {
     if (Arch.endswith("eb"))
       return EndianKind::BIG;
     else
       return EndianKind::LITTLE;
   }
 
   if (Arch.startswith("aarch64") || Arch.startswith("aarch64_32"))
     return EndianKind::LITTLE;
 
   return EndianKind::INVALID;
 }
 
 // ARM, Thumb, AArch64
-ARM::ISAKind ARM::parseArchISA(StringRef Arch) {
+ARM::ISAKind LLVMSupport_API ARM::parseArchISA(StringRef Arch) {
   return StringSwitch<ISAKind>(Arch)
       .StartsWith("aarch64", ISAKind::AARCH64)
       .StartsWith("arm64", ISAKind::AARCH64)
       .StartsWith("thumb", ISAKind::THUMB)
       .StartsWith("arm", ISAKind::ARM)
       .Default(ISAKind::INVALID);
 }
 
-unsigned ARM::parseFPU(StringRef FPU) {
+unsigned LLVMSupport_API ARM::parseFPU(StringRef FPU) {
   StringRef Syn = getFPUSynonym(FPU);
   for (const auto &F : FPUNames) {
     if (Syn == F.getName())
       return F.ID;
   }
   return FK_INVALID;
 }
 
-ARM::NeonSupportLevel ARM::getFPUNeonSupportLevel(unsigned FPUKind) {
+ARM::NeonSupportLevel LLVMSupport_API
+ARM::getFPUNeonSupportLevel(unsigned FPUKind) {
   if (FPUKind >= FK_LAST)
     return NeonSupportLevel::None;
   return FPUNames[FPUKind].NeonSupport;
 }
 
 // MArch is expected to be of the form (arm|thumb)?(eb)?(v.+)?(eb)?, but
 // (iwmmxt|xscale)(eb)? is also permitted. If the former, return
 // "v.+", if the latter, return unmodified string, minus 'eb'.
 // If invalid, return empty string.
-StringRef ARM::getCanonicalArchName(StringRef Arch) {
+StringRef LLVMSupport_API ARM::getCanonicalArchName(StringRef Arch) {
   size_t offset = StringRef::npos;
   StringRef A = Arch;
   StringRef Error = "";
 
   // Begins with "arm" / "thumb", move past it.
   if (A.startswith("arm64_32"))
     offset = 8;
   else if (A.startswith("arm64e"))
if (offset != StringRef::npos) {
     if (A.find("eb") != StringRef::npos)
       return Error;
   }
 
   // Arch will either be a 'v' name (v7a) or a marketing name (xscale).
   return A;
 }
 
-StringRef ARM::getFPUSynonym(StringRef FPU) {
+StringRef LLVMSupport_API ARM::getFPUSynonym(StringRef FPU) {
   return StringSwitch<StringRef>(FPU)
       .Cases("fpa", "fpe2", "fpe3", "maverick", "invalid") // Unsupported
       .Case("vfp2", "vfpv2")
       .Case("vfp3", "vfpv3")
       .Case("vfp4", "vfpv4")
       .Case("vfp3-d16", "vfpv3-d16")
       .Case("vfp4-d16", "vfpv4-d16")
       .Cases("fp4-sp-d16", "vfpv4-sp-d16", "fpv4-sp-d16")
       .Cases("fp4-dp-d16", "fpv4-dp-d16", "vfpv4-d16")
       .Case("fp5-sp-d16", "fpv5-sp-d16")
       .Cases("fp5-dp-d16", "fpv5-dp-d16", "fpv5-d16")
       // FIXME: Clang uses it, but it's bogus, since neon defaults to vfpv3.
       .Case("neon-vfpv3", "neon")
       .Default(FPU);
 }
 
-StringRef ARM::getFPUName(unsigned FPUKind) {
+StringRef LLVMSupport_API ARM::getFPUName(unsigned FPUKind) {
   if (FPUKind >= FK_LAST)
     return StringRef();
   return FPUNames[FPUKind].getName();
 }
 
-ARM::FPUVersion ARM::getFPUVersion(unsigned FPUKind) {
+ARM::FPUVersion LLVMSupport_API ARM::getFPUVersion(unsigned FPUKind) {
   if (FPUKind >= FK_LAST)
     return FPUVersion::NONE;
   return FPUNames[FPUKind].FPUVer;
 }
 
-ARM::FPURestriction ARM::getFPURestriction(unsigned FPUKind) {
+ARM::FPURestriction LLVMSupport_API ARM::getFPURestriction(unsigned FPUKind) {
   if (FPUKind >= FK_LAST)
     return FPURestriction::None;
   return FPUNames[FPUKind].Restriction;
 }
 
-unsigned ARM::getDefaultFPU(StringRef CPU, ARM::ArchKind AK) {
+unsigned LLVMSupport_API ARM::getDefaultFPU(StringRef CPU, ARM::ArchKind AK) {
   if (CPU == "generic")
     return ARM::ARCHNames[static_cast<unsigned>(AK)].DefaultFPU;
 
   return StringSwitch<unsigned>(CPU)
 #define ARM_CPU_NAME(NAME, ID, DEFAULT_FPU, IS_DEFAULT, DEFAULT_EXT)           \
   .Case(NAME, DEFAULT_FPU)
 #include "llvm/Support/ARMTargetParser.def"
    .Default(ARM::FK_INVALID);
 }
 
-uint64_t ARM::getDefaultExtensions(StringRef CPU, ARM::ArchKind AK) {
+uint64_t LLVMSupport_API ARM::getDefaultExtensions(StringRef CPU,
+                                                   ARM::ArchKind AK) {
   if (CPU == "generic")
     return ARM::ARCHNames[static_cast<unsigned>(AK)].ArchBaseExtensions;
 
   return StringSwitch<uint64_t>(CPU)
 #define ARM_CPU_NAME(NAME, ID, DEFAULT_FPU, IS_DEFAULT, DEFAULT_EXT)           \
   .Case(NAME,                                                                  \
         ARCHNames[static_cast<unsigned>(ArchKind::ID)].ArchBaseExtensions |    \
             DEFAULT_EXT)
 #include "llvm/Support/ARMTargetParser.def"
   .Default(ARM::AEK_INVALID);
 }
 
-bool ARM::getHWDivFeatures(uint64_t HWDivKind,
+bool LLVMSupport_API ARM::getHWDivFeatures(uint64_t HWDivKind,
                                            std::vector<StringRef> &Features) {
-
   if (HWDivKind == AEK_INVALID)
     return false;
 
   if (HWDivKind & AEK_HWDIVARM)
     Features.push_back("+hwdiv-arm");
   else
     Features.push_back("-hwdiv-arm");
 
   if (HWDivKind & AEK_HWDIVTHUMB)
     Features.push_back("+hwdiv");
   else
     Features.push_back("-hwdiv");
 
   return true;
 }
 
-bool ARM::getExtensionFeatures(uint64_t Extensions,
-                               std::vector<StringRef> &Features) {
-
+bool LLVMSupport_API ARM::getExtensionFeatures(
+    uint64_t Extensions, std::vector<StringRef> &Features) {
   if (Extensions == AEK_INVALID)
     return false;
 
   for (const auto &AE : ARCHExtNames) {
     if ((Extensions & AE.ID) == AE.ID && AE.Feature)
       Features.push_back(AE.Feature);
     else if (AE.NegFeature)
       Features.push_back(AE.NegFeature);
   }
 
   return getHWDivFeatures(Extensions, Features);
 }
 
-StringRef ARM::getArchName(ARM::ArchKind AK) {
+StringRef LLVMSupport_API ARM::getArchName(ARM::ArchKind AK) {
   return ARCHNames[static_cast<unsigned>(AK)].getName();
 }
 
-StringRef ARM::getCPUAttr(ARM::ArchKind AK) {
+StringRef LLVMSupport_API ARM::getCPUAttr(ARM::ArchKind AK) {
   return ARCHNames[static_cast<unsigned>(AK)].getCPUAttr();
 }
 
-StringRef ARM::getSubArch(ARM::ArchKind AK) {
+StringRef LLVMSupport_API ARM::getSubArch(ARM::ArchKind AK) {
   return ARCHNames[static_cast<unsigned>(AK)].getSubArch();
 }
 
-unsigned ARM::getArchAttr(ARM::ArchKind AK) {
+unsigned LLVMSupport_API ARM::getArchAttr(ARM::ArchKind AK) {
   return ARCHNames[static_cast<unsigned>(AK)].ArchAttr;
 }
 
-StringRef ARM::getArchExtName(uint64_t ArchExtKind) {
+StringRef LLVMSupport_API ARM::getArchExtName(uint64_t ArchExtKind) {
   for (const auto &AE : ARCHExtNames) {
     if (ArchExtKind == AE.ID)
       return AE.getName();
   }
   return StringRef();
 }
 
 static bool stripNegationPrefix(StringRef &Name) {
   if (Name.startswith("no")) {
     Name = Name.substr(2);
     return true;
   }
   return false;
 }
 
-StringRef ARM::getArchExtFeature(StringRef ArchExt) {
+StringRef LLVMSupport_API ARM::getArchExtFeature(StringRef ArchExt) {
   bool Negated = stripNegationPrefix(ArchExt);
   for (const auto &AE : ARCHExtNames) {
     if (AE.Feature && ArchExt == AE.getName())
       return StringRef(Negated ? AE.NegFeature : AE.Feature);
   }
 
   return StringRef();
 }
if (CandidateFPU.FPUVer == InputFPU.FPUVer &&
       return CandidateFPU.ID;
     }
   }
 
   // nothing found
   return ARM::FK_INVALID;
 }
 
-bool ARM::appendArchExtFeatures(StringRef CPU, ARM::ArchKind AK,
-                                StringRef ArchExt,
-                                std::vector<StringRef> &Features,
-                                unsigned &ArgFPUID) {
-
+bool LLVMSupport_API ARM::appendArchExtFeatures(
+    StringRef CPU, ARM::ArchKind AK, StringRef ArchExt,
+    std::vector<StringRef> &Features, unsigned &ArgFPUID) {
   size_t StartingNumFeatures = Features.size();
   const bool Negated = stripNegationPrefix(ArchExt);
   uint64_t ID = parseArchExt(ArchExt);
 
   if (ID == AEK_INVALID)
     return false;
 
   for (const auto &AE : ARCHExtNames) {
if (ArchExt == "fp.dp") {
       FPUKind = getDefaultFPU(CPU, AK);
     }
     ArgFPUID = FPUKind;
     return ARM::getFPUFeatures(FPUKind, Features);
   }
   return StartingNumFeatures != Features.size();
 }
 
-StringRef ARM::getDefaultCPU(StringRef Arch) {
+StringRef LLVMSupport_API ARM::getDefaultCPU(StringRef Arch) {
   ArchKind AK = parseArch(Arch);
   if (AK == ArchKind::INVALID)
     return StringRef();
 
   // Look for multiple AKs to find the default for pair AK+Name.
   for (const auto &CPU : CPUNames) {
     if (CPU.ArchID == AK && CPU.Default)
       return CPU.getName();
   }
 
   // If we can't find a default then target the architecture instead
   return "generic";
 }
 
-uint64_t ARM::parseHWDiv(StringRef HWDiv) {
+uint64_t LLVMSupport_API ARM::parseHWDiv(StringRef HWDiv) {
   StringRef Syn = getHWDivSynonym(HWDiv);
   for (const auto &D : HWDivNames) {
     if (Syn == D.getName())
       return D.ID;
   }
   return AEK_INVALID;
 }
 
-uint64_t ARM::parseArchExt(StringRef ArchExt) {
+uint64_t LLVMSupport_API ARM::parseArchExt(StringRef ArchExt) {
   for (const auto &A : ARCHExtNames) {
     if (ArchExt == A.getName())
       return A.ID;
   }
   return AEK_INVALID;
 }
 
-ARM::ArchKind ARM::parseCPUArch(StringRef CPU) {
+ARM::ArchKind LLVMSupport_API ARM::parseCPUArch(StringRef CPU) {
   for (const auto &C : CPUNames) {
     if (CPU == C.getName())
       return C.ArchID;
   }
   return ArchKind::INVALID;
 }
 
-void ARM::fillValidCPUArchList(SmallVectorImpl<StringRef> &Values) {
+void LLVMSupport_API
+ARM::fillValidCPUArchList(SmallVectorImpl<StringRef> &Values) {
   for (const CpuNames<ArchKind> &Arch : CPUNames) {
     if (Arch.ArchID != ArchKind::INVALID)
       Values.push_back(Arch.getName());
   }
 }
 
-StringRef ARM::computeDefaultTargetABI(const Triple &TT, StringRef CPU) {
+StringRef LLVMSupport_API ARM::computeDefaultTargetABI(const Triple &TT,
+                                                       StringRef CPU) {
   StringRef ArchName =
       CPU.empty() ? TT.getArchName() : getArchName(parseCPUArch(CPU));
 
   if (TT.isOSBinFormatMachO()) {
     if (TT.getEnvironment() == Triple::EABI ||
         TT.getOS() == Triple::UnknownOS ||
         parseArchProfile(ArchName) == ProfileKind::M)
       return "aapcs";

llvm/lib/Support/Atomic.cpp

 #include <windows.h>
 #undef MemoryFence
 #endif
 
 #if defined(__GNUC__) || (defined(__IBMCPP__) && __IBMCPP__ >= 1210)
 #define GNU_ATOMICS
 #endif
 
-void sys::MemoryFence() {
+void LLVMSupport_API sys::MemoryFence() {
 #if LLVM_HAS_ATOMICS == 0
   return;
 #else
 #  if defined(GNU_ATOMICS)
   __sync_synchronize();
 #  elif defined(_MSC_VER)
   MemoryBarrier();
 #  else
 # error No memory fence implementation for your platform!
 #  endif
 #endif
 }
 
-sys::cas_flag sys::CompareAndSwap(volatile sys::cas_flag* ptr,
+sys::cas_flag LLVMSupport_API sys::CompareAndSwap(volatile sys::cas_flag *ptr,
                                                   sys::cas_flag new_value,
                                                   sys::cas_flag old_value) {
 #if LLVM_HAS_ATOMICS == 0
   sys::cas_flag result = *ptr;
   if (result == old_value)
     *ptr = new_value;
   return result;
 #elif defined(GNU_ATOMICS)
   return __sync_val_compare_and_swap(ptr, old_value, new_value);
 #elif defined(_MSC_VER)
   return InterlockedCompareExchange(ptr, new_value, old_value);
 #else
 #  error No compare-and-swap implementation for your platform!
 #endif
 }

llvm/lib/Support/AutoConvert.cpp

 //===----------------------------------------------------------------------===//
 
 #ifdef __MVS__
 
 #include "llvm/Support/AutoConvert.h"
 #include <fcntl.h>
 #include <sys/stat.h>
 
-std::error_code llvm::disableAutoConversion(int FD) {
+std::error_code LLVMSupport_API llvm::disableAutoConversion(int FD) {
   static const struct f_cnvrt Convert = {
       SETCVTOFF,        // cvtcmd
       0,                // pccsid
       (short)FT_BINARY, // fccsid
   };
   if (fcntl(FD, F_CONTROL_CVT, &Convert) == -1)
     return std::error_code(errno, std::generic_category());
   return std::error_code();
 }
 
-std::error_code llvm::enableAutoConversion(int FD) {
+std::error_code LLVMSupport_API llvm::enableAutoConversion(int FD) {
   struct f_cnvrt Query = {
       QUERYCVT, // cvtcmd
       0,        // pccsid
       0,        // fccsid
   };
 
   if (fcntl(FD, F_CONTROL_CVT, &Query) == -1)
     return std::error_code(errno, std::generic_category());
 
   Query.cvtcmd = SETCVTALL;
   Query.pccsid =
       (FD == STDIN_FILENO || FD == STDOUT_FILENO || FD == STDERR_FILENO)
           ? 0
           : CCSID_UTF_8;
   // Assume untagged files to be IBM-1047 encoded.
   Query.fccsid = (Query.fccsid == FT_UNTAGGED) ? CCSID_IBM_1047 : Query.fccsid;
   if (fcntl(FD, F_CONTROL_CVT, &Query) == -1)
     return std::error_code(errno, std::generic_category());
   return std::error_code();
 }
 
-std::error_code llvm::setFileTag(int FD, int CCSID, bool Text) {
+std::error_code LLVMSupport_API llvm::setFileTag(int FD, int CCSID, bool Text) {
   assert((!Text || (CCSID != FT_UNTAGGED && CCSID != FT_BINARY)) &&
          "FT_UNTAGGED and FT_BINARY are not allowed for text files");
   struct file_tag Tag;
   Tag.ft_ccsid = CCSID;
   Tag.ft_txtflag = Text;
   Tag.ft_deferred = 0;
   Tag.ft_rsvflags = 0;
 
   if (fcntl(FD, F_SETTAG, &Tag) == -1)
     return std::error_code(errno, std::generic_category());
   return std::error_code();
 }
 
 #endif // __MVS__

llvm/lib/Support/CMakeLists.txt

elseif(LLVM_INTEGRATED_CRT_ALLOC MATCHES "mimalloc$")
     set(MIMALLOC_LIB "${LLVM_INTEGRATED_CRT_ALLOC}/out/msvc-x64/Release/mimalloc-static.lib")
     if(NOT EXISTS "${MIMALLOC_LIB}")
     message(FATAL_ERROR "Cannot find the mimalloc static library. To build it, first apply the patch from https://github.com/microsoft/mimalloc/issues/268 then build the Release x64 target through ${LLVM_INTEGRATED_CRT_ALLOC}\\ide\\vs2019\\mimalloc.sln")
     endif()
     set(system_libs ${system_libs} "${MIMALLOC_LIB}" "-INCLUDE:malloc")
   endif()
 endif()
 
-add_llvm_component_library(LLVMSupport
+add_llvm_component_library(LLVMSupport SHARED
   AArch64TargetParser.cpp
   ABIBreak.cpp
   ARMTargetParser.cpp
   AMDGPUMetadata.cpp
   APFixedPoint.cpp
   APFloat.cpp
   APInt.cpp
   APSInt.cpp
if(LLVM_ENABLE_ZLIB)
   set(llvm_system_libs ${llvm_system_libs} "${zlib_library}")
 endif()
 
 if(LLVM_ENABLE_TERMINFO)
   get_library_name(${TERMINFO_LIB} terminfo_library)
   set(llvm_system_libs ${llvm_system_libs} "${terminfo_library}")
 endif()
 
-set_property(TARGET LLVMSupport PROPERTY LLVM_SYSTEM_LIBS "${llvm_system_libs}")
+set_target_properties(LLVMSupport PROPERTIES
+  LLVM_SYSTEM_LIBS "${llvm_system_libs}"
+  DEFINE_SYMBOL "LLVMSupport_EXPORTS"
+  C_VISIBILITY_PRESET hidden
+  CXX_VISIBILITY_PRESET hidden
+  VISIBILITY_INLINES_HIDDEN YES)
 
 
 if(LLVM_INTEGRATED_CRT_ALLOC)
   if(LLVM_INTEGRATED_CRT_ALLOC MATCHES "snmalloc$")
     set_property(TARGET LLVMSupport PROPERTY CXX_STANDARD 17)
     add_definitions(-D_SILENCE_CXX17_ITERATOR_BASE_CLASS_DEPRECATION_WARNING)
     if ("${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang" AND
         "${CMAKE_SYSTEM_PROCESSOR}" MATCHES "x86_64")

llvm/lib/Support/CachePruning.cpp

static Expected<std::chrono::seconds> parseDuration(StringRef Duration) {
   default:
     return make_error<StringError>("'" + Duration +
                                        "' must end with one of 's', 'm' or 'h'",
                                    inconvertibleErrorCode());
   }
 }
 
 Expected<CachePruningPolicy>
-llvm::parseCachePruningPolicy(StringRef PolicyStr) {
+    LLVMSupport_API llvm::parseCachePruningPolicy(StringRef PolicyStr) {
   CachePruningPolicy Policy;
   std::pair<StringRef, StringRef> P = {"", PolicyStr};
   while (!P.second.empty()) {
     P = P.second.split(':');
 
     StringRef Key, Value;
     std::tie(Key, Value) = P.first.split('=');
     if (Key == "prune_interval") {
if (Key == "prune_interval") {
                                      inconvertibleErrorCode());
     }
   }
 
   return Policy;
 }
 
 /// Prune the cache of files that haven't been accessed in a long time.
-bool llvm::pruneCache(StringRef Path, CachePruningPolicy Policy) {
+bool LLVMSupport_API llvm::pruneCache(StringRef Path,
+                                      CachePruningPolicy Policy) {
   using namespace std::chrono;
 
   if (Path.empty())
     return false;
 
   bool isPathDir;
   if (sys::fs::is_directory(Path, isPathDir))
     return false;

llvm/lib/Support/Chrono.cpp

#if defined(_WIN32)
   int Error = ::localtime_s(&Storage, &OurTime);
   assert(!Error);
   (void)Error;
 #endif
 
   return Storage;
 }
 
-raw_ostream &operator<<(raw_ostream &OS, TimePoint<> TP) {
+LLVMSupport_API raw_ostream &operator<<(raw_ostream &OS, TimePoint<> TP) {
   struct tm LT = getStructTM(TP);
   char Buffer[sizeof("YYYY-MM-DD HH:MM:SS")];
   strftime(Buffer, sizeof(Buffer), "%Y-%m-%d %H:%M:%S", &LT);
   return OS << Buffer << '.'
             << format("%.9lu",
                       long((TP.time_since_epoch() % std::chrono::seconds(1))
                                .count()));
 }

llvm/lib/Support/Compression.cpp

static StringRef convertZlibCodeToString(int Code) {
   case Z_DATA_ERROR:
     return "zlib error: Z_DATA_ERROR";
   case Z_OK:
   default:
     llvm_unreachable("unknown or unexpected zlib status code");
   }
 }
 
-bool zlib::isAvailable() { return true; }
+bool LLVMSupport_API zlib::isAvailable() { return true; }
 
-Error zlib::compress(StringRef InputBuffer,
-                     SmallVectorImpl<char> &CompressedBuffer, int Level) {
+Error LLVMSupport_API zlib::compress(StringRef InputBuffer,
+                                     SmallVectorImpl<char> &CompressedBuffer,
+                                     int Level) {
   unsigned long CompressedSize = ::compressBound(InputBuffer.size());
   CompressedBuffer.reserve(CompressedSize);
   int Res =
       ::compress2((Bytef *)CompressedBuffer.data(), &CompressedSize,
                   (const Bytef *)InputBuffer.data(), InputBuffer.size(), Level);
   // Tell MemorySanitizer that zlib output buffer is fully initialized.
   // This avoids a false report when running LLVM with uninstrumented ZLib.
   __msan_unpoison(CompressedBuffer.data(), CompressedSize);
   CompressedBuffer.set_size(CompressedSize);
   return Res ? createError(convertZlibCodeToString(Res)) : Error::success();
 }
 
-Error zlib::uncompress(StringRef InputBuffer, char *UncompressedBuffer,
+Error LLVMSupport_API zlib::uncompress(StringRef InputBuffer,
+                                       char *UncompressedBuffer,
                                        size_t &UncompressedSize) {
   int Res =
       ::uncompress((Bytef *)UncompressedBuffer, (uLongf *)&UncompressedSize,
                    (const Bytef *)InputBuffer.data(), InputBuffer.size());
   // Tell MemorySanitizer that zlib output buffer is fully initialized.
   // This avoids a false report when running LLVM with uninstrumented ZLib.
   __msan_unpoison(UncompressedBuffer, UncompressedSize);
   return Res ? createError(convertZlibCodeToString(Res)) : Error::success();
 }
 
-Error zlib::uncompress(StringRef InputBuffer,
-                       SmallVectorImpl<char> &UncompressedBuffer,
-                       size_t UncompressedSize) {
+Error LLVMSupport_API zlib::uncompress(
+    StringRef InputBuffer, SmallVectorImpl<char> &UncompressedBuffer,
   UncompressedBuffer.reserve(UncompressedSize);
   Error E =
       uncompress(InputBuffer, UncompressedBuffer.data(), UncompressedSize);
   UncompressedBuffer.set_size(UncompressedSize);
   return E;
 }
 
-uint32_t zlib::crc32(StringRef Buffer) {
+uint32_t LLVMSupport_API zlib::crc32(StringRef Buffer) {
   return ::crc32(0, (const Bytef *)Buffer.data(), Buffer.size());
 }
 
 #else
-bool zlib::isAvailable() { return false; }
-Error zlib::compress(StringRef InputBuffer,
-                     SmallVectorImpl<char> &CompressedBuffer, int Level) {
+bool LLVMSupport_API zlib::isAvailable() { return false; }
+Error LLVMSupport_API zlib::compress(StringRef InputBuffer,
+                                     SmallVectorImpl<char> &CompressedBuffer,
+                                     int Level) {
   llvm_unreachable("zlib::compress is unavailable");
 }
-Error zlib::uncompress(StringRef InputBuffer, char *UncompressedBuffer,
+Error LLVMSupport_API zlib::uncompress(StringRef InputBuffer,
+                                       char *UncompressedBuffer,
                                        size_t &UncompressedSize) {
   llvm_unreachable("zlib::uncompress is unavailable");
 }
-Error zlib::uncompress(StringRef InputBuffer,
-                       SmallVectorImpl<char> &UncompressedBuffer,
-                       size_t UncompressedSize) {
+Error LLVMSupport_API zlib::uncompress(
+    StringRef InputBuffer, SmallVectorImpl<char> &UncompressedBuffer,
   llvm_unreachable("zlib::uncompress is unavailable");
 }
-uint32_t zlib::crc32(StringRef Buffer) {
+uint32_t LLVMSupport_API zlib::crc32(StringRef Buffer) {
   llvm_unreachable("zlib::crc32 is unavailable");
 }
 #endif