<HTML>
<style> BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }</style>Would you object to me trying anyway, Florian? It might be that I run into the same problems you had and it's too unsafe, but I'm going by a conservative philosophy in that if it spots something that it can't work out (e.g. an instruction that it's not programmed to handle) or is potentially unsafe (e.g. reading and writing to a block of memory that it doesn't have control over, due to multi-threading issues), then it just stops optimising and drops all assumptions that it has made at that point.<br>
<br>
<div>As a small test case, I'm attempting to see if I can spot and optimise, for example, "mov %rax, %rbx; lea %rcx, -8(%rsp); mov %rbx, 8(%rsp)", where a pipeline stall occurs due to a read-after-write penalty (with %rbx in this case). Normally the peephole optimiser will sort out such a problem, but because LEA appears in between the MOV's, it won't catch it. The other thing is attempting to merge unsigned division and modulus into a single "div" operation - that was actually my intention behind "Minor_div_improvement" in issue #32984 - by changing SBB to SETAE, it preserves the flags register that I can make better use of it in such a deep optimiser, as I can be certain as to what its value is at that point (or at the very least know it hasn't changed).</div><div><br>
</div><div>More than anything, it's a personal research project - I'd be over the moon if it works and it holds up to every test case thrown at it, but if it doesn't, well, at least I know more about assembly language and have gained experience to improve the peephole optimiser and other elements of FPC.<br>
</div><br>
Gareth aka. Kit<br>
<br>
<br>
<span style="font-weight: bold;">On Mon 21/05/18 20:44 , 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 13.05.2018 um 21:02 schrieb Christo:
<br>
<span style="color: rgb(102, 102, 102);">> On Sun, 2018-05-13 at 03:28 +0100, J. Gareth Moreton wrote:
</span><br>
<span style="color: rgb(102, 102, 102);">>> Expand on Data Flow Analysis in the compiler.
</span><br>
<span style="color: rgb(102, 102, 102);">>>
</span><br>
<span style="color: rgb(102, 102, 102);">>> What I personally call the "Deep Optimizer", I'm proposing an assembler-level optimisation
</span><br>
<span style="color: rgb(102, 102, 102);">>> system (although it won't touch pure assembler routines) that rearranges commands and changes
</span><br>
<span style="color: rgb(102, 102, 102);">>> registers in order to minimise pipeline stalls and to also collapse a "div" and "mod"
</span><br>
<span style="color: rgb(102, 102, 102);">>> operation into a single instruction where possible.
</span><br>
<span style="color: rgb(102, 102, 102);">>
</span><br>
<span style="color: rgb(102, 102, 102);">> I would also like the data flow analyzer to look at inline assembler and emit hints and warnings
</span><br>
<span style="color: rgb(102, 102, 102);">> if it picks up something incoherent.
</span><br>
<br>
We had already a data flow analyzer for assembler in 1.0.x and early 2.x times, however, it was
<br>
disabled after several years as it was too hard to make it work safely.
<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>