abrown opened PR #10580 from abrown:asm-flags to bytecodealliance:main:
This change replaces ISLE lowerings for the
ProducesFlagsandConsumesFlagswrappers with instructions from the new assembler. This is a necessary step towards fully using the new assembler for ALU instructions (AluRmiRis only used for zeroing registers now).A couple items of note:
- there are a few places where
lower.islewants to abstract over some subset of ALU operations to avoid repetition; this change retains that via somex64_*_flagshelpers that take a new type (ChainFlagsOp, e.g.) that restricts which operations the helper can use. This is not a major refactor but it does show that we use these flag-producing instructions in quite limited ways.- we previously decided to keep rules that used wider versions of registers for i8/i16 operations to avoid CPU dependencies; this is problematic for instructions that rely on overflow, though, so this change extracts those "wider register" rules into
x64_*_break_depshelpers.<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
abrown updated PR #10580.
abrown has marked PR #10580 as ready for review.
abrown requested wasmtime-compiler-reviewers for a review on PR #10580.
abrown requested cfallin for a review on PR #10580.
cfallin submitted PR review:
Nice! I like the factoring here -- once the low-level helpers are out of the way, the application of this to each instruction is pretty straightforward.
cfallin created PR review comment:
Can we add a comment here that this should only be provided an instruction that actually produces flags, and is meant to be used by helpers that bind it with explicit instructions? In other words, it's semantically "unsafe" in the Rust sense and has to be used in the right way to uphold invariants.
abrown updated PR #10580.
abrown has enabled auto merge for PR #10580.
abrown merged PR #10580.
Last updated: Dec 06 2025 at 07:03 UTC