Stream: git-wasmtime

Topic: wasmtime / PR #11097 x64: Refactor backend condition hand...

Wasmtime GitHub notifications bot (Jun 21 2025 at 23:06):

alexcrichton opened PR #11097 from alexcrichton:x64-refactor-conditions to bytecodealliance:main:

This commit represents a refactor of the x64 backend's handling of condition codes for various instructions with a goal of simplifying conversion of a Value to a condition code used for select and brif. This additionally tries to deduplicate handling of condition codes across icmp and fcmp for example.

Previously the x64 backend had types such as IcmpCondResult and FcmpCondResult which respresented the condition codes for the icmp and fcmp values. When used in select, brif, or trap{n,}z each lowering had to special case icmp and fcmp to create these *CondResult values and call specialized helpers to lower the value back. Furthermore on the select instruction this created a matrix of ways-to-produce-the-condition-code along with
ways-to-handle-the-condition-code to conditionally move GPR, XMM, or 128-bit values. The end result was a fair bit of duplication across rules and optimizations on some rules but not others. For example brif on a vall_true value was optimized but select was not.

The design implemented in this commit is inspired/modeled after what the riscv64 backend is currently doing. There is a top-level helper is_nonzero_cmp which takes a Value and produces a CondResult. This CondResult is a merging of IcmpCondResult and FcmpCondResult into one. This centralizes the ability to take any value and produce condition codes, for example this handles icmp, fcmp, 128-bit integers, v{all,any}_true, etc. Once the condition is produced it's then handled separately at each location for jumps, selects, traps, etc. In effect CondResult serves as a "narrow waist" through which production of condition codes can all flow meaning that if an optimization is added for production of condition codes all instructions benefit instead of having to hand-update each one.

The goal of this refactoring was to not actually change any lowerings and only refactor internals, but this refactoring exposed a few non-optimal lowerings in the backend which were improved as a result of this change. In the future I plan on additionally adding more ways to pattern-match "produces a condition" which will now equally benefit all of these locations.

<!--
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.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

Wasmtime GitHub notifications bot (Jun 21 2025 at 23:06):

alexcrichton requested wasmtime-compiler-reviewers for a review on PR #11097.

Wasmtime GitHub notifications bot (Jun 21 2025 at 23:06):

alexcrichton requested abrown for a review on PR #11097.

Wasmtime GitHub notifications bot (Jun 21 2025 at 23:06):

alexcrichton requested fitzgen for a review on PR #11097.

Wasmtime GitHub notifications bot (Jun 21 2025 at 23:06):

alexcrichton requested wasmtime-core-reviewers for a review on PR #11097.

Wasmtime GitHub notifications bot (Jun 23 2025 at 18:26):

abrown submitted PR review:

I think this makes sense to me but @fitzgen you may want to double-check the Spectre-related changes.

Wasmtime GitHub notifications bot (Jun 24 2025 at 14:49):

fitzgen submitted PR review:

Nice!

Wasmtime GitHub notifications bot (Jun 24 2025 at 15:11):

fitzgen merged PR #11097.

Last updated: Dec 06 2025 at 06:05 UTC