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!).
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!).
bjorn3 commented on issue #1082:
Is this still relevant?
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!).
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
vmctx
as well, making it necessary to keep that around anyway. Will go ahead and close.
Last updated: Dec 23 2024 at 13:07 UTC