Getting ready for 2.061

[David Nadlinger]

On Saturday, 22 December 2012 at 12:15:38 UTC, Russel Winder 
wrote:
> Interesting (or not)
> side observation: LDC generally creates faster executables than 
> DMD,
> except in one or two cases that I have.

If you ever have time to do some quick profiling, could you 
please try to figure out why the LDC-generated executable is 
slower – or if the code you are working on is open source, put 
some instructions together on how to run the benchmark(s)? The 
LLVM backend really shouldn't produce slower code than DMD in 
just about any situation, so most likely we are doing something 
stupid in LDC.

I'm really interested in this, because apart from target platform 
support (druntime/ARM is still not there yet, though) and some 
very few DMD-specific bugs such as the one you seem to hit, there 
is little reason to use LDC other than for the its code 
generation.

Oh, and if you get around to doing this before the next LDC 
release, could you please try it on a Git master build, and if 
you are on a 32 bit system, ideally use LLVM 3.2+? We had to 
disable optimizations on earlier LLVM versions for x86 builds of 
druntime due to a LLVM codegen bug only fixed in 3.2, and the 
GC-to-stack-promotion pass now activated in master should catch a 
few cases where we do stupid things like allocating array 
manifest constants on every entry into function, even if they 
were only used for meta-programming.

There is still a single known issue which can drastically affect 
GC performance, though: 
https://github.com/ldc-developers/ldc/issues/233. There is an 
easy fix, but it completely breaks shared libraries (but given 
that those don't work reliably anyway, I think I'll just go with 
it for the time being…)

David