[cfe-dev] [RFC] __attribute__((internal_linkage))

Evgenii Stepanov via cfe-dev cfe-dev at lists.llvm.org
Thu Oct 15 17:37:08 PDT 2015


Hi,

this is a proposal to add a new function attribute to Clang. The
attribute would be called "internal_linkage" (or any other name) and
it would, as the name implies, set the function linkage to "internal".

The attribute would let us apply the same behavior as of C "static"
keyword, but on C++ class methods. AFAIK, there is no way to do this
currently.

The first use case would be libc++.

To ensure ABI stability, libc++ attempts to tightly control the set of
symbols exported from libc++.so.  This is achieved with a "trick" of
marking all functions and class methods defined in the library headers
on Linux/MacOSX with::

  __attribute__((always_inline, visibility("hidden")))

All direct calls to functions marked with the always_inline attribute
are inlined and are never emitted as an external symbol
reference. Hidden visibility removes the symbol from the shared
library exports list.

This approach has a number of drawbacks.

* always_inline functions are not always inlined. Inlining is an
  optimization, and there are multiple cases when a compiler can
  decide against it.

  * Clang can sometimes emit an **unreachable**
    call to an always_inline function as an external symbol reference.
  * Inlining may be impossible between functions with incompatible
    attributes. For example, ``__attribute__((no_sanitize_address))``,
    which suppresses AddressSanitizer instrumentation in a function,
    prevents inlining of functions that do not have the same
    attribute.

* At -O0 optimization level indiscriminate inlining results in very
  large stack frames. As a consequence, removing these attributes
  speeds up libc++ test suite by 10%.

In this case, what libc++ really needs is internal linkage. Inlining
is just an undesired side effect. The always_inline attribute could be
replaced with the proposed internal_linkage attribute for all the
benefits and no drawbacks.


More information about the cfe-dev mailing list