JuliaLang
inference: invalidate stale slot wrapper types in `ssavaluetypes`
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 JuliaLang/julia#55548
@nanosoldier runbenchmarks("inference", vs=":master")
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 Conditional might be a better solution. This PR assumes that the slot assignment is always visited before any stale ssavaluetype is used, but that is not necessarily guaranteed in the algorithm.
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.
As Jameson suggested on Slack, adding a guard on the side that consumes
Conditionalmight be a better solution.
I tried implementing 22249491d463305e904d2e3a8859048e6f4b1331 with this approach, but it ended up requiring significant changes to the Conditional implementation (and it's still WIP at implementing tmerge for Conditional). Honestly I'm unsure whether we would want to accept this level of complexity. A simpler approach of widening ssavaluetypes would solve the original issue without any performance regressions (the original performance regression was fixed by tracking SSAs where slot wrapper types are put into ssavaluetypes). What do you think about the approach we should take here?