[libcxx-commits] [libcxx] [libc++] Introduce implicit and explicit ABI annotations (PR #193045)

[Nikolas Klauser via libcxx-commits]

philnik777 wrote:

> @ldionne / @philnik777 . Following up on the current status:
> 
> We were able to roll this change internally, with no significant regressions. We did, however:
> 
>     * disabled Clang header modules for a handful of targets that were pushed over the 2Gb space limit for SLoc (see above)
> 
>     * patched the `_LIBCPP_END_EXPLICIT_ABI_ANNOTATIONS` macro to avoid emitting ODR ABI tags (since we have been using `_LIBCPP_NO_ABI_TAG` internally, but this change makes it only partially effective).

That's great to hear!

> So, we'll be interested in measuring the (hopefully, positive) impact of removing explicit `HIDE_FROM_ABI` annotations - let us know when you plan to do this, given that LLVM release branch has been cut recently.

I think we want to wait until at least the 23.1.0 release (25th of August) to make sure there are not significant problems.

> Speaking of ODR ABI tags - I believe you still plan to make them non-optional for Clang-based compilers?

If we can get away with it, yes.

> We've experimented a bit on what would happen if we do enable them. The impact seems to be:
> 
>     * `.debug_str` increase by 2-5% (longer function names, as they now have ABI tags
> 
>     * `.strtab` increase by ~0.6% (constant strings constructed from function names)
> 
>     * increase SLoc pressure: ~30Mb added for large binaries, which end up including most of public libc++ headers, which would also put some large targets over the limit

Thanks for looking into this. I assume the increased SLoc pressure should be mitigated by removing most `_LIBCPP_HIDE_FROM_ABI`s, so I'm not too concerned about that. We'll know more once we remove them.
Could you maybe give an assessment on how severe the other regressions are? 2-5% sounds pretty bad, but I don't know whether that's actually a concern for you. I'm also not very familiar with debug info, so I'm not too sure what's actually in that section. Maybe we can look into removing ABI Tags from debug information to some extent to mitigate this. The 0.6% seem OK to me, but again, difficult to say how bad this is from the outside.

> 
> What is yet unclear is how much it will adversely affect FDO / PGO - e.g. if the profiles rely on fully-qualified function names, enabling the ODR-ABI-tags (or switching them twice a year when `_LIBCPP_VERSION` is updated) may invalidate some profiles that would be unfortunate. It may also affect performance tracking over time (e.g. how much cycles is spent in a particular function) due to a symbol name skew. Go demangle package has just [added](https://github.com/ianlancetaylor/demangle/commit/83e58baca7248962d58657affe41b3b6f27ee423) an option to strip out ABI tags during demangling that would help us mitigate that, but not all of the tools would have this option.

That is a concern I hadn't thought about so far, and I'm not sure how to address. Removing the ABI tag from e.g. the LLDB stack trace seems like a good idea, since users tend to not actually care about it. I'm not sure how well this translates to other cases though.

> @ldionne - ODR ABI tags have been available for ~4 years now, what's your take on their usefulness so far, and have you heard of any issues end-users are facing?



https://github.com/llvm/llvm-project/pull/193045