Branching off Bug 798668 Comment 3, emitInstanceOf() does not contain the same path as fun_hasInstance() in which a primitive .prototype triggers an error. > x = y = String.slice > try { > print(((function () { > (x instanceof y) > }))()) > } catch (e) {} > > Here's another testcase that when tested on 32-bit js shell on m-c changeset > 70337fa2fe62, without --ion-eager shows no output (presumably a newline), > but with --ion-eager shows: > > undefined

This reminds me of bug 787050 - I'd be happy to see this whole path get reimplemented. It's not really sound in IonMonkey to combine opcodes like this. I think Crankshaft generates a specialized IC, and JSC splits INSTANCEOF into multiple opcodes.

autoBisect shows this is probably related to the following changeset: The first good revision is: changeset: 114177:d3ed5864b6eb user: Nicolas B. Pierron date: Mon Nov 26 19:08:37 2012 -0800 summary: Bug 814177 - Use a callVM for generic InstanceOf cases. r=dvander Nicolas, is this a possible fix?

(In reply to Gary Kwong [:gkw] from comment #2) > The first good revision is: > changeset: 114177:d3ed5864b6eb > user: Nicolas B. Pierron > date: Mon Nov 26 19:08:37 2012 -0800 > summary: Bug 814177 - Use a callVM for generic InstanceOf cases. > r=dvander > > Nicolas, is this a possible fix? Yes, it is. Even if this is not a duplicate, the fact that the impl was not identical has been fixed in this Bug as well as in Bug 814861.