<HTML>
Just to clarify, the patch does NOT contain the binary search algorithm. It does contain a utility function that was accidentally left over when I stripped the code out, named "CreateCMOVInstr", but this can be safely removed.<br>
<div><br>
</div><div>Gareth aka. Kit</div><div><br>
</div><br>
<span style="font-weight: bold;">On Wed 26/12/18 00:27 , "J. Gareth Moreton" gareth@moreton-family.com sent:<br>
</span><blockquote style="BORDER-LEFT: #F5F5F5 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT:0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
Merry Christmas everyone!<br>
<br>
I've uploaded my improvements to a bug report, along with a test program that gives timings and verifies correctness.<br>
<br>
https://bugs.freepascal.org/view.php?id=34762<br>
<br>
It turns out that my binary search algorithm runs slower on average "Domain of 1024" tests (which are based on the design of the peephole optimizer) that I had set up (which currently still compile into linear lists) except in the case where the correct branch is the midpoint of the valid set (in a jump tree, this is the first value tested). Jump trees are also faster than a binary search currently despite the large number of conditional branches required - nevertheless, I will continue to research this algorithm to see if it can find a role - I suspect that it might still find a place where each branch calls an identically-structured procedure... if I can get the compiler to identify that in the branches. Successfully doing this will also improve case blocks that are compiled into jump tables instead.<br>
<div><br>
</div><div>Gareth aka. Kit<br>
</div> <br>
<br>
<span style="font-weight: bold;">On Sat 15/12/18 19:12 , "J. Gareth Moreton" gareth@moreton-family.com sent:<br>
</span><blockquote style="BORDER-LEFT: #F5F5F5 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT:0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
I'll see what I can do!<br>
<br>
The one thing about my case optimisations here is that they're done at the node level. Some parts are platform-independent, but unfortunately, things like jump table generation have to be implemented for each platform.<br>
<br>
The aint shuffling is a little difficult to test for sure, but what's worse is the use of TConstExprInt, and not just because of the overhead involved with reading and writing to them. I used logic in some places though, like when I do a sort of for-loop between max_ and hv, I subtracted 1 from each variable (sometimes implicitly) to account for a potential overflow situation. It's impossible for it to trigger an underflow because max_ is greater than min_, and they wouldn't be equal otherwise a jump table won't even be generated.<br>
<br>
Either way, I'm just enjoying myself with this!<br>
<br>
Gareth aka. Kit<br>
<br>
<br>
<span style="font-weight: bold;">On Sat 15/12/18 19:55 , Martok listbox@martoks-place.de sent:<br>
</span><blockquote style="BORDER-LEFT: #F5F5F5 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">Am 15.12.2018 um 18:08 schrieb J. Gareth Moreton:
<br>
<span style="color: rgb(102, 102, 102);">> So here's something else I've been playing with in the interim... I've been
</span><br>
<span style="color: rgb(102, 102, 102);">> working on improving the algorithms used when compiling case blocks. It was
</span><br>
<span style="color: rgb(102, 102, 102);">> driven partly by my binary search idea for certain kinds of case block, which I
</span><br>
<span style="color: rgb(102, 102, 102);">> wrote up over here: <a target="_blank" href="<a href=" http:="" wiki.freepascal.org="" case_compiler_optimization"="">http://wiki.freepascal.org/Case_Compiler_Optimization</a>"><span style="color: red;">http://wiki.freepascal.org/Case_Compiler_Optimization</span>
</span><br>
<br>
Feel free to include '0033093_Casenode_order.patch' from
<br>
<<a target="_blank" href="https://bugs.freepascal.org/view.php?id=33093>"><span style="color: red;">https://bugs.freepascal.org/view.php?id=33093></span></a>;
<br>
It's actually already a bit simpler in your version ;-)
<br>
<br>
The one thing that still bugs me (but I know it's not really seen as a problem
<br>
in FPC) is that every platform cg theoretically has to implement all of that,
<br>
causing a lot of duplication.
<br>
<br>
I like the use of more expressive intermediate names. But there was a lot of
<br>
overflowed-aint-shuffling, are you sure that still works everywhere?
<br>
<br>
Bug 0032115 provides a "nice" test case for things that can go wrong with
<br>
different word sizes, and is also a good test for the true label count.
<br>
<br>
<br>
--
<br>
Regards,
<br>
Martok
<br>
<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>
<br>
<br>
<br>
</blockquote>
_______________________________________________<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><br>
<br>
</blockquote>
_______________________________________________<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>
</blockquote></HTML>