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).
Actually, I might be wrong about what the link flag is called.
I'm fairly sure C++ uses the link flag that LLVM calls "choose one".
It's in the C++ spec that all inlines collapse to the same one. We should be using the same flag.
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.