As the CFA gets smarter, we're seeing situations where it "correctly" proves that the OSR entrypoint through which we're trying to enter cannot possibly execute. This occurs when you have code which, in its prologue, modifies some constant object and flips it to have a new structure: o = constant; o.f = thing; // create new field loop { // osr entrpoint things } o's structure at compile-time will be the structure after having created the new field. Likely, that structure will be terminal, and so watchpointable. Hence we will prove that o's future structure set contains only that structure. But that means that 'o.f = thing' cannot possibly succeed every again, which is absolutely true - it can't. Any future execution of that statement, so long as that statement is creating a new field and nothing more, will OSR exit immediately. But then we go and prove our own demise, as it were: we prove that the OSR entrypoint is unreachable, since the code that preceded it cannot execute. It's useful to leverage knowledge of what the future structure set of an object can be in the future. We use this to do good optimizations, like structure watchpointing. That necessarily implies leveraging the fact that an object's structure cannot time-travel into the past. But in cases where the entrypoint into the function occurs at a point that is proven unreachable by this strategy, we should, instead of disabling entry, force the analysis to be just conservative enough to allow that entry to happen.
Created attachment 159262 [details] work in progress
Created attachment 159263 [details] the patch
Comment on attachment 159263 [details] the patch R is me
Landed in http://trac.webkit.org/changeset/125982