DMD backend quality (Was: Re: DIP 1031--Deprecate Brace-Style Struct Initializers--Community Review Round 1 Discussion)

[jxel]

On Tuesday, 18 February 2020 at 13:04:36 UTC, Dejan Lekic wrote:
> On Sunday, 16 February 2020 at 00:16:24 UTC, H. S. Teoh wrote:
>> ...
>> Of course, DMD is still very fast at compiling and useful for 
>> smaller utilities and script-like programs where performance 
>> isn't critical, or for running unittests for isolated modules 
>> during development due to fast turnaround times. But codegen 
>> quality is definitely not among the reasons I still use DMD.
>> ...
>
> I do not know about others, but I personally do not expect DMD 
> to be as performant as people would like it to be. As a 
> REFERENCE COMPILER I expect it to be as close to the current 
> language specification as possible. DMD does that beautifully, 
> and on top of that does a pretty good job at compiling code 
> quite fast. I can't ask for more! - If they optimize the 
> codegen to generate better code, that is fine, but not 
> essential, as I use GCC (others may prefer LDC) for release 
> builds.

The problem is that efforts are divided as a result. Work still 
has to be maintained on the backend. As someone showed there's 
multiple PR that have stagnated because no one is willing to look 
at them that modify the backend to comply with the C ABI. Bugs 
that have been open for years. Bugs that don't exist in LDC, even 
though that's basically being maintained by one person. If people 
want a fast backend, you can build a custom backend for 
performance in LLVM, a few projects have done this already. But 
honestly that's a waste of time. The slowest part of D is the 
frontend and CTFE not the backend in LDC. That's not even 
mentioning the constant out of memory problems I experience and 
have to try to optimize the compiler for with my code.