|Summary:||fourthTier: Decouple the way that CFA stores its state from the way it does abstract interpretation|
|Product:||WebKit||Reporter:||Filip Pizlo <fpizlo>|
|Severity:||Normal||CC:||barraclough, ggaren, mark.lam, mhahnenberg, msaboff, oliver, sam|
|Version:||528+ (Nightly build)|
|Bug Depends on:|
Description Filip Pizlo 2013-07-17 23:18:03 PDT
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.