<div dir="ltr"><div dir="ltr">On Mon, Jun 8, 2020 at 8:30 PM kinke via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Monday, 8 June 2020 at 06:14:44 UTC, Manu wrote:<br>
> D's inline today doesn't do any of those things. It doesn't <br>
> implement a mechanic that I have ever wanted or known a use for.<br>
<br>
We've had this discussion a while back. As of the latest LDC <br>
beta, `pragma(inline, true)` functions are now properly emitted <br>
into each referencing CU, and will be inlined in most cases <br>
(`alwaysinline` LLVM function attribute), even at -O0.<br></blockquote><div><br></div><div>Yes, and thank you; it's always nice that we can fix broken things in LDC.</div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In modules other than the owning one, the function 'copy' is <br>
emitted as `available_externally`, meaning that it's *only* <br>
available for inlining at the IR level, it will never make it to <br>
the assembler and object file.<br></blockquote><div><br></div><div>Yeah I always forget the proper names for all the linkage flags that symbols can have.</div><div>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.</div><div>It's a shame to have a ton of noise in a binary when it's unnecessary.</div><div>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.</div><div>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.<br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In its owning module, the function is emitted as a regular <br>
function, as a fallback for non-inlined cases (and for when <br>
people take its address etc.). Our opinions diverge wrt. whether <br>
that's a problem - to me it's clearly no big deal, as the <br>
function is a) most likely small, and b) subject to linker <br>
stripping if unreferenced.</blockquote><div><br></div><div>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.</div><div>b) linker stripped is not reliable. We are unnecessarily inviting issues in some cases, and there's just no reason for that.</div><div><br></div><div>If we're confident that link stripping is 100% reliable when a symbol is not referenced, then I have no complaint here.</div><div><br></div><div>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).</div><div>I think it's the same flag that `static` (or `inline`) in C++ specifies right?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Wrt. control of which CUs contain which functions, that's totally <br>
out of hand anyway due to the way templates are emitted.<br></blockquote><div><br></div><div>I'm not sure what you mean. Templates work correctly; template instances are only generated and emit to the calling CU.</div></div></div>