You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In most cases it is fine to fold an asm.js load/store offset into the wasm load/store offset. It will fail on some rare code when the pre-offset index is a signed value (wasm interprets it as unsigned with infinite precision), but to help us get some benchmarks out and develop the binary encoding could this be a command line option that defaults to off?
You might recall a big sage a year ago in emscripten with this being rejected there as 'not wanted', and I had to maintain an emscripten fork with this support, but perhaps people have conceded it's worth the burden now, or that at least it could help us get some testing done until the llvm wasm backend pipeline is more useful. The rebased emscripten patches are still at https://github.com/JSStats/emscripten if they are of any use.
The text was updated successfully, but these errors were encountered:
We could write a simple pass that does this, then it would be easy to do testing on it (just run binaryen-shell -offsetize input.wast).
ghost
changed the title
asm2wasm: load/store offsets are not being translated to wasm load/store immediate offsets.
Add a binaryen-shell pass to fold load/store index offsets into the wasm load/store immediate offsets.
Dec 21, 2015
Note that it's not semantically valid in all cases to do this transformation at the asm.js level, because asm.js code may depend on the value being wrapped, while wasm's offsets are defined to be non-wrapping. That said, this may be a useful thing to implement for now, because it'll probably work in most cases, and it'll be more representative of what we hope to have in production in the future.
I have patches in progress which implement offset folding with non-wrapping semantics in the LLVM wasm backend using the inbounds property on getelementptr.
Yeah, definitely not valid to do in general at the asm level. But a pass might be nice for testing, as 99% of the changes are valid to do, so e.g. it would give a good picture of binary size changes even with 1% wrong semantics.
In most cases it is fine to fold an asm.js load/store offset into the wasm load/store offset. It will fail on some rare code when the pre-offset index is a signed value (wasm interprets it as unsigned with infinite precision), but to help us get some benchmarks out and develop the binary encoding could this be a command line option that defaults to off?
You might recall a big sage a year ago in emscripten with this being rejected there as 'not wanted', and I had to maintain an emscripten fork with this support, but perhaps people have conceded it's worth the burden now, or that at least it could help us get some testing done until the llvm wasm backend pipeline is more useful. The rebased emscripten patches are still at https://github.com/JSStats/emscripten if they are of any use.
The text was updated successfully, but these errors were encountered: