
Delete an inline function, save 794 kB - nikbackm
https://randomascii.wordpress.com/2017/01/22/delete-an-inline-function-save-794-kb/
======
ot
Another (obvious) optimization is to make functions that _have to be inline_
smaller. For example, std::string is used ubiquitously in C++ programs; this
change shaved a few MBs of .text from a bunch of large services at FB:
[https://github.com/facebook/folly/commit/be4c6d6b3e21914df8a...](https://github.com/facebook/folly/commit/be4c6d6b3e21914df8a0207ef4f716a09a648745)
.

~~~
minimax
That is a smart optimization but it does make you wonder why were they using a
size_t to hold the category (only 3 possible values) in the first place...

~~~
ot
You should check out how SSO (small string optimization) is implemented.
size_t is actually the natural choice, because it is shared with the capacity
(or with part of the string in the small case).

~~~
minimax
Ah I see. In size() and c_str(), strictly speaking it's not the category
constants that become 8 byte immediates but rather the category mask. Since
the category constants and masks are all compile time constants I wonder if a
smarter compiler could have performed this optimization for you.

~~~
ot
Exactly. And yes, a "sufficiently smart compiler" [1] could have discovered
the optimization, the old and new methods are semantically equivalent. It
would be interesting to test a superoptimizer on this, but I suspect it
wouldn't go very far because superoptimizers usually operate at the basic
block level (this has a branch) and optimize for number of instructions, not
bytes.

[1]
[http://wiki.c2.com/?SufficientlySmartCompiler](http://wiki.c2.com/?SufficientlySmartCompiler)

------
dzdt
With all the work on compilers and programming languages, doesn't it seem like
linker and loader technology is ripe for a major overhaul?

This kind of "chaos theory" linker crap is ridiculous.

~~~
valarauca1

        With all the work on compilers and programming languages, 
        doesn't it seem like linker and loader technology is ripe 
        for a major overhaul?
    

Loaders?

Not really that just puts _text_ (raw executable machine code, and binary
data) at certain locations in memory and updates some other _text_ to ensure
branches/functions point to the right location. This isn't rocket science it
works well. All in all loaders are very fast.

Linkers?

I would like to think so. It is just a damn complex problem. The real issue
here is legacy support. Object files were a _hack_ to make compilers faster,
use less resources, and give old school incremental-recompilation.

To make linkers faster, better, etc. one really needs to move away from opaque
object files. I like what the LLVM is doing with LTO but this _kind of_
assumes you have all the rs/c/cpp files your compiling so you can see
everything in llvm-ir format.

The real issue is build tools.

Modern C/C++ have a high level tool orchestrate compiling/moving object
files/linking object files. In some total you need half a dozen different
programs to do all these task (cc, cp, rm, make, sed/awk, ln). Each tool has
no clue what everything else is doing.

You need to have that context for the linker to do it's job better. But now
the linker has to do the job of all those tools :|

~~~
dfox
What strikes me as weird is that I know of exactly one compiler system that
got the incrementally compiled modules problem (almost) right and at the same
time is AOT compiler without huge runtime: Turbo Pascal. The intermediate
files contained both compiler readable definitions as well as object code, the
linker was able to link only the required parts without resorting to hacks
such as having each function in separate source file (see glibc) and the
toolchain was able to generate missing intermediate files even without having
to explicitly name them on command line. FPC implements the same mechanism by
splitting the compiler metadata and object file into separate on-disk files,
which seems like good compromise.

The problem with such approach is that the compiler frontends have to know
about each other and produce/consume compatible metadata. For C (and Fortran
and...) you an get away without sharing any metadata between separate
compilation units and when you cannot (constants, structure layouts) CPP is
workable and simple solution, this ignores the problem of inline functions
defined in headers, but there is not that much C code that does that.

~~~
valarauca1

         What strikes me as weird is that I know of exactly one 
         compiler system that got it right (...) Turbo Pascal.
    

Long Live Turbo Pascal.

    
    
         when you cannot (...) CPP
    

I really see no way forward to be able to modernize CPP build systems. CPP has
invented it's own paradigm for how a build system should work. Unless square 1
is "support CPP" making something support cpp is almost impossible.

~~~
dfox
cpp(1) is not where the paradigm stems from, the same paradigm was there
before and was there even before C itself. The whole idea of preprocessor
stems from assembly programming and the idea that having one file with lines
like "PORTB .equ 0x17" and reusing it is useful, in the same spirit the way
how ld(1) works was/is useful for assembly programming (you can jump
arbitrarily between notionally different functions, and in fact GCC is
perfectly capable of generating object files that do that from C/C++ code). On
the other hand, cpp(1) is useful for more things than just C/C++, there are
even programs which read their configuration by means of popen("cpp
/etc/foo").

And as for supporting ld(1) and unix toolchain in general, see my remark above
about how FPC works, IIRC MSVC compiller does something similar for C++,
albeit in more limited manner (stdaux.h and such stuff).

------
JoeAltmaier
tl;dr: modules using inline fns (even library fns like log2f) generate a
static version too; such modules can be linked in if those fns are used
_anywhere else_ even if those modules are not needed themselves.

~~~
brucedawson
Prior to VC++ 2013 the VC++ compiler would generate non-inline versions of all
inline functions it saw, even if they weren't used. Even now the option to
strip out these unreferenced inline functions (/Zc:inline) is off by default,
because it breaks a few non-conforming programs.

So, at least VC++ isn't generating these non-inline versions as aggressively
as it used to.

------
sklegg
> 2017

> still using compiled languages

/s

