Skip to content

x64: Migrate div instructions to the new assembler #10820

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 5 commits into from
May 22, 2025

Conversation

alexcrichton
Copy link
Member

This mostly required adding a new kind of operand representing a TrapCode and plumbing around a few bits and bobs to ensure that this compile-time-only-abstraction does not need to be accounted for in all the encoding bits.

@alexcrichton alexcrichton requested a review from abrown May 20, 2025 22:51
@alexcrichton alexcrichton requested a review from a team as a code owner May 20, 2025 22:51
@github-actions github-actions bot added cranelift Issues related to the Cranelift code generator cranelift:area:x64 Issues related to x64 codegen cranelift:meta Everything related to the meta-language. winch Winch issues or pull requests labels May 21, 2025
Copy link

Subscribe to Label Action

cc @saulecabrera

This issue or pull request has been labeled: "cranelift", "cranelift:area:x64", "cranelift:meta", "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.

Comment on lines 88 to 93
pub fn trap() -> Operand {
Operand {
implicit: true,
..Operand::from(Location::trap)
}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

What if instead of "trap as an Operand" we add a field like Inst::trap? I'm concerned that trap codes aren't really operands after all and that we already have a TrapCode hidden away in the Amode with all of its own machinery. Seems like it would be better to:

  • define all instructions that can trap with something like inst(...).can_trap()
  • decide whether we truly need to pass around trap codes in ISLE or if we can define them earlier, e.g., .can_trap(242)

Copy link
Member Author

Choose a reason for hiding this comment

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

Tried it out and I like it better too 👍

This mostly required adding a new kind of operand representing a
`TrapCode` and plumbing around a few bits and bobs to ensure that this
compile-time-only-abstraction does not need to be accounted for in all
the encoding bits.
Reduces the size of `KnownOffset` so `Option<KnownOffset>` doesn't have
such a high alignment or size, greatly shrinking the size of the
instruction and prevents the changes to `Div` from increasing the size
of the overall `Inst` enum. In fact it now shrinks!
Copy link
Contributor

@abrown abrown left a comment

Choose a reason for hiding this comment

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

Nice!

@abrown abrown added this pull request to the merge queue May 22, 2025
Merged via the queue into bytecodealliance:main with commit b4f041f May 22, 2025
53 checks passed
@alexcrichton alexcrichton deleted the x64-div branch May 22, 2025 16:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cranelift:area:x64 Issues related to x64 codegen cranelift:meta Everything related to the meta-language. cranelift Issues related to the Cranelift code generator winch Winch issues or pull requests
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants