<HTML>
<style> BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }</style>So far, I'm researching the optimisation as listed below... tracking registers with identical values and changing them to minimise pipeline stalls. Because I don't need to keep track of their actual values, just whether they've changed since a particular MOV instruction, I've managed to move this into the peephole optimiser as an extension to TX86AsmOptimizer.PostPeepholeOptMov().<br>
<br>
It's a bit more difficult than it looks though - I've had a lot of crashes so far when it changes a register when it shouldn't do, but I'm ironing out the bugs one by one. To truly see the gains though, one would need to perform some kind of intense timing comparison.<br>
<br>
This would be the first step in the step-by-step implementation. More in-depth deep data-flow optimisation, like successfully merging div and mod instructions of the same numerator and denominator will require some more care and thought, especially as the two divison operations may not use the same registers (if successful though, it will improve the compiler itself, since it has "x div 1000" and "x mod 1000" side-by-side in a couple of places, a common pair of expressions to produce a human-readable time metric, e.g. seconds and milliseconds).<div><br>
</div><div>Gareth aka. Kit<br>
</div> <br>
<br>
<span style="font-weight: bold;">On Sun 03/06/18 14:12 , 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 21.05.2018 um 21:05 schrieb J. Gareth Moreton:
<br>
<span style="color: rgb(102, 102, 102);">> Would you object to me trying anyway, Florian?
</span><br>
<br>
No, feel free to go ahead, but it needs to be done step by step.
<br>
<br>
<span style="color: rgb(102, 102, 102);">> It might be that I run into the same problems you had and it's too
</span><br>
<span style="color: rgb(102, 102, 102);">> unsafe, but I'm going by a conservative philosophy in that if it spots something that it can't work out (e.g. an
</span><br>
<span style="color: rgb(102, 102, 102);">> instruction that it's not programmed to handle) or is potentially unsafe (e.g. reading and writing to a block of memory
</span><br>
<span style="color: rgb(102, 102, 102);">> that it doesn't have control over, due to multi-threading issues), then it just stops optimising and drops all
</span><br>
<span style="color: rgb(102, 102, 102);">> assumptions that it has made at that point.
</span><br>
<span style="color: rgb(102, 102, 102);">>
</span><br>
<span style="color: rgb(102, 102, 102);">> As a small test case, I'm attempting to see if I can spot and optimise, for example, "mov %rax, %rbx; lea %rcx,
</span><br>
<span style="color: rgb(102, 102, 102);">> -8(%rsp); mov %rbx, 8(%rsp)", where a pipeline stall occurs due to a read-after-write penalty (with %rbx in this case).
</span><br>
<br>
Things like this are fine, it gets hairy though as soon as memory locations are involved.
<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>