Stream: git-wasmtime

Topic: wasmtime / Issue #1179 x86: Consistently permit REX prefi...

Wasmtime GitHub notifications bot (Feb 03 2021 at 18:26):

bjorn3 commented on Issue #1179:

Is this fixed with the new x64 backend?

Wasmtime GitHub notifications bot (Feb 03 2021 at 18:32):

abrown commented on Issue #1179:

This is very specific to the old backend, I vote we close it.

Wasmtime GitHub notifications bot (Feb 03 2021 at 18:32):

abrown closed Issue #1179:

It looks like our SIMD encodings waver between permitting and not permitting the REX prefix: compare uses of enc_32_64 and enc_both in x86/encoding.rs.

As a result, vector operations using r8-r15 as parts of a memory operand, or xmm8-xmm15 as a register operand, get rejected when searching for encodings and, I believe, result in Cranelift not using those xmm registers entirely in some circumstances (we're missing a rex-friendly MOVUPS encoding so I don't think we can encode a spill of xmm8-xmm15).

I ran across this trying to emit movups xmm7, [r11] when restoring SIMD registers in Windows prologues. This currently results in a constraint violation panic when compiling. I believe this is because I specified the location after inserting the instruction, so Cranelift picked the FPR8/GPR8-constrained encoding, and I just gave it an impossible operand, whereas regalloc would have been unable to use r11 as an operand and forced shuffling until a fitting register were available.

I'm pretty sure we can make the blanket change from enc_32_64 to enc_both for the region I linked above. However, I don't know the maybe_isap variants, and I figure it'd be better to confirm this before changing stuff around.

cc @abrown and @bnjbvr as people who've recently touched these things, I think?

Last updated: Dec 06 2025 at 06:05 UTC