[Closed]FPC error when using O3

[Seenkao]

Hi!
Я очень надеюсь, что это просто ошибка вывода отладочной информации при флаге "-al". Когда я выставляю оптимизацию равную 3 у меня в предоставленном ниже коде, выводится ассемблерный лог (так же ещё ниже код). Это проявляется в разных версиях FPC, как в 3.2.2, так и в 3.3.1. Конечный код в отладке не показывает этого ни чего (но код программы я не просматривал, возможно там есть этот код). Выкладываю пример для FPC 3.3.1.


Google translate:
I really hope this is simply a debug output error with the "-al" flag. When I set optimization to 3 in the code below, an assembly log is output (the code is also below). This occurs in different versions of FPC, both 3.2.2 and 3.3.1. The final code in debug mode doesn't show any of this (but I haven't looked at the program source, so it's possible this code is there). I'm posting an example for FPC 3.3.1.

Code: Pascal  [Select][+][-]

1. procedure render_AddVertex6;
2. var
3.   i: {$IfDef CPU64}Int64{$Else}Integer{$EndIf};
4.   vertices: zglGLESPVertex;
5. begin
6.   RenderTextured := False;
7.   for i := 0 to 2 do                              // 0  1  2 - 2  3  0
8.   begin
9.     zglVertices[vertexSize].pointXY := renderQuad[i];
10.     inc(vertexSize);
11.   end;
12.  
13.   zglVertices[vertexSize].pointXY := renderQuad[2];
14.   inc(vertexSize);
15.  
16.   zglVertices[vertexSize].pointXY := renderQuad[3];
17.   inc(vertexSize);
18.  
19.   zglVertices[vertexSize].pointXY := renderQuad[0];
20.   inc(vertexSize);
21. end;

Code: Text  [Select][+][-]

1. .section .text.n_zgl_render_2d_$$_render_addvertex6,"ax"
2.         .balign 16,0x90
3. .globl  ZGL_RENDER_2D_$$_RENDER_ADDVERTEX6
4.         .type   ZGL_RENDER_2D_$$_RENDER_ADDVERTEX6,@function
5. ZGL_RENDER_2D_$$_RENDER_ADDVERTEX6:
6. .Lc24:
7. # [224] begin
8.         movq    U_$ZGL_OPENGL_ALL_$$_VERTEXSIZE@GOTPCREL(%rip),%rax
9.         movq    U_$ZGL_OPENGL_ALL_$$_ZGLVERTICES@GOTPCREL(%rip),%rdx
10.         movq    U_$ZGL_RENDER_2D_$$_RENDERQUAD@GOTPCREL(%rip),%rcx
11. # [225] RenderTextured := False;
12.         movq    U_$ZGL_OPENGL_ALL_$$_RENDERTEXTURED@GOTPCREL(%rip),%rsi
13.         movb    $0,(%rsi)
14. # [228] zglVertices[vertexSize].pointXY := renderQuad[i];
15.         movq    (%rdx),%rdi
16.         movq    (%rax),%rsi
17.         shlq    $4,%rsi
18.         movq    (%rcx),%r8
19.         movq    %r8,8(%rdi,%rsi)
20. # [229] inc(vertexSize);                       // starts here
21.         addq    $1,(%rax)
22.         movq    (%rdx),%rdi
23.         movq    (%rax),%rsi
24.         shlq    $4,%rsi
25.         movq    8(%rcx),%r8
26.         movq    %r8,8(%rdi,%rsi)
27.         addq    $1,(%rax)
28.         movq    (%rdx),%rdi
29.         movq    (%rax),%rsi
30.         shlq    $4,%rsi
31.         movq    16(%rcx),%r8
32.         movq    %r8,8(%rdi,%rsi)
33.         addq    $1,(%rax)
34. # [232] zglVertices[vertexSize].pointXY := renderQuad[2];
35.         movq    (%rdx),%rdi
36.         movq    (%rax),%rsi
37.         shlq    $4,%rsi
38.         movq    16(%rcx),%r8
39.         movq    %r8,8(%rdi,%rsi)
40. # [233] inc(vertexSize);
41.         addq    $1,(%rax)
42. # [235] zglVertices[vertexSize].pointXY := renderQuad[3];
43.         movq    (%rdx),%rdi
44.         movq    (%rax),%rsi
45.         shlq    $4,%rsi
46.         movq    24(%rcx),%r8
47.         movq    %r8,8(%rdi,%rsi)
48. # [236] inc(vertexSize);
49.         addq    $1,(%rax)
50. # [238] zglVertices[vertexSize].pointXY := renderQuad[0];
51.         movq    (%rdx),%rsi
52.         movq    (%rax),%rdx
53.         shlq    $4,%rdx
54.         movq    (%rcx),%rcx
55.         movq    %rcx,8(%rsi,%rdx)
56. # [239] inc(vertexSize);
57.         addq    $1,(%rax)
58. .Lc25:
59. # [240] end;
60.         ret
61. .Lc23:
62.  
63. .section .text.n_zgl_render_2d_$$_render_addvertextexture6,"ax"

