Stream: git-wasmtime

Topic: wasmtime / issue #5430 Don't report moves for fixed_nonal...

Wasmtime GitHub notifications bot (Dec 14 2022 at 00:38):

elliottt commented on issue #5430:

Looks like this isn't quite solved yet: the s390x tests that are failing are due to not recording an entry in the is_move map of the vcode table for the move that puts the result of the atomic_rmw instruction into %r2 before returning.

Attempting a local fix by recording Operand::fixed_nonallocatable constraints in is_move when appropriate instead of avoiding adding an entry at all hits a bug in regalloc2 where we're assuming that a fixed constraint returned by is_move must always be a pinned vreg, and not a fixed-nonallocatable register.

Wasmtime GitHub notifications bot (Dec 14 2022 at 01:01):

elliottt commented on issue #5430:

The last problem here was that moves weren't making it into the final output. The problem was that in the VCode::emit function we were skipping all instructions that satisfied MachInst::is_move, which includes the moves that we didn't report to regalloc2. The solution was to reuse the VCode::is_move map rather than calling MachInst::is_move, as presence in that map corresponds directly to whether or not we told regalloc2 about the move.

Wasmtime GitHub notifications bot (Dec 14 2022 at 01:50):

elliottt commented on issue #5430:

@uweigand I've reworked this a bit more to avoid the changes to VCode. The problem was that there was a move using a fixed non-allocatable register produced by the s390x backend in the casloop_emit function. I've reworked this to use MovPReg, which is designed to handle fixed non-allocatable sources, but this does introduce some additional indirection for the result.

Last updated: Dec 06 2025 at 06:05 UTC