It's just checking the Class, should speed up for-of on an array.

Patch adds a new HasClass MIR/LIR instruction and uses it to inline intrinsic_IsArrayIterator and intrinsic_isStringIterator. Though note that in many cases (like the test in bug 874580) we don't even use this instruction: we can use type information to fold the call completely. This wins about 5-10% on Jason's test in bug 874580 (GC is the main problem).

Comment on attachment 824579 [details] [diff] [review] Patch Review of attachment 824579 [details] [diff] [review]: ----------------------------------------------------------------- Looks good. One thought: are there prototype objects for ArrayIterator and StringIterator that have the appropriate class? There's already a HaveSameClass intrinsic and corresponding inlines. ::: js/src/jit/LIR-Common.h @@ +5259,5 @@ > > +class LHasClass : public LInstructionHelper<1, 1, 0> > +{ > + public: > + LIR_HEADER(HasClass); Nit: no ; ::: js/src/jit/MCallOptimize.cpp @@ +1392,5 @@ > IonBuilder::InliningStatus > +IonBuilder::inlineHasClass(CallInfo &callInfo, const Class *expected) > +{ > + JS_ASSERT(callInfo.argc() == 1); > + JS_ASSERT(!callInfo.constructing()); I guess it's a matter of taste whether these should be checked and return InliningStatus_NotInlined or asserted since intrinsics should be called correctly always. I've been preferring checking and returning InliningStatus_NotInlined for a less cryptic error instead of crashing in IonBuilder. @@ +1414,5 @@ > + current->add(hasClass); > + current->push(hasClass); > + > + return InliningStatus_Inlined; > + Nit: extra newline ::: js/src/jit/MIR.h @@ +8691,5 @@ > + setMovable(); > + } > + > + public: > + INSTRUCTION_HEADER(HasClass); Nit: no ;

Bug 976504 contains a more up-to-date implementation of HasClass.

Sorry totally forgot about this. Duping forward to bug 1111159, it has a more up-to-date patch.