Just remembered that JM has an optimization to replace regexp_exec with regexp_test if the result of the call does not escape. E.g. see the following micro-benchmark: function f() { var x = 0; var re = /foo/; for (var i=0; i<10000000; i++) { if (re.exec("foo")) {}; } return x; } var t = new Date; f(); print(new Date - t); Ion : 7523 ms JM+TI : 662 ms

I think there's a problem with type barriers here, the interpreter calls regexp_exec and when JM/Ion calls regexp_test we see a new type and recompile. Since we're using JM as a baseline compiler, it should have the right types when Ion kicks in though.

Calling a different native seems easiest in codegen. We could do something more fancy with MIR def/use-analysis but this handles the most common cases, matches JM and TM and is just a few lines of code.

Let me know if you think we should do this somewhere else. It's a bit more complicated to do it earlier because we have to get the JSFunction instead of Native, but it's possible I think.

Comment on attachment 633085 [details] [diff] [review] Patch Review of attachment 633085 [details] [diff] [review]: ----------------------------------------------------------------- Yeah, I think this should be done elsewhere. There is additional complication if we are worried about strict correctness: visitCallNative() pushes the target JSFunction * onto the stack, since the allocated space for the outparam, vp[0], is initially defined to hold the callee. Since we have to know the JSFunction *, can we perform the target replacement in the IonBuilder?

Yeah, this makes a huge difference to v8-regexp.

OK, I will post an updated patch later today.

Performs the replacement in IonBuilder. A bit more complicated since we have to look up the JSFunction on the RegExp.prototype object, but it's pretty self-contained. Speeds up the micro-benchmark in this bug, but I don't see an improvement on v8-regexp with the default config. With --no-jm --ion-limit-script-size=off our score doubles though.

Comment on attachment 660772 [details] [diff] [review] Patch v2 Review of attachment 660772 [details] [diff] [review]: ----------------------------------------------------------------- As far as I can tell, the only change required is the following to jsop_call(): if (target->maybeNative() == regexp_exec && !CallResultEscapes(pc)) target = regexp_test; Is there some reason that looking through the prototype chain of the regexp object is useful? It doesn't seem that we need to know if test was replaced on the prototype, as we just want its behavior to replace exec.

Comment on attachment 660772 [details] [diff] [review] Patch v2 Review of attachment 660772 [details] [diff] [review]: ----------------------------------------------------------------- Blah, there's no reasonable way to get a JSFunction* to correspond to the regexp_test. Technically, we don't really need it at all -- it's just necessary for pushing vp[0] as the callee, but regexp_test never reads from that slot. But the ways to obviate the need for a JSFunction* aren't as pretty as I thought they would be. In the future, we should support this case even if test is redefined on the prototype, but it is not currently important enough for medium-sized refactoring work.