RESOLVED FIXED118835
fourthTier: Decouple the way that CFA stores its state from the way it does abstract interpretation
https://bugs.webkit.org/show_bug.cgi?id=118835
Summary fourthTier: Decouple the way that CFA stores its state from the way it does a...
Filip Pizlo
Reported 2013-07-17 23:18:03 PDT
Patch forthcoming.
Attachments
work in progress (89.67 KB, patch)
2013-07-17 23:18 PDT, Filip Pizlo
no flags
the patch (214.04 KB, patch)
2013-07-18 16:29 PDT, Filip Pizlo
oliver: review+
Filip Pizlo
Comment 1 2013-07-17 23:18:45 PDT
Created attachment 206952 [details] work in progress
Filip Pizlo
Comment 2 2013-07-18 15:13:36 PDT
I'm pretty sure this is a stupid idea, and it's not necessary.
Filip Pizlo
Comment 3 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.
Filip Pizlo
Comment 4 2013-07-18 16:29:14 PDT
Created attachment 207031 [details] the patch
Filip Pizlo
Comment 5 2013-07-18 19:18:48 PDT
Note You need to log in before you can comment on or make changes to this bug.