Cryptic bug for DMD v2.087.x

[Nicholas Wilson]

On Monday, 12 August 2019 at 11:27:13 UTC, Peter Jacobs wrote:
> Nicholas,
> Not a silly question.  Yes, the run time is dominated by 
> crunching numbers but most of the core of the code is @nogc and 
> we find that there is little run-time difference between DMD64 
> and LDC generated executables.

That _is_ odd. usually LDC and GDC will run circles around DMD, 
especially with LTO/PGO. Doubly so for loop/math heavy stuff like 
cfd, where the code gets vectorised and unrolled very 
aggressively.

>  It turns out that, for the complex-numbers plus optimized 
> flavour of the code, we need to use the ldc compiler because of 
> another (longer term) bug.  I thought that I would report the 
> recent change in compiler behaviour while it was fresh.  For 
> development runs, which is mostly what I do, I generally find 
> the debug build and profiling provided by dmd to be convenient.

Fair enough.

> The other members of our CFD group who do large parallel 
> calculations mainly build with ldmd2.

makes sense.

> As for the 80-bit FP nature of the problem, I don't 
> deliberately use 80-bit variables.  Is there a way to easily 
> identify where I force the use of 80-bit variables upon the 
> compiler?  I expect that operations with temporary results that 
> stay within the floating-point registers will probably use 
> 80-bit values but I cannot think of any places where I have 
> wanted to retain 80-bits when storing data in my variables.
>
> Peter J.

They crop up in DMD's intrinsics for transcendentals which the 
standard library uses for non CTFE. I've tried to kill off in the 
past but without success. LDC defers to LLVM, which does things 
sensibly. There isn't a `-vreal` switch though its probably not 
too hard to implement.