[fpc-devel] Looking for some general clarification on how exactly revision #43175 "fixes" bugtracker issue #0036139

[Florian Klämpfl]

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;
> begin
>     if v=2 then while true do ;
> end.
> 
> 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.