TI has an optimization to ignore overflow (or negative zero) checks for binary operators if the result is used by a bitwise op. We should also use this for jsop_mod. The attached test case from azakai has this line: (g * g + a) % 256 & 255 jsop_mod sometimes results in -0 here and we'll always call a stub, but we can ignore the negative zero here.

Btw, g * g overflows to double, that's probably hard to inline for JSOP_MOD. But if emscripten could convert the operand to int32 first, like this: ((g * g + a)|0) % 256 & 255 we might be able to do everything inline after we get rid of the -0 check. (And we should also optimize MOD power-of-2 to something more efficient)

It would be good to avoid an inline stub call for (int % int) == double; have the inline path make an int where possible and convert it to double. Other paths would benefit from this too, e.g. Math natives like round() that can make -1 (see bug 606648 comment 6).