Support WASM's V128 as Rust u128 in Func::wrap() ?

[cylewitruk]

Thanks for filing a feature request! Please fill out the TODOs below.

Feature

Wondering why V128 isn't supported in Func::wrap()? Both Walrus and Wasmer seem to allow V128's to be used in host functions mapped as u128's. I know this wasn't the "intended" use for V128's, but it would sure be nice for host functions, at least in Rust :)

Benefit

Would allow passing of 128-bit numbers to/from host-functions without the need to split them into two parameters including lower and upper bits.

Implementation

Haven't looked into the Wasmtime internals, so no comment.

Alternatives

• Passing two i64's low+high bits and bitwising them apart/together (fast, but boilerplate needed).
• Using ExternRef's to pass u/i128's (slow)
• Open to other suggestions...?

[alexcrichton]

I've been meaning to dust off this branch for some time now!

[cylewitruk]

Well look at that! I searched issues and PR's before opening this and didn't find anything, but looks like it was hiding in a branch :) That would be really awesome, actually. We're currently evaluating Wasmtime as the runtime for stacks.co VM runtime for its Clarity language. As all numbers are currently treated as 128-bits, this would definitely save us some headaches! :D

[alexcrichton]

One thing to keep in mind perhaps is that v128 is generally intended for vector/simd operations right now so it may not be totally suitable for 128-bit numbers since there's nothing like v128.add which performs a 128-bit addition. You may get more mileage out of pairs of u64 depending on your use case.

Additionally most engines may not be that optimal at this time passing around v128 as parameters and results. The v128 type is generally thought of "you use this in your hot inner loop and that's it". One example is that Cranelift/Wasmtime follow System-V which means that on RISC-V for example all arguments/results are passed through memory rather than in registers.

Not to say that this isn't a good use case, just figured it might be worth giving a heads up! I personally think it'd be reasonable to improve these sorts of issues if they arise. If you're interested in running on other engines though it might be worth testing there too

[cylewitruk]

Very informed input, and good information for anyone else who might be wondering the same thing!

In our case we're aware of the limitations and that v128 was meant primarily for simd operations - we're currently passing low/high u64 pairs back-and-forth, but this does incur a slight overhead in host functions instead of simply being able to, for example, u128::from_le_bytes(...).

[alexcrichton]

Ok sounds good! I forgot to close this earlier but this was solved by #7010.

If you notice any performance issues though in this area (or others) please let us know!