Introduce IR BinaryOps for unsigned division and remainder. #5171
Conversation
| expectedFastLinkSize = 147046, | ||
| expectedFullLinkSizeWithoutClosure = 85355, | ||
| expectedFullLinkSizeWithClosure = 21492, | ||
| expectedFastLinkSize = 148624, |
There was a problem hiding this comment.
Just to check my understanding: This is because of (signed) integer division now being inlined more strongly? (IMO OK).
There was a problem hiding this comment.
Not really. The bulk of it is the unsigned div/mod methods of RuntimeLong, which are now unconditionally retained:
https://gist.github.com/sjrd/7ed63b130ce471a24480869f8f784dc6
That is a fixed cost.
GCC manages to get rid of them, but other JS optimizers would not be able to do that. Ideally, one day we should only conditionally reach the methods of RuntimeLong depending on which Long_x operators are used, but it's probably not really worth the trouble.
In a larger codebase, this is compensated by the fact that the unsigned divisions produce much shorter (and better) code now.
There was a problem hiding this comment.
Ah, I see. OK, that's acceptable. Maybe an alternative could be to emit runtime long methods as static methods, so it would be easier for JS optimizers to get rid of them. (it's not entirely clear to me how easy that would be in practice :-/).
There was a problem hiding this comment.
It would be nice for them to be static, indeed. At the top-level we can do this by reaching the static forwarders, and forcing the module instance methods to be inlined into those. However, for divisions in particular, they are not entirely inlined. They use several non-inlined helpers. So those need to perform the LoadModule anyway, and that makes the static forwarders not so great for them.
Then again, if we actually have to call the division methods, we are in a bad place anyway, performance-wise. I'll follow up with attempts at doing that.
In the meantime, I'll wait to merge #5158 first, since they will conflict on the size checks, and I'd rather rebase this PR against #5158 than the other way around.
This allows to better mutualize their implementation with the signed divisions. Moreover, our 3 implementation strategies (JS with `RuntimeLong`, JS with `bigint` and Wasm) have different efficient implementations of those operations. Using IR BinaryOps for them allows each backend to use the most appropriate implementation, while letting the optimizer generically manipulate their mathematical properties.
This allows to better mutualize their implementation with the signed divisions.
Moreover, our 3 implementation strategies (JS with
RuntimeLong, JS withbigintand Wasm) have different efficient implementations of those operations. Using IR BinaryOps for them allows each backend to use the most appropriate implementation, while letting the optimizer generically manipulate their mathematical properties.