[dmd-internals] building dmd with the microsoft compiler

Rainer Schuetze r.sagitario at gmx.de
Sun Nov 13 08:13:46 PST 2011


Hi,

a few days ago, I was trying to figure out why dmd takes so long 
compiling my projects. (The usual development build time for 
VisualD+parser is about 40 seconds which starts to get annoying. With 
enabled GC it was more than a minute. Comparing this with the C++ 
project at work which is about 50 times larger, but only takes about 10 
seconds to (incrementally) build with changes to a few files, I think 
there is something wrong with the D compilation model. But this is a 
different topic.)

Activating the profiler didn't help (crashes or takes forever), so I 
pushed the dmd source through the Microsoft compiler (I'm currently 
using cl v15 that comes with VS2008). Using the Microsoft compiler has 
several advantages

- way better debug information and integration into current debuggers
- better support for instrumented/sampling profiling tools
- better dependency handling for building dmd (if used from within 
Visual Studio)
- the executable can use up to 4GB memory on Win 64-bit host, up to 3GB 
memory on Win32

The downsides are

- no 80-bit float support
- no C99 sprintf (%j, %z, %a)
- restricted structured exception handling

I have patched the compiler to use handcrafted implementations and it 
now passes the dmd test suite.

Quite a bit to my surprise, the compiler is also almost twice as fast on 
my projects as the dmc compiled dmd! The test suite runs a bit slower 
though (5% to 10%).

Is there interest in adding the patches to the dmd source? I would like 
to do some cleanup before creating a pull request.

The major changes are with respect to the 80-bit floats, because this 
also leaks into the backend. Mostly, it's replacing "long double" with 
my implementation "long_double". I've seen "d-gcc-real.h" being used if 
IN_GCC  is defined, but the defined type real_t is only referred to 
partially. I wonder whether this is still in use (by LDC/GDC?) and 
whether it ever passed the test suites?

The C99 printf functions are overloaded by inserting an include file on 
the command line, I would prefer if these would go into port.c/h, but 
these would need to be included by the backend aswell then.

I have also built a 64-bit executable of dmd building 32-bit code, but 
it does not perform aswell (somewhere between dmc and msc 32-bit versions).

Rainer



More information about the dmd-internals mailing list