Skip to content

winch: Crank the ratchet on tests that can fail #10829

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jun 11, 2025

Conversation

alexcrichton
Copy link
Member

@alexcrichton alexcrichton commented May 23, 2025

This commit moves all "ignore these outright" tests for Winch and
AArch64 to "run the test and expect failure" after recent PRs which
removed most of the segfaults/etc which prevented running these tests.
One failure remained which was easy enough to fix here: the cmov
implementation only worked on integer registers, not floating-point
registers, leading to a panic. A helper was added for floating-point selects to
resolve this panic and get some tests passing.

After this fix the ignore method is no longer necessary as all tests
can be run and be flagged as either pass or fail.

@alexcrichton alexcrichton requested review from a team as code owners May 23, 2025 00:25
@alexcrichton alexcrichton requested review from abrown, dicej and saulecabrera and removed request for a team, abrown and dicej May 23, 2025 00:25
@github-actions github-actions bot added the winch Winch issues or pull requests label May 23, 2025
Copy link

Subscribe to Label Action

cc @saulecabrera

This issue or pull request has been labeled: "winch"

Thus the following users have been cc'd because of the following labels:

  • saulecabrera: winch

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

Copy link
Member

@saulecabrera saulecabrera left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Glad that we can avoid ignoring tests. Thanks for this! Left one small comment inline.

saulecabrera added a commit to saulecabrera/wasmtime that referenced this pull request May 30, 2025
This commit is the first step toward simplifying constant handling,
particularly for the aarch64 backend.

The main highlights in this patch are:

* Introduction of `ConstantPool` implemenetation on top of Cranlift
primitives
* Usage of the constant pool from aarch64, which simplifies the
loading of constants, particularly floating point constants.

