Re: [fpc-devel] Kit's ambitions!
Hi Gareth, This is the disassembly of /function GetProcessorUsed: longint; inline; /Unless you advise me otherwise, I take the absence of /function GetProcessorUsed: longint; inline; /mentioned anywhere in this screen print that /GetProcessorUsed/ is indeed inlined. And in the face of your incredulity, I need to remind you that I get all the compiler complaints about inlining unless I restrict memory operations to the local stack, as outlined in my original message. Wolf On 17/05/2018 10:42, J. Gareth Moreton wrote: Unless I'm mistaken, Wolf, you cannot inline procedures that have asm blocks appearing anywhere (this includes the entire procedure). Nevertheless, does the disassembly of your program show it to be inlined? Gareth aka. Kit ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Kit's ambitions!
From: fpc-devel On Behalf Of Wolf Sent: Friday, 18 May 2018 07:27 This is the disassembly of function GetProcessorUsed: longint;inline; Unless you advise me otherwise, I take the absence of function GetProcessorUsed: longint;inline; mentioned anywhere in this screen print that GetProcessorUsed is indeed inlined. And in the face of your incredulity, I need to remind you that I get all the compiler complaints about inlining unless I restrict memory operations to the local stack, as outlined in my original message. The line numbers mentioned in your disassembly screen shot don’t line up with the source code you’ve previously posted, and the screenshot doesn’t show enough context to say anything about this being either simply the disassembly of the GetProcessorUsed function or really a place where you called GetProcessorUsed in source code and the compiler inlined the call. But given the fact that you can see it building a stack frame, I would strongly suspect that you are simply showing the disassembly of GetProcessorUsed here instead of a call site which is calling GetProcessorUsed and has the call inlined. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Kit's ambitions!
What you've shown suggests that the routine is NOT inlined, as it's building a stack frame and the 'add' operations at the very top looks like padding (they're all zeroes in machine code) to align the procedure to a 16 byte boundary, and would crash the program if directly executed. Look at the disassembly where your function is called - the presence of CALL will tell you it is not inlined. Gareth aka. Kit ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugging Loop Unroll Optimization
In our previous episode, Mattias Gaertner said: > > ISO7185: "After a for-statement is executed, other than being left by a > > goto-statement, the > > control-variable shall be undefined" > > > > http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Declarations_and_Statements_(Delphi)#For_Statements: > > "After the for statement terminates (provided this was not forced by a > > Break or an Exit procedure), > > the value of counter is undefined." > > > > So this shall not be unrolled, but is still error prone, if Result is not > > set after the regular end of the for loop. > > To avoid misunderstandings: > The above clearly says, that using break/goto/exit is safe: Well, well, clearly. One could interpret it that it says that the for statement terminates naturally if not forced by break or exit. It doesn't say what happens with break or exit. The fact that this exception is not documented with an example makes it very ambiguous IMHO. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugging Loop Unroll Optimization
On 18.05.2018 13:28, Marco van de Voort wrote: In our previous episode, Mattias Gaertner said: ISO7185: "After a for-statement is executed, other than being left by a goto-statement, the control-variable shall be undefined" http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Declarations_and_Statements_(Delphi)#For_Statements: "After the for statement terminates (provided this was not forced by a Break or an Exit procedure), the value of counter is undefined." So this shall not be unrolled, but is still error prone, if Result is not set after the regular end of the for loop. To avoid misunderstandings: The above clearly says, that using break/goto/exit is safe: Well, well, clearly. One could interpret it that it says that the for statement terminates naturally if not forced by break or exit. It doesn't say what happens with break or exit. Sometimes I feel that FPC developers are more lawyers than programmers. The fact that this exception is not documented with an example makes it very ambiguous IMHO. Your very own documentation isn't ambiguous at all, though: https://www.freepascal.org/docs-html/ref/refsu58.html#x164-18600013.2.4 [^] Citation: "If the loop was terminated prematurely with an exception or a break statement, the loop variable retains the value it had when the loop was exited." Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugging Loop Unroll Optimization
On Fri, 18 May 2018 13:28:30 +0200 (CEST) mar...@stack.nl (Marco van de Voort) wrote: >[...] > > > "After the for statement terminates (provided this was not forced by a > > > Break or an Exit procedure), the value of counter is undefined." >[...] > Well, well, clearly. One could interpret it that it says that the for > statement terminates naturally if not forced by break or exit. It doesn't > say what happens with break or exit. If the value of counter is undefined no matter what, then you would not bother writing the exception in the brackets, wouldn't you? > The fact that this exception is not documented with an example makes it very > ambiguous IMHO. I found a dozen places in the VCL using this. For Result:=...do if ... then exit; Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugging Loop Unroll Optimization
Lawyers or not, well-defined behaviour can only be a good thing for a language. As for those code snippets in the VCL and the like, unless we want to change the rule so that the for-loop counter has a distinct value afterwards, Result should be explicitly set after the for loop (presumably people want "High + 1"). What's the easiest solution to this? Change the code or change the rule? Gareth aka. Kit On Fri 18/05/18 12:46 , Mattias Gaertner nc-gaert...@netcologne.de sent: On Fri, 18 May 2018 13:28:30 +0200 (CEST) mar...@stack.nl [1] (Marco van de Voort) wrote: >[...] > > > "After the for statement terminates (provided this was not forced by a Break or an Exit procedure), the value of counter is undefined." >[...] > Well, well, clearly. One could interpret it that it says that the for > statement terminates naturally if not forced by break or exit. It doesn't > say what happens with break or exit. If the value of counter is undefined no matter what, then you would not bother writing the exception in the brackets, wouldn't you? > The fact that this exception is not documented with an example makes it very > ambiguous IMHO. I found a dozen places in the VCL using this. For Result:=...do if ... then exit; Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org [2] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel [3]" target="_blank">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel Links: -- [1] mailto:mar...@stack.nl [2] mailto:fpc-devel@lists.freepascal.org [3] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugging Loop Unroll Optimization
Am 18.05.2018 um 14:07 schrieb J. Gareth Moreton: > What's the easiest solution to this? Change the code or change the rule? Follow consensus. There's little point in ignoring 30 years of language development, just because nobody started an ISO committee. In this case: """After a for-statement is executed, other than being left by a goto-statement, the control-variable shall be undefined""" Break/continue/exit wasn't even invented then! Borland extended this, hence the VCL samples mentioned. But that is a discussion I have wasted a lot of time on once already, no intention to do that again. -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugging Loop Unroll Optimization
> Citation: "If the loop was terminated prematurely with an exception or a > break statement, the loop variable retains the value it had when the > loop was exited." As a quick fix, not unrolling loops left with exit at least fixes this specific situation. This still leaves exceptions raised, but IIRC the handlers don't restore context anyways, we might be okay? diff --git a/compiler/optloop.pas b/compiler/optloop.pas index 46039ffc5a..dc714ea2cc 100644 --- a/compiler/optloop.pas +++ b/compiler/optloop.pas @@ -76,7 +76,7 @@ unit optloop; function checkbreakcontinue(var n:tnode; arg: pointer): foreachnoderesult; begin -if n.nodetype in [breakn,continuen] then +if n.nodetype in [breakn,continuen,exitn] then result:=fen_norecurse_true else result:=fen_false; I'll be running this on today's snapshot, see if anything else remains. -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugging Loop Unroll Optimization
That looks sensible. Sorry to waste your time on this. I'm glad it states the for-loop variable will be left undefined - that's good enough documentation for me. I wouldn't call it a quick fix... more of fixing an oversight, since I can see the trick of using Result as the for-counter being very easily overlooked. Of course, the perfect fix is only counting "exitn" if the for-loop counter is Result. One to test for later. Gareth aka. Kit On Fri 18/05/18 14:40 , Martok list...@martoks-place.de sent: > Citation: "If the loop was terminated prematurely with an exception or a > break statement, the loop variable retains the value it had when the > loop was exited." As a quick fix, not unrolling loops left with exit at least fixes this specific situation. This still leaves exceptions raised, but IIRC the handlers don't restore context anyways, we might be okay? diff --git a/compiler/optloop.pas b/compiler/optloop.pas index 46039ffc5a..dc714ea2cc 100644 --- a/compiler/optloop.pas +++ b/compiler/optloop.pas @@ -76,7 +76,7 @@ unit optloop; function checkbreakcontinue(var n:tnode; arg: pointer): foreachnoderesult; begin - if n.nodetype in [breakn,continuen] then + if n.nodetype in [breakn,continuen,exitn] then result:=fen_norecurse_true else result:=fen_false; I'll be running this on today's snapshot, see if anything else remains. -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org [1] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel [2]" target="_blank">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel Links: -- [1] mailto:fpc-devel@lists.freepascal.org [2] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugging Loop Unroll Optimization
> Sorry to waste your time on this. Don't worry, I like investigating this stuff. I don't like the rule-lawyering that usually follows ;-) > I'm glad it states the for-loop variable will be left undefined - that's > good enough documentation for me. It is *not* undefined when the loop is left with break or exit, that's the point. The ISO is not a very good reference for modern-ish Pascal. -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugging Loop Unroll Optimization
Apologies, I meant it was undefined if the loop exits normally, but retains its current value if terminated prematurely. Ah well! Admittedly I do like concrete rules, and any situations where something is undefined is explicitly stated. Hopefully we can put this one to bed now! Back to more exciting research and ventures. Gareth aka. Kit On Fri 18/05/18 15:33 , Martok list...@martoks-place.de sent: > Sorry to waste your time on this. Don't worry, I like investigating this stuff. I don't like the rule-lawyering that usually follows ;-) > I'm glad it states the for-loop variable will be left undefined - that's good enough documentation for me. It is *not* undefined when the loop is left with break or exit, that's the point. The ISO is not a very good reference for modern-ish Pascal. -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org [1] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel [2]" target="_blank">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel Links: -- [1] mailto:fpc-devel@lists.freepascal.org [2] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugging Loop Unroll Optimization
Martok schrieb am Fr., 18. Mai 2018, 15:40: > > Citation: "If the loop was terminated prematurely with an exception or a > > break statement, the loop variable retains the value it had when the > > loop was exited." > As a quick fix, not unrolling loops left with exit at least fixes this > specific > situation. This still leaves exceptions raised, but IIRC the handlers don't > restore context anyways, we might be okay? > > diff --git a/compiler/optloop.pas b/compiler/optloop.pas > index 46039ffc5a..dc714ea2cc 100644 > --- a/compiler/optloop.pas > +++ b/compiler/optloop.pas > @@ -76,7 +76,7 @@ unit optloop; > > function checkbreakcontinue(var n:tnode; arg: pointer): > foreachnoderesult; >begin > -if n.nodetype in [breakn,continuen] then > +if n.nodetype in [breakn,continuen,exitn] then >result:=fen_norecurse_true > else >result:=fen_false; > > I'll be running this on today's snapshot, see if anything else remains. > Maybe it should also check for goto and at least explicit raise statements? Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugging Loop Unroll Optimization
> It is *not* undefined when the loop is left with break or exit, > that's the point. The ISO is not a very good reference for modern- > ish Pascal. I think based on both documented and observed behaviour, the following definition would be appropriate: The for-loop variable is undefined after the loop if the loop ran to completion. It retains its last value if the loop exited in a controlled way (goto, break, exit, ?) before running to completion. The ISO standard basically listed all known "controlled" ways to exit the loop before it ran to completion. It's just that in the meantime other flow control methods have been added. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugging Loop Unroll Optimization
In our previous episode, Mattias Gaertner said: > > Well, well, clearly. One could interpret it that it says that the for > > statement terminates naturally if not forced by break or exit. It doesn't > > say what happens with break or exit. > > If the value of counter is undefined no matter what, then you would > not bother writing the exception in the brackets, wouldn't you? I would not try to interpret an ambiguous line, and look for alternate sources of info. Seems that those are there, so that is case closed, and the only possible outcome is to try to disable certain optimizations for FOR statements that have multiple exit points or adapt the optimizations. > > The fact that this exception is not documented with an example makes it very > > ambiguous IMHO. > > I found a dozen places in the VCL using this. > For Result:=...do if ... then exit; To keep in annoying detail mode: for result:=0 to 3 do if x(result) then exit(result) ...is yet another case since the exit(result) could be taken as an explicit assignment of the loopvar to an location outside the loop, after which the loopvar scope ends. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] FPC trunk compiler slower than 3.0.4
Hello, I observe that FPC trunk compiler is about 65-70% (factor 1.65-1.7) slower than FPC 3.0.4 compiler. E.g. building Lazarus IDE takes on my machine: 1:00 with FPC 3.0.4 1:40 with FPC trunk Do you observe the same? Any hints why? Is anybody worried about the speed? Is anybody working on the speed issues? The compile time increase is huge. I seem to have the same fpc.cfg and FPC/Lazarus build options. Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugging Loop Unroll Optimization
Am 18.05.2018 um 17:15 schrieb Sven Barth via fpc-devel: > Maybe it should also check for goto and at least explicit raise statements? That'd be adding goton and raisen to the check, right? For now, just checking exit seems to be enough to get rid all of the easily testable Lazarus crashes. The "Optimized IDE" profile is usable again. I'll post the patch to the bug tracker, as we seem to have decided it is not a hack ;-) -- Regards, Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugging Loop Unroll Optimization
On 18.05.2018 17:17, Marco van de Voort wrote: To keep in annoying detail mode: for result:=0 to 3 do if x(result) then exit(result) ...is yet another case since the exit(result) could be taken as an explicit assignment of the loopvar to an location outside the loop, after which the loopvar scope ends. It is a yet another case of what? AFAICS the above code throws a compiler error: Illegal assignment to for-loop variable "$result" - and that is correct because you assign a value to a loop variable within a loop. BTW. it's the same as: function Test: Integer; begin for Result := 1 to 10 do Exit(5); end; gives a compiler error as well, since you assign 5 to loop variable within a loop. The Exit; (without argument) doesn't assign anything - it should just exit the current function without touching any of the variables. Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugging Loop Unroll Optimization
On Sat, 19 May 2018 01:16:00 +1000 "Thorsten Engler" wrote: >[...] > The for-loop variable is undefined after the loop if the loop ran to > completion. It retains its last value if the loop exited in a controlled way > (goto, break, exit, ?) before running to completion. You forgot the case where the loop was not entered: for i:=2 to 1 do ; i is now undefined. Same for for i in emptyset do ; Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugging Loop Unroll Optimization
" I think based on both documented and observed behaviour, the following definition would be appropriate: The for-loop variable is undefined after the loop if the loop ran to completion. It retains its last value if the loop exited in a controlled way (goto, break, exit, ?) before running to completion. " I'm happy with that, although it might be best to simply say (goto, break etc.) since it's hard to be completely exhaustive (since there's raise and continue as well), and let's just hope that someone doesn't call a function that then performs a long jump to a completely different routine! For purposes of compiler optimisation, I would argue that, internally, 'exit' is only necessary to check if the for-loop variable is Result, but that's just nit-picking. I'm in two minds with 'raise' because it's not always easy to determine where the exception is raised (e.g. in a subroutine called by the for-loop, or triggered by an interrupt signal such as a segmentation fault), and I wouldn't call it exiting the loop in a controlled way. Gareth aka. Kit. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org [1] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel [2]" target="_blank">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel Links: -- [1] mailto:fpc-devel@lists.freepascal.org [2] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugging Loop Unroll Optimization
> -Original Message- > From: fpc-devel On Behalf > Of Mattias Gaertner > > You forgot the case where the loop was not entered: > > for i:=2 to 1 do ; > > i is now undefined. > > Same for > > for i in emptyset do ; Both are cases of "the loop run to completion". Just because "completion" resulted in zero executions of the loop contents doesn't change that. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC trunk compiler slower than 3.0.4
On 18/05/2018 17:32, Ondrej Pokorny wrote: Hello, I observe that FPC trunk compiler is about 65-70% (factor 1.65-1.7) slower than FPC 3.0.4 compiler. E.g. building Lazarus IDE takes on my machine: 1:00 with FPC 3.0.4 1:40 with FPC trunk Do you observe the same? Any hints why? Is anybody worried about the speed? Is anybody working on the speed issues? The compile time increase is huge. I seem to have the same fpc.cfg and FPC/Lazarus build options. Building the IDE with custom opts, include -gw ... 3.0.4 60 seconds trunk 67 seconds 3.1.1 [2018/04/16] not sure what revision trunk 73 seconds revision 39024 (18 May 2018) All builds were run twice, and the 2nd run taken. So OS file caching from previous builds should be similar for all of them. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugging Loop Unroll Optimization
On 05/18/2018 11:16 AM, Thorsten Engler wrote: The for-loop variable is undefined after the loop if the loop ran to completion. It retains its last value if the loop exited in a controlled way (goto, break, exit, ?) before running to completion. speaking from the peanut gallery, FWIW, i like that verbiage... it is straight forward and clear to understand... -- 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 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC trunk build failed
On 17/05/18 22:22, Dimitrios Chr. Ioannidis via fpc-devel wrote: > Hi, > > I tried to build trunk today and I got the following error : > >> aasmcpu.pas(1540,31) Error: Compilation raised exception internally >> Fatal: Compilation aborted >> An unhandled exception occurred at $004B6EEE: >> EAccessViolation: Access violation > > [snip] > > Any hint ? If it's a bug should I filled a report in Mantis ? I think that when the compiler raises an exception internally, that is always worth a bugreport. It would perhaps be helpful to find the revision which started failing by eg. going back a month or so and bisect from there on. Just my 2c... -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
