Bug 94412

Summary: The current state of the call frame should be taken into account in the DFG for both predictions and proofs
Product: WebKit Reporter: Filip Pizlo <fpizlo>
Component: JavaScriptCoreAssignee: Filip Pizlo <fpizlo>
Status: RESOLVED FIXED    
Severity: Normal CC: barraclough, ggaren, mhahnenberg, msaboff, oliver
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Bug Depends on:    
Bug Blocks: 94205    
Attachments:
Description Flags
work in progress
none
the patch ggaren: review+

Description Filip Pizlo 2012-08-17 22:22:01 PDT
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.
Comment 1 Filip Pizlo 2012-08-17 22:40:30 PDT
Created attachment 159262 [details]
work in progress
Comment 2 Filip Pizlo 2012-08-18 12:19:15 PDT
Created attachment 159263 [details]
the patch
Comment 3 Geoffrey Garen 2012-08-19 14:50:26 PDT
Comment on attachment 159263 [details]
the patch

R is me
Comment 4 Geoffrey Garen 2012-08-19 14:51:33 PDT
Comment on attachment 159263 [details]
the patch

R is me
Comment 5 Filip Pizlo 2012-08-19 15:03:05 PDT
Landed in http://trac.webkit.org/changeset/125982