We're doing much better than d8, but a profile of the JSNES shell benchmark shows 8% of time spent in the VM multiplying values, which is suspicious.
Is this for a JSOP_POS maybe? It could be the same issue as bug 1131537...
Yeah, it appears to be for JSOP_POS. The value flowing into the MMul is, e.g. (not in analysis mode): TypeBarrier(CallGetProperty(Object, "lengthCounter")) where "lengthCounter" is initialized to null, reset to integer 0, and usually an integer. So although static analysis would tell us that it can be Object null, baseline caches should only see Int32.
It appears that TI claims to know nothing about these accesses.
I just saw a underscore benchmark that spends 37% of its runtime in MulValues: http://jsperf.com/underscore-indexof-binary/2#chart=bar
Oh this is bug 1131537.