Compiler: Size of generated executable file

[Walter Bright]

bearophile wrote:
> Sean Kelly:
>> I guess this is different than --gc-sections or whatever the ld
>> flag is?<
> 
> I don't remember what --gc-sections is, but I guess it's something
> different. The code removed during the LTO is for example unreachable
> functions, or functions/methods, that once inlined are called from
> nowhere else, unused constants, etc. Here you can see an example on C
> code (in D1 it's the same): 
> http://llvm.org/docs/LinkTimeOptimization.html Anyway, currently the
> LDC project is mostly sleeping.

Optlink does this too. It's oooollldd technology, been around since the 
80's. Consider the following program:

========================
int x;
void foo() { x++; }
int main() { return 0; }
========================

Compile it,

     dmd foo -L/map

and let's have a look at the object file (cut down for brevity):

========================
_D3foo3fooFZv   comdat
         assume  CS:_D3foo3fooFZv
                 mov     EAX,FS:__tls_array
                 mov     ECX,[EAX]
                 inc     dword ptr _D3foo1xi[ECX]
                 ret
_D3foo3fooFZv   ends
__Dmain comdat
         assume  CS:__Dmain
                 xor     EAX,EAX
                 ret
__Dmain ends
=========================

Now look at the map file with:

     grep foo foo.map

=========================
  0004:00000090       _D3foo12__ModuleInfoZ      00434090
  0003:00000004       _D3foo1xi                  00433004
  0003:00000004       _D3foo1xi                  00433004
  0004:00000090       _D3foo12__ModuleInfoZ      00434090
=========================

and we see that _D3foo3fooFZv does not appear in it. Optlink does this 
by default, you don't even have to throw a switch.