What does 'inline' mean?

[Manu]

On Mon, Jun 8, 2020 at 8:30 PM kinke via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On Monday, 8 June 2020 at 06:14:44 UTC, Manu wrote:
> > D's inline today doesn't do any of those things. It doesn't
> > implement a mechanic that I have ever wanted or known a use for.
>
> We've had this discussion a while back. As of the latest LDC
> beta, `pragma(inline, true)` functions are now properly emitted
> into each referencing CU, and will be inlined in most cases
> (`alwaysinline` LLVM function attribute), even at -O0.
>

Yes, and thank you; it's always nice that we can fix broken things in LDC.
But I think for inline it's actually quite important that the spec is
useful, and that all compilers do the same thing; otherwise DMD experiences
link errors that LDC properly avoids.

In modules other than the owning one, the function 'copy' is
> emitted as `available_externally`, meaning that it's *only*
> available for inlining at the IR level, it will never make it to
> the assembler and object file.
>

Yeah I always forget the proper names for all the linkage flags that
symbols can have.
This approach is fine from a linkage point of view (there shouldn't be
errors), but I'd really like to not see the symbol in the owning module if
it's never called locally.
It's a shame to have a ton of noise in a binary when it's unnecessary.
Most D software is full of bloaty junk, but in the cases where I care about
this, it's actually a very tightly controlled binary ecosystem, which binds
between multiple languages, and only exposes necessary stuff at the ABI
boundary.
I've also seen cases where the function is not referenced in the owning
module, but it does not get stripped by the linker for whatever reason, and
then if the inline function has a call to an extern symbol that you don't
link, you'll get link errors, even though there's no calls.
By emitting it even when it's never been referenced, we're just inviting
link errors and inconsistent behaviour between different linkers. We can
trivially avoid that risk.

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?

Wrt. control of which CUs contain which functions, that's totally
> out of hand anyway due to the way templates are emitted.
>

I'm not sure what you mean. Templates work correctly; template instances
are only generated and emit to the calling CU.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20200609/715621e6/attachment.htm>