V8-raytrace does this. I figure others might want to do that as well, since it seems like a sensible thing to do. This bug doesn't extend to going all out and optimizing the case where in a==b both a and b can be either null or object, since I don't yet have evidence that there are enough hot spots in the code out there that do that. Patch forthcoming.
Created attachment 134666 [details] work in progress Almost done, but still need to do 32-bit and run some more tests. Putting up for EWS to see that my 64-bit code doesn't make non-Mac ports sad.
Comment on attachment 134666 [details] work in progress Attachment 134666 [details] did not pass qt-wk2-ews (qt): Output: http://queues.webkit.org/results/12194493
Comment on attachment 134666 [details] work in progress Attachment 134666 [details] did not pass qt-ews (qt): Output: http://queues.webkit.org/results/12212042
Comment on attachment 134666 [details] work in progress Attachment 134666 [details] did not pass gtk-ews (gtk): Output: http://queues.webkit.org/results/12206020
Created attachment 134708 [details] the patch It appears to work now.
Comment on attachment 134708 [details] the patch CompareEq should always predict bool shouldn't it? It would seem easier to just do a single forNode(nodeIndex).set(PredictBoolean); in the AbstractState logic for it? r=me
(In reply to comment #6) > (From update of attachment 134708 [details]) > CompareEq should always predict bool shouldn't it? It would seem easier to just do a single forNode(nodeIndex).set(PredictBoolean); in the AbstractState logic for it? You might have a point there. ;-) I will make the change that you speak of.
Landed in http://trac.webkit.org/changeset/112762