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.