[Martin_fr]

Is there an actual error? Like, does the program return the wrong result? or crash?

As for the asm, I can see that the loop was "unrolled".

That is the compiler knows the loop goes 0..2 which is 3 iterations, so it writes the code 3 times, instead of writing the loop.

[marcov]

Don't use a 64-bit loop counter unless you really have to.

[ALLIGATOR]

Don't use a 64-bit loop counter unless you really have to.

Why?

[Fred vS]

Hello.

I dont know if it could help but

Some applications compiled with optimization DFA may have problems on Windows.
DFA optimization was added in -O3 optimization type.

-O3 = O2 + CONSTPROP + DFA + USELOADMODIFYSTORE + LOOPUNROLL

If you use -O3 or -O4 it is safer to add also -OoNODFA to disable DFA.

From fpc wiki 3.0.0 about New Feature DFA optimization:
https://wiki.freepascal.org/FPC_New_Features_3.0.0

Dead store elimination

Overview: The compiler can now, to a limited extent, remove stores to local variables and parameters if these values are not used before they are overwritten.
Notes: The use of this optimization requires that data flow analysis (-Oodfa) is enabled.
It can help in particular with cleaning up instructions that have become useless due to constant propagation.
More information: -Oodfa is still a work in progress.

[Thaddy]

Don't use a 64-bit loop counter unless you really have to.

Why?

This remark is only relevant for 32 bit code.

[ALLIGATOR]

Some applications compiled with optimization DFA may have problems on Windows

Are these issues already known and described in the bug tracker? If not, do you have any sample code?

[marcov]

64-bit counters might frustrate current optimizations. As you can see it doesn't keep the loopcounter in  a register.

[Seenkao]

As for the asm, I can see that the loop was "unrolled".

Не обратил внимания. Видимо я внёс свои оптимизации, а компилятор поверх оптимизаций ещё и свои применил. "А я испугался" - думая что это баг.

Благодарю за замечание!

---------------------------------
Google translate:
Didn't pay attention. Apparently I made my own optimizations, and the compiler applied its own on top of the optimizations. "And I got scared," thinking it was a bug.

Thanks for the tip!

Don't use a 64-bit loop counter unless you really have to.

Он используется только для 64-х битного кода.

-------------------------
Google translate:
It is used only for 64-bit code. 

[Fred vS]

Some applications compiled with optimization DFA may have problems on Windows

Are these issues already known and described in the bug tracker? If not, do you have any sample code?

This issue is known with in MSEgui discussion: https://github.com/mse-org/mseide-msegui/discussions/60

I don't know if this is valid for LCL. 

[marcov]

This issue is known with in MSEgui discussion: https://github.com/mse-org/mseide-msegui/discussions/60

That is for 3.0.0.  He is using 3.3.1, that is 11 years difference. Without a testable demonstration program I wouldn't put too much stock in it.