Lowering i32x4.splat + f64x2.convert_low_i32x4 results in panic

[ShinWonho]

Test Case

;; unsigned.wat
(module
  (func (export "foo") (result v128)
    (i32.const 0)
    (i32x4.splat)
    (f64x2.convert_low_i32x4_u)
  )
)

;; signed.wat
(module
  (func (export "foo") (result v128)
    (i32.const 0)
    (i32x4.splat)
    (f64x2.convert_low_i32x4_s)
  )
)

Steps to Reproduce

wasmtime unsigned.wat
wasmtime signed.wat

Expected Results

Terminate without any errors

Actual Results

thread '<unnamed>' panicked at cranelift/codegen/src/machinst/lower.rs:766:21:
should be implemented in ISLE: inst = `v6 = fcvt_from_uint.f64x2 v13  ; v13 = const0`, type = `Some(types::F64X2)`
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
zsh: abort      wasmtime unsigned.wat

thread '<unnamed>' panicked at cranelift/codegen/src/machinst/lower.rs:766:21:
should be implemented in ISLE: inst = `v6 = fcvt_from_sint.f64x2 v13  ; v13 = const0`, type = `Some(types::F64X2)`
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
zsh: abort      wasmtime signed.wat

Versions and Environment

Wasmtime version or commit: wasmtime-cli 18.0.2 (90db6e9 2024-02-28)

Operating system & Architecture:

1. Server

• OS: Ubuntu 18.04.3 LTS (Bionic Beaver)
• Arc: x86_64

2. IMac

• OS: Monterey 12.6.2
• Arc: x86_64

Extra Info

It is not reproduced in

1. M1 MacBook Air

• OS: Sonoma 14.3.1
• Arc: Arm64

2. MacBook Pro

• Monterey 12.6.3
• Arc: x86_64

[fitzgen]

Thanks for the bug report!

[github-actions]

Subscribe to Label Action

cc @cfallin, @fitzgen

Details

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

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

• cfallin: isle
• fitzgen: isle

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

Learn more.

[alexcrichton]

This was "introduced" in #7859 which was backported to the 18.0.0 release in #7878. I say "introduced" here because this was sort of always a bug and that PR just happened to expose it, it's not directly caused by that PR per se.

Fuzzing later found this bug which resulted in #7915 as a band-aid fix for the issue followed up with #7919 for a "real fix" for at least the unsigned case. We'd forgotten about the signed case though (oops!) so I can work on that.

I'll note though that the band-aid of #7915 means that this issue doesn't reproduce as-is on main today.

[alexcrichton]

I posted #8099 for the missing signed conversion, but AFAIK that's just "good to have" and isn't require for correct operation on main.

The release-19.0.0 branch has all the various fixes there as well, so the only question remaining I think is effectively whether or not we want to backport #7915 to the 18.0.x branch.

[alexcrichton]

I think we're more-or-less done with this now so I'm going to close this.