Florian Klämpfl <[email protected]> schrieb am So., 17. Juni 2018, 10:56:
> Am 16.06.2018 um 23:21 schrieb J. Gareth Moreton: > > Note that I speak mostly from an x86_64 perspective, since this is where > I have almost universal exposure. > > > > So I've been pondering a few things after researching Florian's > prototype patch for optimisations done prior to register > > allocation, when the pre-compiled assembly language utilises imaginary > (virtual) registers pretty much everywhere other > > than where distinct registers are required (e.g. function parameters). > My question is... how much can be moved to the > > pre-allocation stage? > > A lot, basically everything which reduced register pressure. The only > problem is, at this stage, the code contains a lot > of moves (compile with -sr to see how it looks like). So the optimizer > must be able to handle this. It might be even > possible to build a generic optimizer pass at this stage. Example: > > A typical sequence FPC often generates is: > > mov %src1,%dest1 > add %dest1,%src2,%dest2 > > If src1 is no released after mov but dest1 is release, src1 and dest1 > still cannot be coalesced as they interfere, so an > extra register is allocated. The move will be remove by the peephole > optimizer, but register was allocated and increase > register pressure. Such optimizations could be done generic (for all > CPUs): if the destination of a mov is only read > afterwards (this information is already generically available), the mov > can be removed and in this case dest1 can be > replaced by src1. > Though only if the type of src1 is the same as that of dest1, right? (e.g. int vs. address register) Regards, Sven >
_______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
