Incremental compilation with DMD

[Walter Bright]

Tom S wrote:
> Walter Bright wrote:
>> Tom S wrote:
>>> Personally I'm of the opinion that functions should be explicitly 
>>> marked for CTFE, and this is just another reason for such. I'm using 
>>> a patched DMD with added pragma(ctfe) which instructs the compiler 
>>> not to run any codegen or generate debug info functions/aggregates 
>>> marked as such. This trick alone can slim an executable down by a 
>>> good megabyte, which sometimes is a life-saver with OPTLINK.
>>
>> If you are compiling files with -lib, and nobody calls those CTFE 
>> functions at runtime, then they should never be linked in. (Virtual 
>> functions are always linked in, as they have a reference to them even 
>> if they are never called.)
>>
>> Executables built this way shouldn't have dead functions in them.
> 
> It could be debug info, because with -g something definitely is linked 
> in whether it's -lib or not (except with -lib there's way more of it). 

The linker doesn't pull in obj modules based on symbolic debug info. You 
can find out what is pulling in a particular module by deleting it from 
the library, linking, and seeing what undefined symbol message the 
linker produces.


> With ctfe-mixin-based metaprogramming, you also end up with string 
> literals that don't seem to get optimized away by the linker.

The linker has no idea what a string literal is, or what any other 
literals are, either. It doesn't know what a type is. It doesn't know 
what language the source code was. It only knows about symbols, 
sections, and bytes of binary data. The object module format offers no 
way to mark a piece of data as a string literal.

I do think it is possible, though, for the compiler to do a better job 
of not putting unneeded literals into the obj file.