Cranelift: cannot generate relocation against libcall FloorF64, when has_sse41=false

[zeldovich]

.wat Test Case

(module
  (type (;0;) (func (param f64) (result f64)))
  (func $f (type 0) (param f64) (result f64)
    local.get 0
    f64.floor))

Steps to Reproduce

• wasmtime run --wasm-features=-simd --cranelift-set has_sse41=false testcase.wat

Expected Results

I would expect wasmtime / cranelift to be able to compile this code on a machine with has_sse41=false. (In particular, this shows up in a QEMU VM.)

Actual Results

I get an error:

thread 'main' panicked at 'not implemented: cannot generate relocation against libcall FloorF64', crates/cranelift/src/obj.rs:155:21

Versions and Environment

Cranelift version or commit: 4.0.0

Operating system: Linux 6.1.3

Architecture: x86_64; the problem shows up in a QEMU VM where has_sse41=false, but can also be observed outside of a QEMU VM by explicitly passing has_sse41=false like above.

[alexcrichton]

Thanks for the report! I believe this is a bug where it was mistakenly assumed that SSE4.2 would always be available, but that's only for when simd is enabled, not for the general baseline. This I think used to work in Wasmtime some time ago but I think I broke it with refactorings a year or so ago.

That being said this seems reasonable to me to support, but supporting this will require a bit of careful planning. The main trickiness here is that this would be the first-of-its-kind to be a relocation that needs to be resolved when an object is loaded. Currently Wasmtime has no relocations to support at that time which improves the load time of objects. Supporting this will be somewhat nontrivial but I still think is reasonable to implement.