Am 13.10.19 um 01:54 schrieb Ben Grasset:
I guess this doesn't matter too much in the grand scheme of things, but I'm somewhat confused by it, so I thought I'd ask.

Specifically, the reporter of that issue, calling themselves "Alexander", used the following program as an "example" of what they called "too aggressive optimization":

program test:
var v:longword;
    if v=2 then while true do ;

To me, that just shows a while loop that will very obviously be exited immediately in all cases, because "v" is very obviously *not* equal to 2. Yet they used a (tiny) snippet of assembler from this and deemed it "incorrect", without making any attempt to clarify what they meant.

Generally speaking, I would expect any compiler that is *capable* of realizing that the while loop has zero chance of *ever being entered at all* in the first place to remove the loop from its final codegen entirely, because there's no logical reason for it to be there.

As far as I can tell, FPC is not (yet) such a compiler.

If you assign a value explicitly to v, then the if is optimized. If you pass -Oodeadstore, also this assignment to v will be gone (-Oodeadstore is not 100 % reliable though, this is why it is not enabled by default).

Const. propagation in FPC does indeed not take care of the implicit zero value of v: simply because nobody bothered yet as it is not a real world scenario. Actually, supporting this will slow down compilation (very little obviously, but small things add up) and the effect in real world programs is most likely zero. It is just a stunt for primitive benchmarks.
fpc-devel maillist  -

Reply via email to