The main motivation behind this change is to _eventually_ detach the
implicit usage of the scatch register from constant loading as much as
possible, reducing the possibility of subtle bugs (like the one
described in bytecodealliance#10829).

Note that this I have a work-in-progress branch from where all these
changes are cherry picked from to make everything easier to review.
saulecabrera added a commit to saulecabrera/wasmtime that referenced this pull request May 31, 2025
This commit is the first step toward simplifying constant handling,
particularly for the aarch64 backend.

The main highlights in this patch are:

* Introduction of `ConstantPool` implemenetation on top of Cranlift
  primitives. The implemettaion is identical to the existing for x64,
  however, it's abstracted so that it can be easily consumed from any
  existing backend.
* Usage of the constant pool from aarch64, which simplifies the
  loading of constants, particularly floating point constants.

The main motivation behind this change is to _eventually_ detach the
implicit usage of the scatch register from constant loading as much as
possible, reducing the possibility of subtle bugs (like the one
described in bytecodealliance#10829).

Note that I have a work-in-progress branch from where all these
changes are cherry picked from, to make everything easier to review.

A side effect of this change, is the improvement to the code
generation involving floating point constants. Prior to this change,
multiple moves were involved, with this patch, at most 1 move is
required and at worst one load is required.
saulecabrera added a commit to saulecabrera/wasmtime that referenced this pull request May 31, 2025
This commit is the first step toward simplifying constant handling,
particularly for the aarch64 backend.

The main highlights in this patch are:

* Introduction of `ConstantPool` implemenetation on top of Cranlift
  primitives. The implemettaion is identical to the existing for x64,
  however, it's abstracted so that it can be easily consumed from any
  existing backend.
* Usage of the constant pool from aarch64, which simplifies the
  loading of constants, particularly floating point constants.

The main motivation behind this change is to _eventually_ detach the
implicit usage of the scatch register from constant loading as much as
possible, reducing the possibility of subtle bugs (like the one
described in bytecodealliance#10829).

Note that I have a work-in-progress branch from where all these
changes are cherry picked from, to make everything easier to review.

A side effect of this change, is the improvement to the code
generation involving floating point constants. Prior to this change,
multiple moves were involved, with this patch, at most 1 move is
required and at worst one load is required.
saulecabrera added a commit to saulecabrera/wasmtime that referenced this pull request Jun 2, 2025
This commit is the first step toward simplifying constant handling,
particularly for the aarch64 backend.

The main highlights in this patch are:

* Introduction of `ConstantPool` implemenetation on top of Cranlift
  primitives. The implemettaion is identical to the existing for x64,
  however, it's abstracted so that it can be easily consumed from any
  existing backend.
* Usage of the constant pool from aarch64, which simplifies the
  loading of constants, particularly floating point constants.

The main motivation behind this change is to _eventually_ detach the
implicit usage of the scatch register from constant loading as much as
possible, reducing the possibility of subtle bugs (like the one
described in bytecodealliance#10829).

Note that I have a work-in-progress branch from where all these
changes are cherry picked from, to make everything easier to review.

A side effect of this change, is the improvement to the code
generation involving floating point constants. Prior to this change,
multiple moves were involved, with this patch, at most 1 move is
required and at worst one load is required.
github-merge-queue bot pushed a commit that referenced this pull request Jun 3, 2025
* winch(aarch64): implify constant handling, part 1/N

This commit is the first step toward simplifying constant handling,
particularly for the aarch64 backend.

The main highlights in this patch are:

* Introduction of `ConstantPool` implemenetation on top of Cranlift
  primitives. The implemettaion is identical to the existing for x64,
  however, it's abstracted so that it can be easily consumed from any
  existing backend.
* Usage of the constant pool from aarch64, which simplifies the
  loading of constants, particularly floating point constants.

The main motivation behind this change is to _eventually_ detach the
implicit usage of the scatch register from constant loading as much as
possible, reducing the possibility of subtle bugs (like the one
described in #10829).

Note that I have a work-in-progress branch from where all these
changes are cherry picked from, to make everything easier to review.

A side effect of this change, is the improvement to the code
generation involving floating point constants. Prior to this change,
multiple moves were involved, with this patch, at most 1 move is
required and at worst one load is required.

* Update disassembly tests

* Apply refactored constant handling on top of shared float min/max implementation

* `fmt`
@alexcrichton alexcrichton marked this pull request as draft June 10, 2025 14:48
This commit moves all "ignore these outright" tests for Winch and
AArch64 to "run the test and expect failure" after recent PRs which
removed most of the segfaults/etc which prevented running these tests.
One failure remained which was easy enough to fix here: the `cmov`
implementation only worked on integer registers, not floating-point
registers, leading to a panic. A helper was added for floating-point selects to
resolve this panic and get some tests passing.

After this fix the `ignore` method is no longer necessary as all tests
can be run and be flagged as either pass or fail.
@alexcrichton alexcrichton marked this pull request as ready for review June 10, 2025 19:23
@alexcrichton
Copy link
Member Author

Ok now a much smaller PR with all the previous fixes, thanks @saulecabrera! Now this just has a change for fpu_csel plus removing the ignore method, meaning all tests are run in aarch64 right now (although many are still expected to fail)

Copy link
Member

@saulecabrera saulecabrera left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@saulecabrera
Copy link
Member

all tests are run in aarch64 right now (although many are still expected to fail)

I'm currently looking into it.

@saulecabrera saulecabrera added this pull request to the merge queue Jun 10, 2025
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Jun 10, 2025
@alexcrichton
Copy link
Member Author

Reproduced that failure locally and it required a new self.with_aligned_sp during codegen for the wasm unreachable instruction.

@alexcrichton alexcrichton enabled auto-merge June 11, 2025 00:42
@alexcrichton alexcrichton added this pull request to the merge queue Jun 11, 2025
Merged via the queue into bytecodealliance:main with commit 070387a Jun 11, 2025
41 checks passed
@alexcrichton alexcrichton deleted the winch-ratchet branch June 11, 2025 01:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
winch Winch issues or pull requests
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants