Stream: git-wasmtime

Topic: wasmtime / PR #10632 asm: change how regalloc interacts w...

Wasmtime GitHub notifications bot (Apr 22 2025 at 01:00):

abrown opened PR #10632 from abrown:asm-operands-post-fixed to bytecodealliance:main:

This PR changes the paradigm for how a user (like regalloc2) will interact with the operands of an assembler instruction. Instead of using a visitor pattern, calling functions for each of the operands, this approach builds up a list of operands that expose &mut references to the underlying operands of the instruction.

While this does have the advantage of being a bit more straightforward, the motivation for this is more subtle: some instructions have special register constraints that the visitor pattern does not handle. E.g., when switching AluConstOp to use the new assembler, I noticed that the calls it makes to the register allocator are quite different than the visitor expects: AluConstOp boils down to xor %r*, %r* and expects us a completely different call to regalloc2: a single reg_def(). We would need to build a completely different visitor implementation for this.

Also, this refactoring makes it possible for users of the assembler to examine and modify any operands to any instruction. This should be useful regardless of the AluConstOp motivation.

<!--
Please make sure you include the following information:

• If this work has been discussed elsewhere, please include a link to that
  conversation. If it was discussed in an issue, just mention "issue #...".

• Explain why this change is needed. If the details are in an issue already,
  this can be brief.

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

Wasmtime GitHub notifications bot (Apr 22 2025 at 01:00):

abrown requested cfallin for a review on PR #10632.

Wasmtime GitHub notifications bot (Apr 22 2025 at 01:00):

abrown requested wasmtime-compiler-reviewers for a review on PR #10632.

Wasmtime GitHub notifications bot (Apr 22 2025 at 01:02):

abrown submitted PR review.

Wasmtime GitHub notifications bot (Apr 22 2025 at 01:02):

abrown created PR review comment:

We _could_ use a smallvec with a threshold of 4 and be a bit more efficient but I thought, for now, this was fine.

Wasmtime GitHub notifications bot (Apr 22 2025 at 02:59):

cfallin commented on PR #10632:

Hmm -- I have some serious concerns with this approach, and in particular, constructing a Vec of operands for each instruction during each visitor pass. We've worked hard to reduce allocations during compilation, and to operate on data in-place as much as possible; I would expect this to have a pretty nontrivial impact on all that, especially in the fullness of time when the migration of all instructions to the new assembler is complete. Basically: the "mutate in place" was hard-won, let's not give it up.

I suspect/hope there is an easier way to address the "differing constraints for some instructions" problem. In the xor case, we could adopt the approach we took with XMM zeroing, namely to have an "uninitialized value" virtual def instruction that assembles to nothing and then always emit that prior to (and only in the case of) an xor-zeroing idiom. What do you think?

Wasmtime GitHub notifications bot (Apr 29 2025 at 21:28):

abrown closed without merge PR #10632.

Wasmtime GitHub notifications bot (Apr 29 2025 at 21:28):

abrown commented on PR #10632:

The now-merged #10648 takes a different approach to this problem.

Last updated: Dec 06 2025 at 07:03 UTC