Bug 144086 – Force SetLocals live the same way that we force MovHinted Nodes live - by using bytecode liveness

• Status: NEW
• Component: JavaScriptCore

[Filip Pizlo]

As of https://bugs.webkit.org/show_bug.cgi?id=143735 we figure out when and where to Phantom a node by using bytecode liveness. We could also decide which SetLocals must be generated by using bytecode liveness. It would be relatively straight-forward. If we did this, then we could make GetLocal be not MustGenerate.

[Filip Pizlo]

Actually, this is really weird and possibly unprofitable. We keep SetLocals to variables accessed in other blocks alive because GetLocals are live. That's a sensible story because it means that ThreadedCPS sees liveness-at-head and liveness-at-tail at all times.

If we allow GetLocals to die then things change. We could make it work by treating GetLocal like a MovHint in PhantomInsertionPhase: it's a MovHint of the GetLocal. Then we would get Phantoms on the GetLocals in blocks that would have used the GetLocals in bytecode. But this would mean inconsistencies in threaded CPS. Consider the case where we have:

// block 1
var x = 42;
if (a) {
    // block 2
    if (b) {
        // block 3
        use(x);
    }
}

If we prove b to be false then we could jettison block 3, and if we take the "we'll just fix the Phantoms later" approach then we'll be missing a Phi at block 2.

It appears that our current approach of eagerly inserting PhantomLocals to track non-local liveness, and then avoiding killing any GetLocals, is the right approach.