[fpc-devel] TFPHashList (Was: Alternative parsers)

[Florian Klämpfl]

Am 23.10.2010 22:46, schrieb Dariusz Mazur:
>  W dniu 2010-10-22 23:30, Florian Klämpfl pisze:
>> Am 22.10.2010 23:17, schrieb Dariusz Mazur:
>>> full source in attachment (should I prepare it different?)
>> The best would be a diff against compiler sources.
> 
> OK. First I  find better computing of hash. My is slight worse than
> current (but overall faster)
> 
>>> Second: when I review assembler list I've notice some strange lines (all
>>> optimizations are enabled):
>>>
>> Which compiler version? 2.4.x? I think r15502 in trunk should fix this.
> 2.5.1 but older. Now I test from current. Its better (faster) but  I
> found other strange:
> 
> first: dec(i) is translate to three lines
>     movl    %esi,%eax
>     decl    %eax
>     movl    %eax,%esi
> 
> why not simple decl %esi ?

Yes. I saw this too and I didn't find the cause, especially because I
were not able to reproduce it in a small example.

> When variable is in %ebx things are the same.
> 
> 
> second  if I have:
>   while ii>0 do begin
>      ....;
>    dec(ii);
> 
> 
> assembler look:
> 
> 
> # [121] while ii>0 do begin
>     jmp    .Lj16  //<  here add first test of ii
>     .balign 4,0x90
> .Lj15:
> .Ll8:
> # [122] result:=LongWord(result *8010817  ) xor (Pw^);
> .Ll10:
> # [124] dec(ii);
>     movl    %esi,%eax
>     decl    %eax
>     movl    %eax,%esi
> .Lj16:
>     testl    %esi,%esi    //<--  this can be avoid, because test from DECL
>     jg    .Lj15
> 
> 
> Is this possible to achieve this optimizations,
> If yes, can somebody help, from which file I should start
> 

Replacing the jmp by a test and jz is two-fold: it increases code size
(thus higher code cache pollution) and it pollutes the branch prediction
unit while an uncoditional jump is very cheap on modern processers.