Update to my original mail:
https://lists.freepascal.org/pipermail/fpc-devel/2021-June/043884.html
I found the needle in the haystack.
It appears fixed in current (2 day old) fixes 3.3.1. / I have not tested
trunk.
-------------------------
The code is in: components\lazutils\lazcollections.pas
procedure TLazFifoQueue.Grow(ADelta: integer);
var
NewList: array of T;
c: Integer;
i: QWord;
begin
c:=Max(FQueueSize + ADelta, Integer(FTotalItemsPushed -
FTotalItemsPopped));
setlength(NewList{%H-}, c);
i:=FTotalItemsPopped;
while i < FTotalItemsPushed do begin
NewList[i mod c] := FList[i mod FQueueSize];
inc(i);
end;
FList := NewList;
FQueueSize:=c;
end;
Without peephole (the "max" is inlined, below is the compare code)
# Var c located in register ebx
cmpq %rax,%rcx
jl .Lj37
jmp .Lj38
.Lj37:
jmp .Lj39
.Lj38:
movq %rcx,%rax
.Lj39:
movl %eax,%ebx
movslq %ebx,%rax
The 2 moves at the end do 2 things
1) extend 32 to 64 bit (afaik)
2) move the result to ebx
Compiled with peephole the code looks like this
cmpq %rax,%rcx
cmovnlq %rcx,%rax
movslq %eax,%rax
The 2 moves have been combined => ebx is no longer loaded.
But ebx is used for c. And hence c has the wrong value.
<little rant>Because for some mystery SetLength does not use the
register value, but loads from the stackframe, the array is correctly
sized. Therefore the code above never crashes. But it does not move all
data to the new array. Other code then accesses random memory. So my
crashes always happened elsewhere. Really not helpful</little rant>
In 3.3.1 the result is
cmpq %rax,%rcx
# Peephole Optimization: JccMov2CMov
cmovnlq %rcx,%rax
movl %eax,%ebx
# Peephole Optimization: %ebx = %eax; changed to minimise pipeline stall
(MovXXX2MovXXX)
.Ll23:
movslq %eax,%rax
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
