What does 'inline' mean?

[Walter Bright]

On 6/8/2020 7:09 AM, Manu wrote:
> On Mon, Jun 8, 2020 at 8:20 PM Walter Bright via Digitalmars-d 
> <digitalmars-d at puremagic.com <mailto:digitalmars-d at puremagic.com>> wrote:
> 
>     On 6/7/2020 11:14 PM, Manu wrote:
>      > I think a first part of the conversation to understand, is that since D
>     doesn't
>      > really have first-class `inline` (just a pragma, assumed to be low-level
>      > compiler control), I think most people bring their conceptual definition
>     over
>      > from C/C++, and that definition is a little odd (although it is immensely
>      > useful), but it's not like what D does.
> 
>     C/C++ inline has always been a hint to the compiler, not a command.
> 
> 
> It's not a hint at all. It's a mechanical tool; it marks symbols with internal 
> linkage, and it also doesn't emit them if it's never referenced.
> The compiler may not choose to ignore that behaviour,
The C/C++ inline semantics revolve around the mechanics of .h files because it 
doesn't have modules. These reasons are irrelevant for D.

 > it's absolutely necessary, and very important.

For .h files, sure. Why for D, though?

>     Why does it matter where it is emitted? Why would you want multiple copies of
>     the same function in the binary?
> I want zero copies if it's never called. That's very important.

Why are 0 or N copies fine, but 1 is not?


> I also want copies to appear locally when it is referenced; inline functions 
> should NOT require that you link something to get the code... that's not inline 
> at all.

Why? What problem are you solving?


>>     Why? What is the problem with the emission of one copy where it was defined?
> That's the antithesis of inline. If I wanted that, I wouldn't mark it inline.
> I don't want a binary full of code that shouldn't be there. It's very important 
> to be able to control what code is in your binaries.

I know I'm being boring, but why is it important? Also, check out -gc-sections:

https://gcc.gnu.org/onlinedocs/gnat_ugn/Compilation-options.html

Which is a general solution, not a kludge.


> If it's not referenced, it doesn't exist.

Executables (on virtual memory systems) are not loaded into memory and then run. 
They are memory-mapped into memory, and then pages are read off of disk on 
demand. Unmapped code consumes neither memory nor resources.


>>     The PR I have on this makes it an informational warning. You can choose to be
>>     notified if inlining fails.
> That's not sufficient though for all use cases. This is a different kind of 
> inline (I think it's 'force inline').

The default, and pragma(inline,true) are sufficient for all use cases except 
which ones?

> This #3 mechanic is rare, and #1/2 are overwhelmingly common. You don't want a 
> sea of warnings to apply to cases of 1/2.

You won't get a sea of warnings unless you put pragma(inline,true) on a sea of 
functions that can't be inlined.

> I think it's important to be able to distinguish #3 from the other 2 cases.

Why?


>>   At its root, inlining is an optimization, like deciding which variables go into
>>   registers.
> No, actually... it's not. It's not an 'optimisation' in any case except maaaaybe 
> #2; it's about control of the binary output and code generation.

Inlining is 100% about optimization.


> Low level control of code generation is important in native languages; that's 
> why we're here.

Optimizing things that don't matter is wasting your valuable time. Optimizing 
things that are more effectively and thoroughly done with the linker 
(-gc-sections) - it's like chipping wood with a hatchet rather than a woodchipper.