Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2022-01

Proposed new utility functions for x86 peephole optimiser (and maybe others)

2 messages · 1 person ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

J. Gareth Moreton

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

Reply by email

J. Gareth Moreton
to J. Gareth Moreton

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

J. Gareth Moreton wrote 35 lines
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

Reply by email