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
{{ message }}
Repository navigation
Add a binaryen-shell pass to fold load/store index offsets into the wasm load/store immediate offsets. #19
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.
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.[/+]on 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.
Activity
kripken commentedon Dec 21, 2015
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).[-]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.[/+]sunfishcode commentedon 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
inboundsproperty ongetelementptr.kripken commentedon Dec 21, 2015
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.