<HTML>
<style> BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }</style>Thanks David,<br>
<br>
I'm still learning some of the nuances of the Intel and AMD processors, but most of it is just logical analysis. Admittedly my main drive has been to shrink down the size of the binary, since Delphi and Free Pascal have always been a little bit bloated in comparison. Not that it is necessarily a bad thing, but saving space without sacrificing performance can only be a good thing, especially for those with limited bandwidth or for saving those few precious bytes when burning files to a CD or DVD.<br>
<br>
There have been a few instances in the compiled compiler (my main test case) where an entire register is freed up due to my deep optimisation, and that means the corresponding "push" and "pop" at either end of the procedure can be removed (along with the corresponding stack unwinding information), although I haven't started programming that yet.<br>
<br>
I am ready to submit this part of my deep optimiser as a patch. I'm just waiting for Florian's acceptance or rejection of my debug strip patch - https://bugs.freepascal.org/view.php?id=33798 (the 3rd attempt!) - only because it shares some debugging code with said patch (it was useful to monitor how the registers inside references were changed). If it's rejected, it just means I'll have to change some of that debugging code a bit.<br>
<br>
<div>Gareth aka. Kit</div> <br>
<br>
<span style="font-weight: bold;">On Mon 11/06/18 20:27 , David Pethes public@satd.sk sent:<br>
</span><blockquote style="BORDER-LEFT: #F5F5F5 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">Hi,
<br>
nice work.
<br>
<br>
On 8. 6. 2018 0:46, J. Gareth Moreton wrote:
<br>
<br>
<span style="color: rgb(102, 102, 102);">> The deep optimiser changes this to:
</span><br>
<span style="color: rgb(102, 102, 102);">>
</span><br>
<span style="color: rgb(102, 102, 102);">> movq %rcx,%rax
</span><br>
<span style="color: rgb(102, 102, 102);">> movq %rdx,%rsi
</span><br>
<span style="color: rgb(102, 102, 102);">> movq %rcx,%rbx
</span><br>
<span style="color: rgb(102, 102, 102);">>
</span><br>
<span style="color: rgb(102, 102, 102);">> It determines, for the third MOV, it can
</span><br>
<span style="color: rgb(102, 102, 102);">> change %rax for %rcx to minimise a
</span><br>
<span style="color: rgb(102, 102, 102);">> pipeline stall, and then knows that %rbx
</span><br>
<span style="color: rgb(102, 102, 102);">> and %rcx contain the same value, so can
</span><br>
<span style="color: rgb(102, 102, 102);">> remove the 4th MOV completely. Given that
</span><br>
<span style="color: rgb(102, 102, 102);">> modern processors usually have at least 3
</span><br>
<span style="color: rgb(102, 102, 102);">> ALUs and the interdependencies have been
</span><br>
<span style="color: rgb(102, 102, 102);">> removed, this will likely give a speed
</span><br>
<span style="color: rgb(102, 102, 102);">> increase of one cycle over these few
</span><br>
<span style="color: rgb(102, 102, 102);">> commands.
</span><br>
<br>
Note that modern cpu-s can use move elimination for reg to reg moves, so
<br>
it doesn't cost any execution resources (it's "free"). Despite that it's
<br>
still a win, because it spares both bytes in I-cache and decoder
<br>
bandwidth (which can indirectly lead to some spared cycle(s) at other
<br>
places).
<br>
<br>
David
<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>