[PATCH] D109192: [WIP/DNM] Support: introduce public API annotation support

Sun Sep 5 12:52:35 PDT 2021

compnerd added a comment.

In D109192#2984273 <https://reviews.llvm.org/D109192#2984273>, @jrtc27 wrote:

> In D109192#2984255 <https://reviews.llvm.org/D109192#2984255>, @compnerd wrote:
>
>> In D109192#2984252 <https://reviews.llvm.org/D109192#2984252>, @jrtc27 wrote:
>>
>>> In D109192#2984249 <https://reviews.llvm.org/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.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109192/new/

https://reviews.llvm.org/D109192