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, https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/136, 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.
https://www.avast.com/antivirus

_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Reply via email to