<HTML>
<style> BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }</style>That's some interesting insight - thanks Florian. Something that might need rigorous timing tests in that case. I thought about the binary search map since the case statements jump to a procedure call, and I wondered if I could take advantage of that homogenuity. In the meantime, I found a couple of peephole optimisations that don't rely on tricky code like that in the bug report! I'll submit a patch later, just in case I find a few more.<br>
<br>
Gareth aka Kit.<br>
<br>
<br>
<span style="font-weight: bold;">On Sun 27/05/18 13:00 , Florian Klämpfl florian@freepascal.org sent:<br>
</span><blockquote style="BORDER-LEFT: #F5F5F5 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">Am 27.05.2018 um 02:48 schrieb J. Gareth Moreton:
<br>
<span style="color: rgb(102, 102, 102);">> Hi guys,
</span><br>
<span style="color: rgb(102, 102, 102);">>
</span><br>
<span style="color: rgb(102, 102, 102);">> So I'm still experimenting and researching with the deep optimiser, and I'm starting to have some
</span><br>
<span style="color: rgb(102, 102, 102);">> successes... until I found a compiler bug!
</span><br>
<span style="color: rgb(102, 102, 102);">>
</span><br>
<span style="color: rgb(102, 102, 102);">> <a target="_blank" href="https://bugs.freepascal.org/view.php?id=33794"><span style="color: red;">https://bugs.freepascal.org/view.php?id=33794</span></a>
</span><br>
<span style="color: rgb(102, 102, 102);">>
</span><br>
<span style="color: rgb(102, 102, 102);">> What I'm trying to do, and something which I'd like to try out with the regular peephole optimiser
</span><br>
<span style="color: rgb(102, 102, 102);">> at some point, is using a sorted list that maps an assembler command to a handler procedure and
</span><br>
<span style="color: rgb(102, 102, 102);">> using a binary search to find the correct routine. This will speed up the optimiser from O(n) (i.e.
</span><br>
<span style="color: rgb(102, 102, 102);">> the speed of "case X of") to O(log n) per line of code,
</span><br>
<br>
FPC knows different means to generate code for case statements (linear list, jump table, jump tree);
<br>
based on a heuristics the method is chosen. If in case of the assembler optimizer, FPC chooses the
<br>
wrong approach, this heuristics should be checked, see e.g. compiler/ncgset.pas:1170+:
<br>
<br>
{ value has been determined on an i7-4770 using a random case with random values
<br>
if more values are known, this can be handled depending on the target CPU
<br>
<br>
Testing on a Core 2 Duo E6850 as well as on a Raspi3 showed also, that 64 is
<br>
a good value }
<br>
else if labelcnt>=64 then
<br>
genjmptree(labels)
<br>
else
<br>
genlinearlist(labels);
<br>
<br>
<br>
The label count if a jmp tree is beneficial, is surprisingly high, probably due to branch prediction
<br>
which breaks completely havoc in case of a jump tree.
<br>
_______________________________________________
<br>
fpc-devel maillist - <a href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a>
<br>
<a target="_blank" href="<a href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>"><span style="color: red;">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</span></a>
<br>
<br>
<br>
</blockquote></HTML>