Re: [fpc-devel] Looking for some general clarification on how exactly revision #43175 "fixes" bugtracker issue #0036139
On Sun, Oct 13, 2019 at 3:43 AM Jonas Maebe wrote: > The snippet came from the compiled program. It showed that the "while > true do ;" infinite loop got removed by the peephole optimiser (as also > mentioned by Martin). That was wrong. The peephole optimiser does not > perform any dead code analyses. It's only supposed to transform code > patterns into equivalent (but hopefully faster) ones. > > Adding a "v:=2;" statement at the start of the program, which would make > the loop reachable, did not affect the generated code (i.e., the loop > was still removed). > > > Jonas > Ah, I get it now. So basically my comment to them on the tracker issue was just kind of focusing on the wrong thing. Now I know for next time, at least. Thanks! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Looking for some general clarification on how exactly revision #43175 "fixes" bugtracker issue #0036139
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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Looking for some general clarification on how exactly revision #43175 "fixes" bugtracker issue #0036139
On 2019-10-13 01:54, Ben Grasset wrote: 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. The snippet came from the compiled program. It showed that the "while true do ;" infinite loop got removed by the peephole optimiser (as also mentioned by Martin). That was wrong. The peephole optimiser does not perform any dead code analyses. It's only supposed to transform code patterns into equivalent (but hopefully faster) ones. Adding a "v:=2;" statement at the start of the program, which would make the loop reachable, did not affect the generated code (i.e., the loop was still removed). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Looking for some general clarification on how exactly revision #43175 "fixes" bugtracker issue #0036139
On 13/10/2019 01:54, Ben Grasset wrote:
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.
The fix does not appear to be about the "if v=2" part.
But about the "while constant_expression_with_no_sideeffects do
{nothing};" empty loop.
Also in the bug report the "cmpl $2" was not removed.
So the compiler detect the dead code. (caused by v <> 2 / which probably
is not the case in the users real code).
The compile does remove an empty loop.
An empty loop, with a condition that also does nothing, that is a loop
that does nothing. Except it does: It loops forever, and stops the code
after it from being executed.
---
I guess it is just an overlap, that the "if v=2" (which may be needed to
trigger the issue in a minimal example) could/should/might trigger
another optimization (which however is not actually triggered).
That at least is what I would figure from the data avail
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Looking for some general clarification on how exactly revision #43175 "fixes" bugtracker issue #0036139
On 10/12/19 7:54 PM, Ben Grasset wrote: 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. wouldn't this depend on the setting of "boolean short circuits"? if they are off/false, then the entire boolean sequence is evaluated... or have i misunderstood something? -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Looking for some general clarification on how exactly revision #43175 "fixes" bugtracker issue #0036139
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. That said, that's not really such a big deal, because it obviously still immediately determines that it shouldn't even *start* the loop and proceeds as normal. So yeah: basically, the bottom line is I don't quite see what Jonas determined to actually *be* a bug on display in that particular issue, at all. To me it demonstrated nothing but a program that blatantly did exactly what it obviously would do. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
