GitHub (Feb 25 2020 at 04:48): GitHub (Feb 25 2020 at 04:48):shravanrn edited Issue #1083:
This bug is in the context of use of Cranelift to generate wasm sandboxed libraries for use in Firefox - i.e. this is a non web embedding. Full details available here https://bugzilla.mozilla.org/show_bug.cgi?id=1562797
We are using lucet as our wasm compiler which uses Cranelift under the covers. For performance reasons, we need to optimize transitions between native code and wasm sandboxed code beyond what lucet provides out of the box. Key to this is generating efficient trampoline functions that minimize overhead.
To this end we have rewritten trampolines that make a few assumptions based on " properties derivable from the WASM spec about register and stack use of a WASM compiler". These assumptions reduces overhead when using a sandboxed version of libGraphite by several 100's of percent.
Since this is something indirectly implied from the WASM spec, I am hoping that Cranelift can guarantee these and wanted to confirm if these are OK.
There are 3 assumptions - one about stacks, and two about register use
1) Assembly functions generated by Cranelift WASM never underflows the stack
- This is guaranteed from the WASM spec due to the fact that WASM functions are proper stack machines
- This would allow us to use the same stack for the application and wasm module
- However, our reliance on this depends on how bug-free we think Cranelift's conversion from the WASM stack machine
2) Assembly functions generated by Cranelift never reads an uninitialized register
- This is an outcome of all function calls to WASM and within WASM (including indirect jumps) being typesafe.
- This means there should never be code generated that reads from a scratch register prior to writing to it.
- This also means there should never be code generate for a function that takes 2 parameters, that attempts to read a value from the register that would hold a third parameter (if it had existed)
- This allows us to avoid clearing scratch and unused parameter registers during WASM function invocation.
3) Assembly functions generated by Cranelift always restore callee save registers
- Like point 2, this is an outcome of all functions being typesafe combined with the fact that WASM is a stack machine, which cannot manipulate the stack in a way that affects register spills.
- This means that there should no path through the function that would result in a callee save register not being restored
- This allows us to avoid explicitly restoring registers on the way out
GitHub (Feb 25 2020 at 06:42):shravanrn commented on Issue #1083:
(Updating title as we want to point people to this bug until we can update docs)
GitHub (Feb 28 2020 at 23:26):alexcrichton transferred Issue #1083:
This bug is in the context of use of Cranelift to generate wasm sandboxed libraries for use in Firefox - i.e. this is a non web embedding. Full details available here https://bugzilla.mozilla.org/show_bug.cgi?id=1562797
We are using lucet as our wasm compiler which uses Cranelift under the covers. For performance reasons, we need to optimize transitions between native code and wasm sandboxed code beyond what lucet provides out of the box. Key to this is generating efficient trampoline functions that minimize overhead.
To this end we have rewritten trampolines that make a few assumptions based on " properties derivable from the WASM spec about register and stack use of a WASM compiler". These assumptions reduces overhead when using a sandboxed version of libGraphite by several 100's of percent.
Since this is something indirectly implied from the WASM spec, I am hoping that Cranelift can guarantee these and wanted to confirm if these are OK.
There are 3 assumptions - one about stacks, and two about register use
1) Assembly functions generated by Cranelift WASM never underflows the stack
- This is guaranteed from the WASM spec due to the fact that WASM functions are proper stack machines
- This would allow us to use the same stack for the application and wasm module
- However, our reliance on this depends on how bug-free we think Cranelift's conversion from the WASM stack machine
2) Assembly functions generated by Cranelift never reads an uninitialized register
- This is an outcome of all function calls to WASM and within WASM (including indirect jumps) being typesafe.
- This means there should never be code generated that reads from a scratch register prior to writing to it.
- This also means there should never be code generate for a function that takes 2 parameters, that attempts to read a value from the register that would hold a third parameter (if it had existed)
- This allows us to avoid clearing scratch and unused parameter registers during WASM function invocation.
3) Assembly functions generated by Cranelift always restore callee save registers
- Like point 2, this is an outcome of all functions being typesafe combined with the fact that WASM is a stack machine, which cannot manipulate the stack in a way that affects register spills.
- This means that there should no path through the function that would result in a callee save register not being restored
- This allows us to avoid explicitly restoring registers on the way out
Last updated: Nov 22 2024 at 16:03 UTC