What does 'inline' mean?

kinke noone at nowhere.com
Thu Jun 11 17:39:41 UTC 2020


On Monday, 8 June 2020 at 14:22:50 UTC, Manu wrote:
> On Mon, Jun 8, 2020 at 8:30 PM kinke via Digitalmars-d <
>> In its owning module, the function is emitted as a regular
>> function, as a fallback for non-inlined cases (and for when 
>> people take its address etc.). Our opinions diverge wrt. 
>> whether that's a problem - to me it's clearly no big deal, as 
>> the function is a) most likely small, and b) subject to linker 
>> stripping if unreferenced.
>
>
> a) most likely small, but still not nothing; the symbol table 
> is public ABI
> material, and in some projects I've worked on, the symbol table 
> is
> carefully curated.
> b) linker stripped is not reliable. We are unnecessarily 
> inviting issues in
> some cases, and there's just no reason for that.
>
> If we're confident that link stripping is 100% reliable when a 
> symbol is not referenced, then I have no complaint here.
>
> Can you show what case a hard-symbol in the owning CU solves? 
> Non-inlined
> cases will still find it locally if it has internal linkage (or 
> whatever
> that link flag is called).
> I think it's the same flag that `static` (or `inline`) in C++ 
> specifies
> right?

Internal linkage (C(++) static), AFAIK, means that you may end up 
with multiple identical functions in the final linked binary. 
Some linkers may be able to still fold them, such as the MS 
linker and lld with /OPT:ICF (identical COMDAT folding).

Linkonce_odr linkage (C++ templates and `inline` functions) on 
the other hand means that you end up with either 0 or 1 function 
in the final binary, even when multiple object files define it; 
AFAIK, without having to rely on /OPT:REF or --gc-sections etc. 
At least for LLVM, linkonce_odr additionally means that the 
definition is discarded early if unused and might not make it to 
the object file at all.

Weak_odr linkage (current D templates) is similar to linkonce_odr 
but not 'officially' discardable (if unreferenced) for the final 
binary (and thus always making it to the object file). This can 
be overridden by /OPT:REF and --gc-sections etc., the success of 
which also depends on symbol visibility and/or --export-dynamic 
etc.


More information about the Digitalmars-d mailing list