[libcxx-commits] [PATCH] D122536: [libc++] Optimize `exception_ptr`, especially for the empty case

[Fabian Wolff via Phabricator via libcxx-commits]

fwolff marked an inline comment as done.
fwolff added a comment.

In D122536#3445811 <https://reviews.llvm.org/D122536#3445811>, @philnik wrote:

> Adding the move constructor and assignment operator isn't ABI-breaking AFAICT. IIUC the ABI breaking part of this patch is that the functions don't get generated anymore in the dylib. Using `__attribute__((__gnu_inline__))` allows us to suppress generating the functions if they're not inlined, but allows the compiler to inline the function. Now if we don't apply the attribute when building the library the functions will be emitted, but otherwise they won't. This way we have the same linkage and so on for the dylib function, but have all the optimization opportunities of an `inline` function.

Yes, of course you're right about the move constructor and assignment operator,  I had gotten this mixed up.

The GCC documentation <https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Common-Function-Attributes.html#Common-Function-Attributes> says about `gnu_inline` that

> The way to use this is to put a function definition in a header file with this attribute, and put another copy of the function, without `extern`, in a library file.

and

> In C++, this attribute does not depend on `extern` in any way, but it still requires the `inline` keyword to enable its special behavior.

So I don't understand how this is supposed to work in C++. Let's consider a small example:
`a.h`:

  #pragma once
  
  struct A {
    int foo() { return 1; }
  };

`a.cc`:

  #include "a.h"
  
  int A::foo() { return 1; }

Could you annotate this example with `gnu_inline` to illustrate your point? And, if you are going to use any `#ifdef`s, what should they check for in libc++? Thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122536