Stream: git-wasmtime

Topic: wasmtime / issue #2252 `Inst` abstraction in x64 backend

Wasmtime GitHub notifications bot (Aug 28 2025 at 16:08):

abrown closed issue #2252:

As mentioned by @cfallin in https://github.com/bytecodealliance/wasmtime/pull/2248#discussion_r497853577, there is a potential abstraction leak re: Inst. The way I see it, Inst was originally designed to have variants that abstracted common classes of instructions (e.g. div) but eventually grew variants that more closely matched x64 encoding formats (e.g. unary_rm_r). Now Inst contains both kinds--abstract instructions and encoding formats--and this causes confusion (e.g. which format am I supposed to use here? Or is there an instruction that covers this?) and potential bugs (e.g. handing an opcode to a format that should never encode that opcode as @bnjbvr has pointed out). This problem will only be exacerbated by adding other types of encoding formats like VEX and EVEX.

I see several possible directions:

• refactor Inst to only contain abstract instructions
• refactor Inst to only contain x64 encoding formats and figure out some way to limit opcodes to certain formats (this is tricky because the same opcode can be used in multiple formats)
• refactor Inst to contain only x64 instructions, perhaps parameterized; I have mentioned before that I feel that the level of abstraction for lowering is at the machine code instruction (like in v8)

Thoughts?

Last updated: Dec 06 2025 at 07:03 UTC