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

[Eric Fiselier via cfe-dev]

Dropping howard.hinnant at apple.com for Howard's correct email.

On Thu, Oct 15, 2015 at 7:55 PM, Eric Fiselier <eric at efcs.ca> wrote:

> Hi Evgenii,
>
> Thanks for working on this. We could really use a better approach.
>
> > To ensure ABI stability, libc++ attempts to tightly control the set of symbols
> exported from libc++.so.
>
> I think this is a simplification (but correct me if I'm wrong). libc++ can
> manage the symbols exported
> from libc++.so only using __attribute__((visibility("hidden"))).
> __always_inline__ is used to try and prevent
> symbols from being emitted in user code, not libc++.so.
>
> > 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%.
>
> This has always bothered me. I wonder if always-inline also
> messes with tooling which expect the code was compiled at "-O0".
> I'm thinking of gcov as an example.
>
> Evgenii, I have some questions:
>
> 1. What would happen if the user attempts to take the address of a
> function marked
> `__attribute__((internal_linkage))`? Wouldn't this case required external
> linkage?
> For libc++ it's sufficient if it causes a compile error because users
> aren't allowed
> to take the address of functions in the standard library.
>
> 2. It would be great if we could apply the attribute to a namespace, that
> in turn applies it to
>    all of the symbols within. Would this be possible?
>
> /Eric
>
>
>
> On Thu, Oct 15, 2015 at 6:37 PM, Evgenii Stepanov <
> eugeni.stepanov at gmail.com> wrote:
>
>> 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.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151015/7fb203ec/attachment.html>