Wasmtime GitHub notifications bot (Sep 24 2020 at 20:54): Wasmtime GitHub notifications bot (Sep 24 2020 at 20:54):akirilov-arm opened PR #2228 from vector_callee_saves to main:
This PR adds a test case for a function that saves clobbered vector registers on the stack.
Its purpose is to demonstrate that Cranelift deviates from the Procedure Call Standard for the Arm 64-bit Architecture (AAPCS64). The AAPCS64 specifies that a callee is only responsible for saving the bottom 64 bits of a vector register, so it is not possible to preserve a vector value across a function call by keeping it in a callee-saved register (let's ignore the Scalable Vector Extension for the time being, but keep in mind that it makes the rules more complicated).
Due to another deviation from AAPCS64 (the whole vector register is saved instead of only the bottom half), Cranelift effectively implements its own custom calling convention, so there are no correctness issues as long as the generated code calls only functions with the same behaviour.
The wider question is - are we striving for strict AAPCS64 compliance? That's in the non-baldrdash case, of course. I can also open an issue if a longer discussion would be necessary.
cc @cfallin @julian-seward1
Wasmtime GitHub notifications bot (Sep 29 2020 at 21:12):akirilov-arm updated PR #2228 from vector_callee_saves to main:
This PR adds a test case for a function that saves clobbered vector registers on the stack.
Its purpose is to demonstrate that Cranelift deviates from the Procedure Call Standard for the Arm 64-bit Architecture (AAPCS64). The AAPCS64 specifies that a callee is only responsible for saving the bottom 64 bits of a vector register, so it is not possible to preserve a vector value across a function call by keeping it in a callee-saved register (let's ignore the Scalable Vector Extension for the time being, but keep in mind that it makes the rules more complicated).
Due to another deviation from AAPCS64 (the whole vector register is saved instead of only the bottom half), Cranelift effectively implements its own custom calling convention, so there are no correctness issues as long as the generated code calls only functions with the same behaviour.
The wider question is - are we striving for strict AAPCS64 compliance? That's in the non-baldrdash case, of course. I can also open an issue if a longer discussion would be necessary.
cc @cfallin @julian-seward1
Wasmtime GitHub notifications bot (Sep 30 2020 at 13:31):akirilov-arm updated PR #2228 from vector_callee_saves to main:
This PR adds a test case for a function that saves clobbered vector registers on the stack.
Its purpose is to demonstrate that Cranelift deviates from the Procedure Call Standard for the Arm 64-bit Architecture (AAPCS64). The AAPCS64 specifies that a callee is only responsible for saving the bottom 64 bits of a vector register, so it is not possible to preserve a vector value across a function call by keeping it in a callee-saved register (let's ignore the Scalable Vector Extension for the time being, but keep in mind that it makes the rules more complicated).
Due to another deviation from AAPCS64 (the whole vector register is saved instead of only the bottom half), Cranelift effectively implements its own custom calling convention, so there are no correctness issues as long as the generated code calls only functions with the same behaviour.
The wider question is - are we striving for strict AAPCS64 compliance? That's in the non-baldrdash case, of course. I can also open an issue if a longer discussion would be necessary.
cc @cfallin @julian-seward1
Last updated: Dec 23 2024 at 12:05 UTC