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. _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
