Skip to content

Conversation

@alexcrichton
Copy link
Member

This resolves two issues from recent changes in #6649:

  • First the s390x calling convention for wasm functions is changed back to WasmtimeSystemV from Fast. This was an accidental omission from Remove Wasmtime ABIs from Cranelift #6649 where the conclusion was that s390x will continue using a calling convention with little-endian lane order for lane arguments. The only calling convention that supports this today is WasmtimeSystemV, although the Tail calling convention will likely use it in the future as well.

  • Second the apple-aarch64 platform now uses the Fast calling convention instead of AppleAarch64 calling convention. That convention was specified in CFI improvements to the AArch64 fiber implementation #4195 but local testing shows that is not necessary in the sense that tests all pass with the Fast calling convention. This means that the prior comment why the AppleAarch64 calling convention is required is no longer accurate and in the absence of a reason not to I went ahead and switched it to Fast.

In the near future all wasm functions will unconditionally use the Tail calling convention and at that time the lane order can be specified on s390x to be little-endian to satisfy all the constraints here. Additionally any unwinding directives, if necessary for aarch64, can be specified as needed.

This resolves two issues from recent changes in bytecodealliance#6649:

* First the s390x calling convention for wasm functions is changed back
  to `WasmtimeSystemV` from `Fast`. This was an accidental omission from
  bytecodealliance#6649 where the conclusion was that s390x will continue using a
  calling convention with little-endian lane order for lane arguments.
  The only calling convention that supports this today is
  `WasmtimeSystemV`, although the `Tail` calling convention will likely
  use it in the future as well.

* Second the apple-aarch64 platform now uses the `Fast` calling
  convention instead of `AppleAarch64` calling convention. That
  convention was specified in bytecodealliance#4195 but local testing shows that is not
  necessary in the sense that tests all pass with the `Fast` calling
  convention. This means that the prior comment why the `AppleAarch64`
  calling convention is required is no longer accurate and in the
  absence of a reason not to I went ahead and switched it to `Fast`.

In the near future all wasm functions will unconditionally use the
`Tail` calling convention and at that time the lane order can be
specified on s390x to be little-endian to satisfy all the constraints
here. Additionally any unwinding directives, if necessary for aarch64,
can be specified as needed.
@alexcrichton alexcrichton requested a review from a team as a code owner June 30, 2023 18:57
@alexcrichton alexcrichton requested review from itsrainy and removed request for a team June 30, 2023 18:57
@fitzgen fitzgen added this pull request to the merge queue Jul 6, 2023
Merged via the queue into bytecodealliance:main with commit 73405a4 Jul 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants