Wasmtime GitHub notifications bot (May 04 2022 at 22:02): Wasmtime GitHub notifications bot (May 04 2022 at 22:02):cfallin labeled issue #1082:
This is the continuation of the closed PR bytecodealliance/cranelift#624.
Spidermonkey uses a pinned register to contain the HeapBase on x64. It is supposed to be callee preserved, so we need a way to keep it alive (by passing it as an argument and returning it).
The simplest (and less efficient) way to implement it would be to allow forbidding registers by the Cranelift compiler, so Spidermonkey can preserve the semantics of keeping its HeapBase register untouched in Cranelift.
An alternative would be to have a Value holding the heap base, and reloading it before returning. Register allocation would take care of spilling it if needed. For the Spidermonkey case it's a bit unfortunate, because the function call stack frame contains a pointer to TLS state where we can reload the HeapBase register at will.
The best support would be to allow load/stores Cranelift instructions to have support for a heap base, so this optimization can be valuable to other implementations as well. I think we discussed this with @sunfishcode and there was yak shaving involved to make this work (related to the number of operands a given instruction can have? I am not sure to remember!).
Wasmtime GitHub notifications bot (May 04 2022 at 22:02):cfallin labeled issue #1082:
This is the continuation of the closed PR bytecodealliance/cranelift#624.
Spidermonkey uses a pinned register to contain the HeapBase on x64. It is supposed to be callee preserved, so we need a way to keep it alive (by passing it as an argument and returning it).
The simplest (and less efficient) way to implement it would be to allow forbidding registers by the Cranelift compiler, so Spidermonkey can preserve the semantics of keeping its HeapBase register untouched in Cranelift.
An alternative would be to have a Value holding the heap base, and reloading it before returning. Register allocation would take care of spilling it if needed. For the Spidermonkey case it's a bit unfortunate, because the function call stack frame contains a pointer to TLS state where we can reload the HeapBase register at will.
The best support would be to allow load/stores Cranelift instructions to have support for a heap base, so this optimization can be valuable to other implementations as well. I think we discussed this with @sunfishcode and there was yak shaving involved to make this work (related to the number of operands a given instruction can have? I am not sure to remember!).
Wasmtime GitHub notifications bot (Jun 22 2024 at 19:25):bjorn3 commented on issue #1082:
Is this still relevant?
Wasmtime GitHub notifications bot (Jun 22 2024 at 23:12):cfallin closed issue #1082:
This is the continuation of the closed PR bytecodealliance/cranelift#624.
Spidermonkey uses a pinned register to contain the HeapBase on x64. It is supposed to be callee preserved, so we need a way to keep it alive (by passing it as an argument and returning it).
The simplest (and less efficient) way to implement it would be to allow forbidding registers by the Cranelift compiler, so Spidermonkey can preserve the semantics of keeping its HeapBase register untouched in Cranelift.
An alternative would be to have a Value holding the heap base, and reloading it before returning. Register allocation would take care of spilling it if needed. For the Spidermonkey case it's a bit unfortunate, because the function call stack frame contains a pointer to TLS state where we can reload the HeapBase register at will.
The best support would be to allow load/stores Cranelift instructions to have support for a heap base, so this optimization can be valuable to other implementations as well. I think we discussed this with @sunfishcode and there was yak shaving involved to make this work (related to the number of operands a given instruction can have? I am not sure to remember!).
Wasmtime GitHub notifications bot (Jun 22 2024 at 23:12):cfallin commented on issue #1082:
I think we're unlikely to do something like this today due to multi-memory support (and expectation of significant use of it when components are common) and also regular accesses to other fields in
vmctxas well, making it necessary to keep that around anyway. Will go ahead and close.
Last updated: Nov 22 2024 at 16:03 UTC