Some recent benchmarking had a surprising result I wasn't trying to dig for. Notably as summarized in #11 some more use cases of widening multiplication being more optimal than 128-by-128 bit multiplication have started to arise. Coupled with local benchmarking confirming that both on x64 and aarch64 that widening multiplication has more support in LLVM for more optimal lowerings and was easier to implement in Wasmtime than the 128-by-128 bit multiplication once various optimizations were implemented.
In the end i64.mul128, which was primarily motivated by "feels cleaner" and "should have the same performance" as widening multiplication, does not appear to have the expected performance/implementation tradeoff. Getting an as-performant i64.mul128 instruction relative to i64.mul_wide_{s,u} has required more work than expected and so the balance of concerns has me now tipping away from i64.mul128, despite it being "less clean" compared to the add/sub opcodes proposed in this PR.
Some recent benchmarking had a surprising result I wasn't trying to dig for. Notably as summarized in #11 some more use cases of widening multiplication being more optimal than 128-by-128 bit multiplication have started to arise. Coupled with local benchmarking confirming that both on x64 and aarch64 that widening multiplication has more support in LLVM for more optimal lowerings and was easier to implement in Wasmtime than the 128-by-128 bit multiplication once various optimizations were implemented.
In the end
i64.mul128, which was primarily motivated by "feels cleaner" and "should have the same performance" as widening multiplication, does not appear to have the expected performance/implementation tradeoff. Getting an as-performanti64.mul128instruction relative toi64.mul_wide_{s,u}has required more work than expected and so the balance of concerns has me now tipping away fromi64.mul128, despite it being "less clean" compared to the add/sub opcodes proposed in this PR.Closes #11