<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>Find attached a test patch of the deep optimizer - it was intertwined with a number of other peephole changes, so I hope these were removed successfully and won't cause a compiler error. (This is what I intend to submit to the bug reporter as a patch eventually) Running the compiler with DEBUG_AOPTCPU enabled will show where the deep optimizer has made savings in the .s files.<br>
</div><div><br>
</div><div>Gareth aka. Kit<br>
</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>