Closed alexcrichton closed 2 years ago
I'll take a look...
The following ISLE code is doing the lowering:
In the snippet above, it looks like max
is assigned v7V
and b
should be assigned the value coming from a load (i.e., v3V
). But that load has been coalesced into the first operand of pmaxub
(i.e.,64(%v0J)
). @fitzgen, @alexcrichton: I can't remember how to avoid this load coalescing, though...
Correction: I can turn off load coalescing manually with the following, which fixes the issue:
diff --git a/cranelift/codegen/src/isa/x64/lower.rs b/cranelift/codegen/src/isa/x64/lower.rs
index 3b9341420..6cc265be2 100644
--- a/cranelift/codegen/src/isa/x64/lower.rs
+++ b/cranelift/codegen/src/isa/x64/lower.rs
@@ -137,6 +137,10 @@ fn is_mergeable_load<C: LowerCtx<I = Inst>>(
return None;
}
+ if load_ty.is_vector() {
+ return None;
+ }
+
// SIMD instructions can only be load-coalesced when the loaded value comes
// from an aligned address.
if load_ty.is_vector() && !insn_data.memflags().map_or(false, |f| f.aligned()) {
But that is not the right approach. What I meant is that there may have been a way to prevent this kind of thing from happening when an operand was resused but I can't remember exactly how Chris would do it.
I'm not really here (out of office and vanishing after this comment!) but this is the same issue as 3934 I think. Compares need explicit put_in_reg, not implicit reg or mem.
(sorry for not catching that in review, it's subtle!)
Thanks @cfallin! That's exactly what I couldn't remember!
A fuzz bug came in over the weekend and bisection points to https://github.com/bytecodealliance/wasmtime/pull/3886 as the cause. This wasm module:
fails with:
The non-minimized reproduction is here