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]
Created attachment 204375 [details]
32-bit now builds and runs clean.
Created attachment 204376 [details]
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]
Would be nice to take even more advantage and further optimize for cases like
if (!("property" in object))
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