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:
- Change the
src2
ofAluRM
fromGpr
toGprMemImm
,- Add the corresponding encoding.
- Change the
alu_rm
constructor to takeGprMemImm
- Change the
x64_add_mem
&co constructors to takeGprMemImm
.This is a bit stupid since
AluRM
already takes a memory operand, so there is no way to encode theMem
part ofGprMemImm
. I guess maybe we could introduceRegImm
andGprImm
types. But that feels wrong and redundant.Related issue where this first was brought up https://github.com/bytecodealliance/wasmtime/issues/1925
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:
- Change the
src2
ofAluRM
fromGpr
toGprMemImm
,- Add the corresponding encoding.
- Change the
alu_rm
constructor to takeGprMemImm
- Change the
x64_add_mem
&co constructors to takeGprMemImm
.This is a bit stupid since
AluRM
already takes a memory operand, so there is no way to encode theMem
part ofGprMemImm
. I guess maybe we could introduceRegImm
andGprImm
types. But that feels wrong and redundant.Related issue where this first was brought up https://github.com/bytecodealliance/wasmtime/issues/1925
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:
- Change the
src2
ofAluRM
fromGpr
toGprMemImm
,- Add the corresponding encoding.
- Change the
alu_rm
constructor to takeGprMemImm
- Change the
x64_add_mem
&co constructors to takeGprMemImm
.This is a bit stupid since
AluRM
already takes a memory operand, so there is no way to encode theMem
part ofGprMemImm
. I guess maybe we could introduceRegImm
andGprImm
types. But that feels wrong and redundant.Related issue where this first was brought up https://github.com/bytecodealliance/wasmtime/issues/1925
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:
- Change the
src2
ofAluRM
fromGpr
toGprMemImm
,- Add the corresponding encoding.
- Change the
alu_rm
constructor to takeGprMemImm
- Change the
x64_add_mem
&co constructors to takeGprMemImm
.This is a bit stupid since
AluRM
already takes a memory operand, so there is no way to encode theMem
part ofGprMemImm
. I guess maybe we could introduceRegImm
andGprImm
types. But that feels wrong and redundant.Related issue where this first was brought up https://github.com/bytecodealliance/wasmtime/issues/1925
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:
- Change the
src2
ofAluRM
fromGpr
toGprMemImm
,- Add the corresponding encoding.
- Change the
alu_rm
constructor to takeGprMemImm
- Change the
x64_add_mem
&co constructors to takeGprMemImm
.This is a bit stupid since
AluRM
already takes a memory operand, so there is no way to encode theMem
part ofGprMemImm
. I guess maybe we could introduceRegImm
andGprImm
types. But that feels wrong and redundant.Related issue where this first was brought up https://github.com/bytecodealliance/wasmtime/issues/1925
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 23 2024 at 12:05 UTC