Patch forthcoming.
Created attachment 204122 [details] very early work in progress Still figuring out what the best way of doing this is.
Created attachment 204277 [details] it should just work
Created attachment 204289 [details] it did just work Still need to implement 32-bit part, still need to run more tests.
Still debugging some LayoutTests/jquery crashes. No perf numbers yet other than microbenchmarks which speed up by a *lot*.
Created attachment 204361 [details] the patch
Created attachment 204375 [details] the patch 32-bit now builds and runs clean.
Created attachment 204376 [details] the patch Added JSRegress tests.
This isn't a small speed-up. in-four-cases 297.3037+-2.8573 ^ 21.8263+-0.1147 ^ definitely 13.6213x faster in-one-case-false 178.0126+-2.6962 ^ 10.4301+-0.1371 ^ definitely 17.0673x faster in-one-case-true 156.9623+-2.0516 ^ 10.1108+-0.0654 ^ definitely 15.5242x faster in-two-cases 166.7664+-1.6888 ^ 10.5953+-0.1015 ^ definitely 15.7397x faster
Comment on attachment 204376 [details] the patch Would be nice to take even more advantage and further optimize for cases like if (!("property" in object)) throw "oops!"; return object.property; but I can't in good conscience thumb my nose at a 17X speedup.
(In reply to comment #9) > (From update of attachment 204376 [details]) > Would be nice to take even more advantage and further optimize for cases like > > if (!("property" in object)) > throw "oops!"; > return object.property; Yes. Here's the plan: 1) Get the baseline JIT to use the DFG's inline caching logic, including for op_in. 2) Have the DFGByteCodeParser extract the inline cache data for op_in the same way it does for op_get_by_id and friends. 3a) For In's that only have one case in the inline cache and they didn't take slow path, simply turn them into CheckStructure and their result becomes a JSConstant(true) or JSConstant(false). 3b) For In's that too two cases (a true and a false case), integrate Branch(In(@object)) with the CFA such that the CFA will remember that on the then case of the Branch, we know that @object has the true structure, and on the else case of the Branch, we know that @object has the false structure. We haven't yet done such things in the CFA, but they are easy to do in our IR; they'll just require a slight refiddling of the relationship between the CFA's executeEffects() method and the mergeXYZ() methods; executeEffects() will have to convey to the merge methods that we will want to merge slightly different data for the different paths of the branch. > > but I can't in good conscience thumb my nose at a 17X speedup. Seems sensible! ;-) OTOH, this didn't really speed up pdfjs despite increasing coverage, and despite the fact that pdfjs is clearly making good use of the inline caching - disassembly dumps show lots of juicy DFG In stubs, and most of them look optimal. So I guess those functions that used 'in' simply weren't on the hot path. Oh well it happens. Still happy that I made it fast.
Landed in http://trac.webkit.org/changeset/151569