Hello, I have observed something I do not understand. The following is a series of for-loops and the generated code looks strange to me. There always appears an inc followed by a dec and what is even more bizarre is the code in between it: sometimes it inserts a mov %esi,%esi, sometimes lea 0x0(%esi),%esi and sometimes just a simple nop, although the loop looks exactly the same.

This is FPC from the 2_6 branch (RC1), platform is linux i386 and the following was produced when compiling my program with -O2 and no further optimizations. If I use -O3 and -Or then it still looks the same and if I also use -Os then it will remove the mov %esi,%esi, the lea and the nop but the inc and dec won't go away:

Is there a reason why this must be compiled like this? Is it intentionally trying to waste time because of pipelining or something or is this a bug or a design flaw.?

  for I := 255 downto 128 do MS1BTABLE[I] := 7;

0x80662b0 mov $0xff,%eax
0x80662b5 inc %eax
0x80662b6 mov %esi,%esi
0x80662b8 dec %eax
0x80662b9 movl $0x7,0x8097140(,%eax,4)
0x80662c4 cmp $0x80,%eax
0x80662c9 jg 0x80662b8 <INITLOOKUPTABLES+8>

  for I := 127 downto  64 do MS1BTABLE[I] := 6;

0x80662cb mov $0x7f,%eax
0x80662d0 inc %eax
0x80662d1 lea 0x0(%esi),%esi
0x80662d4 dec %eax
0x80662d5 movl $0x6,0x8097140(,%eax,4)
0x80662e0 cmp $0x40,%eax
0x80662e3 jg 0x80662d4 <INITLOOKUPTABLES+36>

  for I :=  63 downto  32 do MS1BTABLE[I] := 5;

0x80662e5 mov $0x3f,%eax
0x80662ea inc %eax
0x80662eb nop
0x80662ec dec %eax
0x80662ed movl $0x5,0x8097140(,%eax,4)
0x80662f8 cmp $0x20,%eax
0x80662fb jg 0x80662ec <INITLOOKUPTABLES+60>

  for I :=  31 downto  16 do MS1BTABLE[I] := 4;

0x80662fd mov $0x1f,%eax
0x8066302 inc %eax
0x8066303 nop
0x8066304 dec %eax
0x8066305 movl $0x4,0x8097140(,%eax,4)
0x8066310 cmp $0x10,%eax
0x8066313 jg 0x8066304 <INITLOOKUPTABLES+84>

  for I :=  15 downto   8 do MS1BTABLE[I] := 3;

0x8066315 mov $0xf,%eax
0x806631a inc %eax
0x806631b nop
0x806631c dec %eax
0x806631d movl $0x3,0x8097140(,%eax,4)
0x8066328 cmp $0x8,%eax
0x806632b jg 0x806631c <INITLOOKUPTABLES+108>

  for I :=   7 downto   4 do MS1BTABLE[I] := 2;

0x806632d mov $0x7,%eax
0x8066332 inc %eax
0x8066333 nop
0x8066334 dec %eax
0x8066335 movl $0x2,0x8097140(,%eax,4)
0x8066340 cmp $0x4,%eax
0x8066343 jg 0x8066334 <INITLOOKUPTABLES+132>

Bernd wrote

Hello, I have observed something I do not understand. The following is a series of for-loops and the generated code looks strange to me. There always appears an inc followed by a dec

Leaving the inc away would require an additional jump to do the abort check at the loop entry.

and what is even more bizarre is the code in between it: sometimes it inserts a mov %esi,%esi, sometimes lea 0x0(%esi),%esi and sometimes just a simple nop,

Alignment of jmp target.

Bernd wrote

Hello, I have observed something I do not understand. The following is a series of for-loops and the generated code looks strange to me. There always appears an inc followed by a dec

Note that the "inc" comes before the loop body and the "dec" is inside it. It's only necessary in case the loop counter may potentially include the upper boundary of the loop counter type, but the compiler indeed does not catch several cases where it could be left out.

and what is even more bizarre is the code in between it: sometimes it inserts a mov %esi,%esi, sometimes lea 0x0(%esi),%esi and sometimes just a simple nop, although the loop looks exactly the same.

That's for code alignment.

Jonas

2011/12/3 Jonas Maebe :

Note that the "inc" comes before the loop body and the "dec" is inside [...] That's for code alignment.

You are right. It seems I shouldn't have drunken so much coffee today and not have worked for so long or I would have easily seen where the JG jumps to ;-)

I think my question is answered, thanks for pointing it out.

Bernd