[Webkit-unassigned] [Bug 104638] Support op_switch_imm bytecode on DFG.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=104638





--- Comment #3 from Filip Pizlo <fpizlo at apple.com>  2012-12-11 01:31:02 PST ---
(In reply to comment #0)
> Here I make an attempt to support op_switch on DFG level.
> 
> Is an approach of parsing jump table and expanding several comparisons possible?
> 
> DFG Bytecode parser were unable to support creating multiple dfg blocks for one bytecode operation.
> Here I mostly solve the problem by tricks, what is a proper way to allow such operations?

I can't see anything obviously wrong with your approach, but I think one way around it, as I say in the other comment, is to have the parser just create a Switch node and only create additional blocks later, if it's appropriate.

One thing you'd have to take care of if you did that is that currently, basic block index implies basic block order.  So if you added blocks you'd up having the DFG generate code for those blocks at the end of the code.  That's not a show-stopper but it probably would lead to suboptimal performance.  You could get around this by just decoupling program order from basic block index, for example by having the DFG process blocks using an index vector:

class Graph {
    // all of the current things...
    Vector<BlockIndex> m_blockOrder;
}

But, probably an even better way to do this in a first cut is to just wire the Switch node all the way through to the backend, and have the backend do all of the code generation for the Switch.  Then you don't have to add any blocks.  This might end up being slightly suboptimal for small switch statements (like, we already have lots of optimizations for CompareStrictEq that you might not end up implementing for Switch even though it does the same things) but it will surely be more optimal for large switch statements where a linear sequence of CompareStrictEq's is likely to be a regression over the baseline JIT's lookup table approach.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.