Incremental compilation with DMD

[Tom S]

Walter Bright wrote:
> 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.

I wasn't implying that.


> 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.

I tested it on a single-module program before posting. Basically void 
main() {} and a single unused function void fooBar {}. With -g, 
something with the function's mangled name ended up in the executable. 
Without -g, the linker was able to remove the function (I ran a diff on 
a compiled file with the function removed altogether from source).


>> 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 wasn't implying that either and I'm well aware of it :S I thought it 
would be easier for everyone to understand than any blurbing about 
LEDATA/LED386 and static data segments.


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

That would be nice and perhaps might make OPTLINK crash less.


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode