[libcxx-commits] [libcxx] [libc++] Optimize `std::exception_ptr` (PR #162773)

[Adrian Vogelsgesang via libcxx-commits]

================
@@ -159,34 +233,34 @@ _LIBCPP_HIDE_FROM_ABI exception_ptr make_exception_ptr(_Ep) _NOEXCEPT {
 
 #else // _LIBCPP_ABI_MICROSOFT
 
-class _LIBCPP_EXPORTED_FROM_ABI exception_ptr {
+class exception_ptr {
   _LIBCPP_DIAGNOSTIC_PUSH
   _LIBCPP_CLANG_DIAGNOSTIC_IGNORED("-Wunused-private-field")
   void* __ptr1_;
   void* __ptr2_;
   _LIBCPP_DIAGNOSTIC_POP
 
 public:
-  exception_ptr() _NOEXCEPT;
-  exception_ptr(nullptr_t) _NOEXCEPT;
-  exception_ptr(const exception_ptr& __other) _NOEXCEPT;
-  exception_ptr& operator=(const exception_ptr& __other) _NOEXCEPT;
-  exception_ptr& operator=(nullptr_t) _NOEXCEPT;
-  ~exception_ptr() _NOEXCEPT;
-  explicit operator bool() const _NOEXCEPT;
+  _LIBCPP_EXPORTED_FROM_LIB_INLINEABLE exception_ptr() _NOEXCEPT;
----------------
vogelsgesang wrote:

Full disclosure: This isn't actually my idea. It was yours, originally proposed back in April 2022. Happy to adjust it however you prefer

> IIUC these functions are supposed to be inlined, so there isn't much point in providing an external version

correct

> except for ABI of course **but we don't need to use the dylib functions**

Right, I think we can let the compiler choose freely to either use the inlined or the dylib-provided version. This means we might not need `[[gnu::inline]]` / `__attribute__((__gnu_inline__))`.

I used it primarily because you requested its usage back in April 2022 in https://reviews.llvm.org/D122536.
It provides a slight benefit that the linker has less work to do (it doesn't have to discard many duplicated definitions of the same inline function). Not sure if we consider this to be worth it, though 🤷 

> **except for ABI of course** but we don't need to use the dylib functions

How should we ensure that the functions are still emitted as part of the dylib? Currently I rely on `_LIBCPP_EXPORTED_FROM_LIB_INLINEABLE` to be marked `inline` in the headers but as non-inline in the dylib. By marking it non-inline in the dylib, I ensure that the compiler actually emits code for it. If I would mark them `inline` also in the dylib, the compiler wouldn't actually emit any code, since the functions are never called / instantiated by the dylib

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