1) I am just getting started on this, so I can only answer with limited knowledge.
@experts, please correct me below, where needed
2) The peephole opt is only something I do "on the side" as it currently is.

From a quick glance, this does not look like something for the peephole opt.

The peephole opt currently looks at statements that are close together (follow each other immediately).
I am not sure to which extend (if at all) it would be acceptable to break that limit (it is doable, question is if desired).

In this specific case:
1) between the "fstpl" and the "mov (half_the_data), %edi" are other statements.
detecting the connection would either:
- need scanning several statements ahead. This would be slow, because it had to be done after each storing "something to memory" (so very often)
- keeping state of all the involved registers and memory (do-able / interesting at least from a theoretical view / but not sure if desired)
2) only half the mem is accessed, and then the other half. That means to detect the connection between the mem read and the register, it is needed to analyse 4 statements. Very unlikely to see this in the peephole opt.

The livelihood of "a[i]" needs to be checked where the code is generated.

24.01.2014 3:04, Martin Frb пишет:

1) You are right that it's not the job for peephole analyzer, it is typical common subexpression elimination.
2) Reporter's assumption about fstp is wrong: the first fstp instruction removes value from fpu stack, so it cannot be used for the second time without first reloading value onto stack.
3) The assignments of floating-point values are currently being generated using integer instructions, hence the subsequent code. This way it doesn't depend on number of available FPU registers, which is hard to know at any point.

Regards,
Sergei

"2) Reporter's assumption about fstp is wrong: the first fstp instruction removes value from fpu stack, so it cannot be used for the second time without first reloading value onto stack."

Compiler should reuse loaded value (a[i]) and store to a[i] using fstl, then fstpl to a[i+1]

That is why Sergei wrote "typical common subexpression elimination". I am sure it is a todo for the fpc team.

Also In this case optimizing this to be re-used is a small (smaller) gain. You still have plenty of statements that recalculate the address of an array element, using multiplication.

Introducing a temporary pointer to a[i], and using addition in each run of the loop to increment it, will gain a lot more. (Again, I am sure it is a todo).

Until that is done, your best choice, if you need the speed is to do this by hand:

if cnt = 0 then exit;
tmpptrA := @a[0];
tmpptrB := @b[0];
for i := 0 to cnt - 1 do
     begin
       tmpptrA^ := tmpptrA^ + tmpptrB^;
       tmpptrA2 := tmpptrA^;
       inc(tmpptrA); // assuming a typed pointer
       tmpptrA^ := tmpptrA2^;
       inc(tmpptrB); // assuming a typed pointer
     end;
or better
if cnt = 0 then exit;
tmpptrA := @a[0];
tmpptrB := @b[0];
for i := 0 to cnt - 1 do
     begin
       tmpVAlue := tmpptrA^ + tmpptrB^;
       tmpptrA^ := tmpVAlue;
       inc(tmpptrA); // assuming a typed pointer
       tmpptrA^ := tmpVAlue;
       inc(tmpptrB); // assuming a typed pointer
     end;

It looses readability, so keep the good code as comment.

There is a bigger example, where exactly that was done, because FPCs optimization was not sufficient enough for what the author wanted. http://bugs.freepascal.org/view.php?id=10275

Actually, if the late hour has not clouded my sight, it goes even better.

tmpptrA := @a[0];
tmpptrB := @b[0];
  tmpVAlue := tmpptrA^;
for i := 0 to cnt - 1 do
     begin
       tmpVAlue := tmpVAlue + tmpptrB^;
       tmpptrA^ := tmpVAlue;
       inc(tmpptrA); // assuming a typed pointer
       inc(tmpptrB); // assuming a typed pointer
     end;
     tmpptrA^ := tmpVAlue;

the last is actually a[cnt], not sure if intended, but it is done so in the original code too.

Martin Frb wrote

There is a bigger example, where exactly that was done, because FPCs optimization was not sufficient enough for what the author wanted. http://bugs.freepascal.org/view.php?id=10275

In that context... @Florian: how is your SSA support coming along? :)

Regards,
Sven

Still WIP :) But a lot of my commits from the last weeks are spin-offs of the SSA work.

Together with all other improvements this results in significant better code:

fpc -l -O3 sha256.pp -S2
Free Pascal Compiler version 2.6.2 [2013/02/12] for i386 Copyright (c) 1993-2012 by Florian Klaempfl and others Target OS: Win32 for i386
Compiling sha256.pp
Linking sha256.exe
74 lines compiled, 0.1 sec , 26016 bytes code, 2220 bytes data

fptime sha256
Expected: 3994057095, got 3994057095
483.000 ms

pp -n @c:\fpc\bin\fpc.cfg -l -O4 sha256.pp -S2
Free Pascal Compiler version 2.7.1 [2014/01/25] for i386 Copyright (c) 1993-2013 by Florian Klaempfl and others

fptime sha256
Expected: 3994057095, got 3994057095
367.000 ms

Nice :D
Still looking forward to more improvements regarding SSA ^^

Regards,
Sven

How are the numbers for ARM? :-)

Nico

Most could be probably gained in this example by moving variables into xmm registers if only certain kind of operations are carried out on them.

Just try :)? This is trunk.

Excellent work Florian! Makes me want to work on those parts of the compiler.. Though my current interests are in other parts of it. But very nice. :)