<HTML>
<style> BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }</style>That's where the first stage of my deep optimizer
might be able to help, since it explicitly starts at a MOV command (say,
mov %reg_source, %reg_dest) and scans forward to see if %reg_dest can
be replaced with %reg_source - it stops when it hits a jump, call,
non-skippable label, when the registers change value or if %reg_dest
cannot be replaced. If all references to %reg_dest were replaced prior
to its value being completely overwritten, then it can then delete the
original MOV.<br>
<br>
<div>While it will only be appropriate to run at -O2 and -O3, the
restrictions surrounding the register replacement, and specially where
it stops searching, help ensure that it runs relatively quickly.</div><div><br>
</div><div>By the way, now that the debug strip patch has now being approved (thanks Florian!), I can now safely submit my prototype for the Deep Optimizer! https://bugs.freepascal.org/view.php?id=33871 - as specifid in the notes, compile the compiler with the DEBUG_AOPTCPU directive and compile projects with the -a flag if you wish to see where the Deep Optimizer has made savings in the intermediate assemblies.<br>
</div><div><br>
</div><div>Note that this version works during post-peephole optimisations. I'm looking at ways to move it to the preallocation phase in a way that's extensible, especially in regards to tracking virtual registers. It's a little tricker because it's very easy to leave a dangling pointer.<br>
</div><div><br>
</div><div>Gareth aka. Kit</div><br>
<br>
<span style="font-weight: bold;">On Sun 17/06/18 09:56 , 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 16.06.2018 um 23:21 schrieb J. Gareth Moreton:
<br>
<span style="color: rgb(102, 102, 102);">> Note that I speak mostly from an x86_64 perspective, since this is where I have almost universal exposure.
</span><br>
<span style="color: rgb(102, 102, 102);">>
</span><br>
<span style="color: rgb(102, 102, 102);">> So I've been pondering a few things after researching Florian's prototype patch for optimisations done prior to register
</span><br>
<span style="color: rgb(102, 102, 102);">> allocation, when the pre-compiled assembly language utilises imaginary (virtual) registers pretty much everywhere other
</span><br>
<span style="color: rgb(102, 102, 102);">> than where distinct registers are required (e.g. function parameters). My question is... how much can be moved to the
</span><br>
<span style="color: rgb(102, 102, 102);">> pre-allocation stage?
</span><br>
<br>
A lot, basically everything which reduced register pressure. The only problem is, at this stage, the code contains a lot
<br>
of moves (compile with -sr to see how it looks like). So the optimizer must be able to handle this. It might be even
<br>
possible to build a generic optimizer pass at this stage. Example:
<br>
<br>
A typical sequence FPC often generates is:
<br>
<br>
mov %src1,%dest1
<br>
add %dest1,%src2,%dest2
<br>
<br>
If src1 is no released after mov but dest1 is release, src1 and dest1 still cannot be coalesced as they interfere, so an
<br>
extra register is allocated. The move will be remove by the peephole optimizer, but register was allocated and increase
<br>
register pressure. Such optimizations could be done generic (for all CPUs): if the destination of a mov is only read
<br>
afterwards (this information is already generically available), the mov can be removed and in this case dest1 can be
<br>
replaced by src1.
<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>