[fpc-devel] Proposed new utility functions for x86 peephole optimiser (and maybe others)
J. Gareth Moreton
gareth at moreton-family.com
Tue Jan 11 13:42:45 CET 2022
And I got the equation wrong for the permissive one. It's meant to be
something like the following instead:
"(r1.volatility + r2.volatility - permitted_volatility) = "
Gareth aka. Kit
On 11/01/2022 08:59, J. Gareth Moreton via fpc-devel wrote:
> Hi everyone,
> During my implementation of a new optimisation,
> which merges some references, Florian asked me to make sure I check
> the volatility fields of the references, something which I forgot
> about, but which turned out was already covered thanks to the fields
> being checked by the RefsEqual function (they must both be ).
> It got me thinking, but in this case, the two references that are
> optimised are only read from, not written, so the optimisation would
> still be valid if one or both were vol_write. Would it be plausible
> to maybe add a couple of versions of RefsEqual that address volatility
> better? For example:
> function RefsEqualPermissive(const r1, r2: treference;
> permitted_volatility: tvolatilityset): Boolean;
> In this case, anything in permitted_volatility is considered
> 'allowed', so the optimisation in the link above would permit
> vol_write since the references are only read from, and this would be
> checked in the function by "(r1.volatility + permitted_volatility) =
> (r2.volatility + permitted_volatility)". In the case of
> permitted_volatility = vol_write, if either r1 or r2 has vol_read, the
> comparison fails.
> function RefsEqualVolatile(const r1, r2: treference): Boolean;
> In this version, the volatility isn't checked at all and is logically
> equivalent to calling RefsEqualPermissive with [vol_read, vol_write]
> (and any other values that are added), but slightly faster.
> Gareth aka. Kit
This email has been checked for viruses by Avast antivirus software.
More information about the fpc-devel