inference: invalidate stale slot wrapper types in ssavaluetypes#55551
inference: invalidate stale slot wrapper types in ssavaluetypes#55551
ssavaluetypes#55551Conversation
|
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. |
|
I was concerned that making this change in the ssavaluetypes array messes with our convergence behavior, but I guess widening should be ok? |
|
I may have to write a fuller explanation later, but ssavaluetypes plays no role in reaching convergence and so there are no constraints on its behavior currently, but also no validity to changing an entry that is not the current pc. It is difficult for the existing algorithm to consider this change for correctness and potentially very costly (as seen by the 10x cost for just this incomplete change) to require the whole array to converge. There is some support (because of cycles) for rescheduling a basic block for analysis after changing an ssavalue result, but is generally expected for that situation to be rare (and not potentially any time a Conditional is created) |
|
As Jameson suggested on Slack, adding a guard on the side that consumes |
fe21eb8 to
d7064c6
Compare
|
@nanosoldier |
|
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. |
When updating a state of local variables from an assignment, all stale slot wrapper types must be invalidated. However, up until now, only those held in the local variable state were being invalidated. In fact, those held in `ssavaluetypes` also need to be invalidated, and this commit addresses that. Currently all `ssavaluetypes` are iterated over with each assignment to a local variable, so this could potentially lead to performance issues. If so it might be necessary to perform invalidation more efficiently along with flow control. - fixes #55548
d7064c6 to
2224949
Compare
I tried implementing 2224949 with this approach, but it ended up requiring significant changes to the |
|
Replaced by #55601 |
This PR implements the "Path-Convergence Criterion" for SSA / ϕ-nodes as part of type-inference. The `VarState.ssadef` field corresponds to the "reaching definition" of the slot in SSA form, which allows us to conveniently reason about the identity of a `slot` across multiple program points. If the reaching def is equal at two program points, then the slot contents are guaranteed to be egal (i.e. `x₀ === x₁`) Fixes #55548 (alternative to #55551), by having `Conditional` remember the reaching definition that it narrows.
When updating a state of local variables from an assignment, all stale slot wrapper types must be invalidated. However, up until now, only those held in the local variable state were being invalidated. In fact, those held in
ssavaluetypesalso need to be invalidated, and this commit addresses that.Currently all
ssavaluetypesare iterated over with each assignment to a local variable, so this could potentially lead to performance issues. If so it might be necessary to perform invalidation more efficiently along with flow control.Conditionallattice element is semantically broken in the presence of SSAValues #55548@nanosoldier
runbenchmarks("inference", vs=":master")