Cranelift ARM64 (AArch64) backend: fix remaining failing tests / correctness holes #1521
Assignees
Labels
bug
Incorrect behavior in the current implementation that needs fixing
cranelift:area:aarch64
Issues related to AArch64 backend.
cranelift:area:machinst
Issues related to instruction selection and the new MachInst backend.
cranelift
Issues related to the Cranelift code generator
Comments
cfallin
added
bug
Subscribe to Label Actioncc @bnjbvr
This issue or pull request has been labeled: "cranelift"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this issue
Apr 16, 2020
This commit enhances our CI with an AArch64 builder. Currently we have no physical hardware to run on so for now we run all tests in an emulator. The AArch64 build is cross-compiled from x86_64 from Linux. Tests all happen in release mode with a recent version of QEMU (recent version because it's so much faster, and in release mode because debug mode tests take quite a long time in an emulator). The goal here was not to get all tests passing on CI, but rather to get AArch64 running on CI and get it green at the same time. To achieve that goal many tests are now ignored on aarch64 platforms. Many tests fail due to unimplemented functionality in the aarch64 backend (bytecodealliance#1521), and all wasmtime tests involving compilation are also disabled due to panicking attempting to generate generate instruction offset information for trap symbolication (bytecodealliance#1523). Despite this, though, all Cranelift tests and other wasmtime tests should be runnin on AArch64 through QEMU with this PR. Additionally we'll have an AArch64 binary release of Wasmtime for Linux, although it won't be too useful just yet since it will panic on almost all wasm modules.
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this issue
Apr 16, 2020
This commit enhances our CI with an AArch64 builder. Currently we have no physical hardware to run on so for now we run all tests in an emulator. The AArch64 build is cross-compiled from x86_64 from Linux. Tests all happen in release mode with a recent version of QEMU (recent version because it's so much faster, and in release mode because debug mode tests take quite a long time in an emulator). The goal here was not to get all tests passing on CI, but rather to get AArch64 running on CI and get it green at the same time. To achieve that goal many tests are now ignored on aarch64 platforms. Many tests fail due to unimplemented functionality in the aarch64 backend (bytecodealliance#1521), and all wasmtime tests involving compilation are also disabled due to panicking attempting to generate generate instruction offset information for trap symbolication (bytecodealliance#1523). Despite this, though, all Cranelift tests and other wasmtime tests should be runnin on AArch64 through QEMU with this PR. Additionally we'll have an AArch64 binary release of Wasmtime for Linux, although it won't be too useful just yet since it will panic on almost all wasm modules.
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this issue
Apr 17, 2020
This commit enhances our CI with an AArch64 builder. Currently we have no physical hardware to run on so for now we run all tests in an emulator. The AArch64 build is cross-compiled from x86_64 from Linux. Tests all happen in release mode with a recent version of QEMU (recent version because it's so much faster, and in release mode because debug mode tests take quite a long time in an emulator). The goal here was not to get all tests passing on CI, but rather to get AArch64 running on CI and get it green at the same time. To achieve that goal many tests are now ignored on aarch64 platforms. Many tests fail due to unimplemented functionality in the aarch64 backend (bytecodealliance#1521), and all wasmtime tests involving compilation are also disabled due to panicking attempting to generate generate instruction offset information for trap symbolication (bytecodealliance#1523). Despite this, though, all Cranelift tests and other wasmtime tests should be runnin on AArch64 through QEMU with this PR. Additionally we'll have an AArch64 binary release of Wasmtime for Linux, although it won't be too useful just yet since it will panic on almost all wasm modules.
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this issue
Apr 20, 2020
This commit enhances our CI with an AArch64 builder. Currently we have no physical hardware to run on so for now we run all tests in an emulator. The AArch64 build is cross-compiled from x86_64 from Linux. Tests all happen in release mode with a recent version of QEMU (recent version because it's so much faster, and in release mode because debug mode tests take quite a long time in an emulator). The goal here was not to get all tests passing on CI, but rather to get AArch64 running on CI and get it green at the same time. To achieve that goal many tests are now ignored on aarch64 platforms. Many tests fail due to unimplemented functionality in the aarch64 backend (bytecodealliance#1521), and all wasmtime tests involving compilation are also disabled due to panicking attempting to generate generate instruction offset information for trap symbolication (bytecodealliance#1523). Despite this, though, all Cranelift tests and other wasmtime tests should be runnin on AArch64 through QEMU with this PR. Additionally we'll have an AArch64 binary release of Wasmtime for Linux, although it won't be too useful just yet since it will panic on almost all wasm modules.
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this issue
Apr 21, 2020
This commit enhances our CI with an AArch64 builder. Currently we have no physical hardware to run on so for now we run all tests in an emulator. The AArch64 build is cross-compiled from x86_64 from Linux. Tests all happen in release mode with a recent version of QEMU (recent version because it's so much faster, and in release mode because debug mode tests take quite a long time in an emulator). The goal here was not to get all tests passing on CI, but rather to get AArch64 running on CI and get it green at the same time. To achieve that goal many tests are now ignored on aarch64 platforms. Many tests fail due to unimplemented functionality in the aarch64 backend (bytecodealliance#1521), and all wasmtime tests involving compilation are also disabled due to panicking attempting to generate generate instruction offset information for trap symbolication (bytecodealliance#1523). Despite this, though, all Cranelift tests and other wasmtime tests should be runnin on AArch64 through QEMU with this PR. Additionally we'll have an AArch64 binary release of Wasmtime for Linux, although it won't be too useful just yet since it will panic on almost all wasm modules.
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this issue
Apr 22, 2020
This commit enhances our CI with an AArch64 builder. Currently we have no physical hardware to run on so for now we run all tests in an emulator. The AArch64 build is cross-compiled from x86_64 from Linux. Tests all happen in release mode with a recent version of QEMU (recent version because it's so much faster, and in release mode because debug mode tests take quite a long time in an emulator). The goal here was not to get all tests passing on CI, but rather to get AArch64 running on CI and get it green at the same time. To achieve that goal many tests are now ignored on aarch64 platforms. Many tests fail due to unimplemented functionality in the aarch64 backend (bytecodealliance#1521), and all wasmtime tests involving compilation are also disabled due to panicking attempting to generate generate instruction offset information for trap symbolication (bytecodealliance#1523). Despite this, though, all Cranelift tests and other wasmtime tests should be runnin on AArch64 through QEMU with this PR. Additionally we'll have an AArch64 binary release of Wasmtime for Linux, although it won't be too useful just yet since it will panic on almost all wasm modules.
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this issue
Apr 22, 2020
This commit enhances our CI with an AArch64 builder. Currently we have no physical hardware to run on so for now we run all tests in an emulator. The AArch64 build is cross-compiled from x86_64 from Linux. Tests all happen in release mode with a recent version of QEMU (recent version because it's so much faster, and in release mode because debug mode tests take quite a long time in an emulator). The goal here was not to get all tests passing on CI, but rather to get AArch64 running on CI and get it green at the same time. To achieve that goal many tests are now ignored on aarch64 platforms. Many tests fail due to unimplemented functionality in the aarch64 backend (bytecodealliance#1521), and all wasmtime tests involving compilation are also disabled due to panicking attempting to generate generate instruction offset information for trap symbolication (bytecodealliance#1523). Despite this, though, all Cranelift tests and other wasmtime tests should be runnin on AArch64 through QEMU with this PR. Additionally we'll have an AArch64 binary release of Wasmtime for Linux, although it won't be too useful just yet since it will panic on almost all wasm modules.
alexcrichton
added a commit
that referenced
this issue
Apr 22, 2020
* Add AArch64 tests to CI This commit enhances our CI with an AArch64 builder. Currently we have no physical hardware to run on so for now we run all tests in an emulator. The AArch64 build is cross-compiled from x86_64 from Linux. Tests all happen in release mode with a recent version of QEMU (recent version because it's so much faster, and in release mode because debug mode tests take quite a long time in an emulator). The goal here was not to get all tests passing on CI, but rather to get AArch64 running on CI and get it green at the same time. To achieve that goal many tests are now ignored on aarch64 platforms. Many tests fail due to unimplemented functionality in the aarch64 backend (#1521), and all wasmtime tests involving compilation are also disabled due to panicking attempting to generate generate instruction offset information for trap symbolication (#1523). Despite this, though, all Cranelift tests and other wasmtime tests should be runnin on AArch64 through QEMU with this PR. Additionally we'll have an AArch64 binary release of Wasmtime for Linux, although it won't be too useful just yet since it will panic on almost all wasm modules. * Review comments
cfallin
added a commit
to cfallin/wasmtime
that referenced
this issue
Apr 23, 2020
Previously, `fcopysign` was mysteriously failing to pass the `float_misc` spec test. This was tracked down to bad logical-immediate masks used to separate the sign and not-sign bits. In particular, the masks for the and-not operations were wrong. The `invert()` function on an `ImmLogic` immediate, it turns out, assumed every immediate would be used by a 64-bit instruction; `ImmLogic` immediates are subtly different for 32-bit instructions. This change tracks the instruction size (32 or 64 bits) intended for use with each such immediate, and passes it back into `maybe_from_u64` when computing the inverted immediate. Addresses one of the failures (`float_misc`) for bytecodealliance#1521 (test failures) and presumably helps bytecodealliance#1519 (SpiderMonkey integration).
cfallin
added a commit
to cfallin/wasmtime
that referenced
this issue
Apr 23, 2020
Previously, `fcopysign` was mysteriously failing to pass the `float_misc` spec test. This was tracked down to bad logical-immediate masks used to separate the sign and not-sign bits. In particular, the masks for the and-not operations were wrong. The `invert()` function on an `ImmLogic` immediate, it turns out, assumed every immediate would be used by a 64-bit instruction; `ImmLogic` immediates are subtly different for 32-bit instructions. This change tracks the instruction size (32 or 64 bits) intended for use with each such immediate, and passes it back into `maybe_from_u64` when computing the inverted immediate. Addresses several of the failures (`float_misc`, `f32_bitwise`) for bytecodealliance#1521 (test failures) and presumably helps bytecodealliance#1519 (SpiderMonkey integration).
cfallin
added a commit
to cfallin/wasmtime
that referenced
this issue
Apr 23, 2020
Previously, `fcopysign` was mysteriously failing to pass the `float_misc` spec test. This was tracked down to bad logical-immediate masks used to separate the sign and not-sign bits. In particular, the masks for the and-not operations were wrong. The `invert()` function on an `ImmLogic` immediate, it turns out, assumed every immediate would be used by a 64-bit instruction; `ImmLogic` immediates are subtly different for 32-bit instructions. This change tracks the instruction size (32 or 64 bits) intended for use with each such immediate, and passes it back into `maybe_from_u64` when computing the inverted immediate. Addresses several of the failures (`float_misc`, `f32_bitwise`) for bytecodealliance#1521 (test failures) and presumably helps bytecodealliance#1519 (SpiderMonkey integration).
cfallin
added a commit
to cfallin/wasmtime
that referenced
this issue
Apr 23, 2020
Previously, `fcopysign` was mysteriously failing to pass the `float_misc` spec test. This was tracked down to bad logical-immediate masks used to separate the sign and not-sign bits. In particular, the masks for the and-not operations were wrong. The `invert()` function on an `ImmLogic` immediate, it turns out, assumed every immediate would be used by a 64-bit instruction; `ImmLogic` immediates are subtly different for 32-bit instructions. This change tracks the instruction size (32 or 64 bits) intended for use with each such immediate, and passes it back into `maybe_from_u64` when computing the inverted immediate. Addresses several of the failures (`float_misc`, `f32_bitwise`) for bytecodealliance#1521 (test failures) and presumably helps bytecodealliance#1519 (SpiderMonkey integration).
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this issue
May 1, 2020
Looks like everything is in general passing now so it's probably time to close bytecodealliance#1521 and all other remaining tests that are failing are classified under new more focused issues. Closes bytecodealliance#1521
alexcrichton
added a commit
that referenced
this issue
May 1, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We've merged the initial aarch64 backend now (in #1494), but not all tests pass when executing on an aarch64 system. @alexcrichton is planning to add an aarch64 test run to the CI setup soon, initially adding directives to ignore the failing tests. We need to work through these tests and resolve all failures.
Also important for #1519: some of the failing SpiderMonkey tests likely are due to lingering edge-case correctness issues.
The text was updated successfully, but these errors were encountered: