Bugzilla

And two final notes:

It would have been interesting to try to avoid the PSP altogether for Ion wasm code.  It's not clear why it's needed.  There's *one* MIR/LIR node used by Wasm that performs an explicit push; any other push/pop logic is hidden in the masm.  It would for sure be interesting to look into this, but it looks like it could be a lot of work and I would prefer for us just to understand how the PSP is supposed to work and make the code work with it.

Since the ARM64 SP is weird and the SP has a code (63 in vixl) that does not fit in the register set, there's a hack in the JIT, JS_HIDDEN_SP, that is enabled on ARM64, that treats the SP differently and introduces some constraints (that are checked by the type system).  I have been toying with removing this restriction, now that we have larger register sets and the SP could have code 32, say, and I have a patch tucked away for that, but there are lots of assumptions in the systems about things not going beyond 32 bits and I never got this fully working.  So I think this is a useful exploration but not on the critical path for Ion-on-ARM64, and it does not address the SP/PSP problem either.

And two final notes:

It would have been interesting to try to avoid the PSP altogether for Ion wasm code.  It's not clear why it's needed.  There's *one* MIR/LIR node used by Wasm (visitWasmBuiltinModD) that performs an explicit push; any other push/pop logic is hidden in the masm.  It would for sure be interesting to look into this, but it looks like it could be a lot of work and I would prefer for us just to understand how the PSP is supposed to work and make the code work with it.

Since the ARM64 SP is weird and the SP has a code (63 in vixl) that does not fit in the register set, there's a hack in the JIT, JS_HIDDEN_SP, that is enabled on ARM64, that treats the SP differently and introduces some constraints (that are checked by the type system).  I have been toying with removing this restriction, now that we have larger register sets and the SP could have code 32, say, and I have a patch tucked away for that, but there are lots of assumptions in the systems about things not going beyond 32 bits and I never got this fully working.  So I think this is a useful exploration but not on the critical path for Ion-on-ARM64, and it does not address the SP/PSP problem either.

And two final notes:

It would have been interesting to try to avoid the PSP altogether for Ion wasm code.  It's not clear why it's needed.  There's *one* MIR/LIR node used by Wasm (visitWasmBuiltinModD) that performs an explicit push; any other push/pop logic is hidden in the masm.  Also, getting rid of the PSP probably means making the SP a "normal" register, which means making the MoveResolver play along, which means getting rid of JS_HIDDEN_SP, see next. It would for sure be interesting to look into this, but it looks like it could be a lot of work and I would prefer for us just to understand how the PSP is supposed to work and make the code work with it.  

Since the ARM64 SP is weird and the SP has a code (63 in vixl) that does not fit in the register set, there's a hack in the JIT, JS_HIDDEN_SP, that is enabled on ARM64, that treats the SP differently and introduces some constraints (that are checked by the type system).  I have been toying with removing this restriction, now that we have larger register sets and the SP could have code 32, say, and I have a patch tucked away for that, but there are lots of assumptions in the systems about things not going beyond 32 bits and I never got this fully working.  So I think this is a useful exploration but not on the critical path for Ion-on-ARM64, and it does not address the SP/PSP problem either.

And two final notes:

It would have been interesting to try to avoid the PSP altogether for Ion wasm code.  It's not clear why it's needed.  There's *one* MIR/LIR node used by Wasm (visitWasmBuiltinModD) that performs an explicit push; any other push/pop logic is hidden in the masm.  Also, getting rid of the PSP probably means making the SP a "normal" register in order for the MoveResolver play along, which means getting rid of JS_HIDDEN_SP, see next. It would for sure be interesting to look into this, but it looks like it could be a lot of work and I would prefer for us just to understand how the PSP is supposed to work and make the code work with it.  

Since the ARM64 SP is weird and the SP has a code (63 in vixl) that does not fit in the register set, there's a hack in the JIT, JS_HIDDEN_SP, that is enabled on ARM64, that treats the SP differently and introduces some constraints (that are checked by the type system).  I have been toying with removing this restriction, now that we have larger register sets and the SP could have code 32, say, and I have a patch tucked away for that, but there are lots of assumptions in the systems about things not going beyond 32 bits and I never got this fully working.  So I think this is a useful exploration but not on the critical path for Ion-on-ARM64, and it does not address the SP/PSP problem either.