Bug 118835 - fourthTier: Decouple the way that CFA stores its state from the way it does abstract interpretation
Summary: fourthTier: Decouple the way that CFA stores its state from the way it does a...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Filip Pizlo
URL:
Keywords:
Depends on:
Blocks: 118749
  Show dependency treegraph
 
Reported: 2013-07-17 23:18 PDT by Filip Pizlo
Modified: 2013-07-18 19:18 PDT (History)
7 users (show)

See Also:


Attachments
work in progress (89.67 KB, patch)
2013-07-17 23:18 PDT, Filip Pizlo
no flags Details | Formatted Diff | Diff
the patch (214.04 KB, patch)
2013-07-18 16:29 PDT, Filip Pizlo
oliver: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Filip Pizlo 2013-07-17 23:18:03 PDT
Patch forthcoming.
Comment 1 Filip Pizlo 2013-07-17 23:18:45 PDT
Created attachment 206952 [details]
work in progress
Comment 2 Filip Pizlo 2013-07-18 15:13:36 PDT
I'm pretty sure this is a stupid idea, and it's not necessary.
Comment 3 Filip Pizlo 2013-07-18 16:25:15 PDT
Actually, this *is* the right way to go.  We need this because:

- We want to hoist things out of loops.

- We don't know what things rely on what type checks.

- We only want to hoist type checks out of loops if they aren't clobbered.

- We may want to still hoist things that depended on those type checks, if it's safe to do those things based on the CFA state at the tail of the loop pre-header.

- We don't want things to rely on their type checks by way of a token, because that's just weird.

So, we want to be able to have a special form of the CFA that can incrementally update a basic block's state-at-tail, and we want to be able to do this for multiple blocks simultaneously.  This requires *not* storing the per-node state in the nodes themselves, but instead using the at-tail HashMap directly.

Hence we need to have a way of making the abstract interpreter (i.e. AbstractState::execute) polymorphic with respect to state representation.  Put another way, we need to separate the way that abstract state is represented from the way DFG IR is abstractly interpreted.
Comment 4 Filip Pizlo 2013-07-18 16:29:14 PDT
Created attachment 207031 [details]
the patch
Comment 5 Filip Pizlo 2013-07-18 19:18:48 PDT
Landed in http://trac.webkit.org/changeset/152879