Making sure lightweight inline functions really are lightweight (was: [Bug 67] New: Imported functions are not inlined.)

[Stewart Gordon]

d-bugmail at puremagic.com wrote:
> http://d.puremagic.com/bugzilla/show_bug.cgi?id=67
<snip>

This brings me to something I've been thinking lately.

http://www.digitalmars.com/d/pretod.html

states, of replacing C preprocessor macros with such things, "The 
compiler optimizer will inline it; no efficiency is lost."

But is any compactness lost?

When compiling a module, the compiler has to decide whether to generate 
object code for every function.  If the function is small enough that 
the compiler feels it's worth inlining, _and_ the function is private, 
then indeed, the function doesn't need to exist as a function in the 
object code.  But what if the function the compiler wants to inline is 
public?

If the entire program is compiled from scratch in one run of the 
compiler, then it doesn't matter whether inlining is within or between 
modules.

But if you're not compiling the whole thing in one go, then things 
become more complicated.  Of course, the heuristic used to determine 
whether to inline a function would need to be absolute, and applied 
equally to code in the module being compiled and to code in imported 
modules.

But different compilers will have different heuristics, and so if 
different compilers have been used then there'll be problems.  Moreover, 
what if some modules have been compiled with -inline and some without? 
Either could easily happen when using libraries, including Phobos. 
There are four possibilities:

(a) the function isn't inlined either when defined or being called - 
just a normal non-inline function
(b) the function is inlined both where defined and where called - in 
which case it's just like a C #define in this respect
(c) the function is inlined when called, but there is still object code 
for the function nonetheless
(d) the compiler of the module in which it's defined wants it inline, 
therefore not generating object code for it, but whatever compiles 
modules that call the function do want it to be inline

Situation (a) or (b) is obviously the most sensible.  (c) would work, 
but the result would be code bloat.  Of course, any half-decent linker 
would do some level of dead code elimination, but there's been some 
sceptical talk around here on how good they really are.

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/8200

But (d) would cause the program not to link, and therefore would have to 
be avoided.

A consequence is that bindings for C APIs that use #defines as inline 
functions might be compromised by the need to link in a new library and 
the resulting code bloat.

A possible solution is to have the inline attribute available for if 
someone wants it, which would force the compiler to inline the function, 
while not forbidding the compiler to also inline functions as it sees 
fit....

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- 
PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.