We currently remove _CHECK_VALIDITY ops as part of a final linear pass over JIT code, with the heuristic being:
- If any op escaped since the last validity check, leave it in.
- Otherwise, remove it.
However, this is too strict. A looser, still correct heuristic would be:
- If any op escaped since the last validity check, and we have an optimization that relies on that validity before the next validity check, leave it in.
- Otherwise, remove it.
As a simple example: _POP_TOP escapes. If we have two POP_TOP instructions in a row, the JIT will check validity between them, which isn't necessary.
Since it's our optimizations that create a reliance on validity checks, the removal of validity checks and the tracking of validity should be done as part of the abstract interpretation. If could be as simple as calling require_validity(ctx); whenever we perform a validity-requiring optimization. This helper would just re-insert the last seen _CHECK_VALIDITY instruction.
Linked PRs
We currently remove
_CHECK_VALIDITYops as part of a final linear pass over JIT code, with the heuristic being:However, this is too strict. A looser, still correct heuristic would be:
As a simple example:
_POP_TOPescapes. If we have twoPOP_TOPinstructions in a row, the JIT will check validity between them, which isn't necessary.Since it's our optimizations that create a reliance on validity checks, the removal of validity checks and the tracking of validity should be done as part of the abstract interpretation. If could be as simple as calling
require_validity(ctx);whenever we perform a validity-requiring optimization. This helper would just re-insert the last seen_CHECK_VALIDITYinstruction.Linked PRs
_CHECK_VALIDITY_AND_SET_IP#131810