Overly clever constant folding

[deadalnix]

On Saturday, 10 December 2022 at 21:36:42 UTC, John Colvin wrote:
> Is this the "constant fold at higher precision and break all 
> your IEEE-754 expectations" madness again? Or something else?
>
> [...]

It really isn't. The problem stem from DMD using real precision 
when doing constant folding in the frontend, without rounding 
intermediary results. This behavior is not correct according to 
floating points, and means that any change in the way DMD 
constant fold in the frontend can change the semantic of the 
program.

While fixing this after a bug report is dully provided, is 
certainly a path forward, it would be missing the larger point: 
why is constant folding done there to begin with? This leads to 
all kind of strange and bizarre behaviors, such as making it very 
unpredictable when the compiler will yell at you about 
unreachable code.

Today's optimizer are shockingly good at doing this kind of 
transformations, and duplicating the logic between the optimizer 
and the front will *in the ideal case* multiply the umber of bugs 
by two, but in practice much more, because DMD is not and 
probably never will be battle tested to the degree LLVM or GCC 
are.

And if take a step back to the step back, we notice that this is 
where the "fill a bug report" approach fails. While this approach 
will certainly help fix this one specific issue, it doesn't 
address the larger point that make this kind of issue - and many 
others - more likely to occur. In fact, piling up more and more 
complex logic under the wrong structure makes it harder and 
harder to replace with a newer, more sensible one.

Anyways, we need to stop constant folding in the front end, and, 
while we are at it, we should also stop inlining in there.