Stream: git-wasmtime

Topic: wasmtime / PR #10413 Cranelift: avoid integer-shift optim...

Wasmtime GitHub notifications bot (Mar 17 2025 at 19:30):

cfallin requested fitzgen for a review on PR #10413.

Wasmtime GitHub notifications bot (Mar 17 2025 at 19:30):

cfallin opened PR #10413 from cfallin:now-shift-to-the-left-now-shift-to-the-right-everybody-do-the-ireduce to bytecodealliance:main:

An optimization rule in our mid-end implemented the following equivalence:

    (x << N) >> N == x as T1 as T2

where T1 is a smaller integer type and T2 is a larger integer type, and N is the difference in bitwidths between them. In other words, when a left-then-right-shift clears the upper bits (or sign-extends them), we can implement that by reducing to a smaller type then extending back to the original type.

Unfortunately, ireduce is not valid on vector-of-integer types. A fuzzbug reported in #10409 shows that this pattern results in invalid CLIF when optimizing this pattern with an i64x2 as input.

This PR tightens the rule's LHS to only apply to integer types.

Note that there is another optimization rule that can also implement this behavior with a bitwise AND with a mask. Previously the two resulting expressions had the same cost in the egraph, and whatever perturbation occurred in the ISLE compilation of the rule (which is a multi-constructor because this is the mid-end, so is returning multiple results) caused that rule's result to be picked instead during extraction. I've also tweaked the costs to make reduces/extends cheaper than ordinary arithmetic as a result, to keep the same optimizer outputs after extraction. One x64 test in particular showed why this is correct: the mask-with-AND resulted in two instructions (move, AND-with-immediate) while a uextend can be done with one (zero-extending move, movzbl), and aarch64 has similar builtin extends in many cases.

Fixes #10409.

<!--
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 (Mar 17 2025 at 19:30):

cfallin requested wasmtime-compiler-reviewers for a review on PR #10413.

Wasmtime GitHub notifications bot (Mar 17 2025 at 19:43):

fitzgen submitted PR review:

Thanks!

Wasmtime GitHub notifications bot (Mar 17 2025 at 19:43):

fitzgen has enabled auto merge for PR #10413.

Wasmtime GitHub notifications bot (Mar 17 2025 at 20:15):

fitzgen merged PR #10413.

Last updated: Apr 16 2025 at 19:03 UTC