Stream: git-wasmtime

Topic: wasmtime / issue #4284 x64 load-op-store imm folding

view this post on Zulip Wasmtime GitHub notifications bot (Jun 17 2022 at 17:33):

pepyakin labeled issue #4284:

Right now the given CLIF

v1 = load.i32 v0+32
v2 = iconst.i32 2
v3 = iadd v1, v2
store v3, v0+32

generates the following assembly

movl    $2, %eax
addl    %eax, 32(%rdi)

However, x64 allows the following encoding

addl    $2, 32(%rdi)

I tried to fix that, by:

  1. Change the src2 of AluRM from Gpr to GprMemImm,
  2. Add the corresponding encoding.
  3. Change the alu_rm constructor to take GprMemImm
  4. Change the x64_add_mem&co constructors to take GprMemImm.

This is a bit stupid since AluRM already takes a memory operand, so there is no way to encode the Mem part of GprMemImm. I guess maybe we could introduce RegImm and GprImm types. But that feels wrong and redundant.

Related issue where this first was brought up https://github.com/bytecodealliance/wasmtime/issues/1925

view this post on Zulip Wasmtime GitHub notifications bot (Jun 17 2022 at 17:33):

pepyakin labeled issue #4284:

Right now the given CLIF

v1 = load.i32 v0+32
v2 = iconst.i32 2
v3 = iadd v1, v2
store v3, v0+32

generates the following assembly

movl    $2, %eax
addl    %eax, 32(%rdi)

However, x64 allows the following encoding

addl    $2, 32(%rdi)

I tried to fix that, by:

  1. Change the src2 of AluRM from Gpr to GprMemImm,
  2. Add the corresponding encoding.
  3. Change the alu_rm constructor to take GprMemImm
  4. Change the x64_add_mem&co constructors to take GprMemImm.

This is a bit stupid since AluRM already takes a memory operand, so there is no way to encode the Mem part of GprMemImm. I guess maybe we could introduce RegImm and GprImm types. But that feels wrong and redundant.

Related issue where this first was brought up https://github.com/bytecodealliance/wasmtime/issues/1925

view this post on Zulip Wasmtime GitHub notifications bot (Jun 17 2022 at 17:33):

pepyakin labeled issue #4284:

Right now the given CLIF

v1 = load.i32 v0+32
v2 = iconst.i32 2
v3 = iadd v1, v2
store v3, v0+32

generates the following assembly

movl    $2, %eax
addl    %eax, 32(%rdi)

However, x64 allows the following encoding

addl    $2, 32(%rdi)

I tried to fix that, by:

  1. Change the src2 of AluRM from Gpr to GprMemImm,
  2. Add the corresponding encoding.
  3. Change the alu_rm constructor to take GprMemImm
  4. Change the x64_add_mem&co constructors to take GprMemImm.

This is a bit stupid since AluRM already takes a memory operand, so there is no way to encode the Mem part of GprMemImm. I guess maybe we could introduce RegImm and GprImm types. But that feels wrong and redundant.

Related issue where this first was brought up https://github.com/bytecodealliance/wasmtime/issues/1925

view this post on Zulip Wasmtime GitHub notifications bot (Jun 17 2022 at 17:33):

pepyakin labeled issue #4284:

Right now the given CLIF

v1 = load.i32 v0+32
v2 = iconst.i32 2
v3 = iadd v1, v2
store v3, v0+32

generates the following assembly

movl    $2, %eax
addl    %eax, 32(%rdi)

However, x64 allows the following encoding

addl    $2, 32(%rdi)

I tried to fix that, by:

  1. Change the src2 of AluRM from Gpr to GprMemImm,
  2. Add the corresponding encoding.
  3. Change the alu_rm constructor to take GprMemImm
  4. Change the x64_add_mem&co constructors to take GprMemImm.

This is a bit stupid since AluRM already takes a memory operand, so there is no way to encode the Mem part of GprMemImm. I guess maybe we could introduce RegImm and GprImm types. But that feels wrong and redundant.

Related issue where this first was brought up https://github.com/bytecodealliance/wasmtime/issues/1925

view this post on Zulip Wasmtime GitHub notifications bot (Jun 17 2022 at 17:33):

pepyakin opened issue #4284:

Right now the given CLIF

v1 = load.i32 v0+32
v2 = iconst.i32 2
v3 = iadd v1, v2
store v3, v0+32

generates the following assembly

movl    $2, %eax
addl    %eax, 32(%rdi)

However, x64 allows the following encoding

addl    $2, 32(%rdi)

I tried to fix that, by:

  1. Change the src2 of AluRM from Gpr to GprMemImm,
  2. Add the corresponding encoding.
  3. Change the alu_rm constructor to take GprMemImm
  4. Change the x64_add_mem&co constructors to take GprMemImm.

This is a bit stupid since AluRM already takes a memory operand, so there is no way to encode the Mem part of GprMemImm. I guess maybe we could introduce RegImm and GprImm types. But that feels wrong and redundant.

Related issue where this first was brought up https://github.com/bytecodealliance/wasmtime/issues/1925

view this post on Zulip Wasmtime GitHub notifications bot (Jul 07 2022 at 17:28):

cfallin commented on issue #4284:

Hi @pepyakin -- sorry for the delayed response here. I think introducing RegImm is actually exactly what we want here: it models the possibilities given by the instruction in the type system. I'm happy to review a PR if you want to try your hand at that, otherwise we can save this issue for some future "codegen quality" sprint. Thanks!

Last updated: Dec 13 2025 at 21:03 UTC