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