Differences of value types in immediate value instruction function signatures

[aibor]

I am debugging an issue that is only present with IPv4 addresses with most significant bit set using JumpOp.Imm. It is fixed by using JumpOp.Imm32

Looking at the signatures I am wondering why some 64bit immediate instructions take int64 (which meets my expectation) while others take int32.

Examples using int64:

func LoadImm(dst Register, value int64, size Size) Instruction
func StoreImm(dst Register, offset int16, value int64, size Size) Instruction

Examples using int32:

func (op JumpOp) Imm(dst Register, value int32, label string) Instruction
func (op ALUOp) Imm(dst Register, value int32) Instruction

Is there a reason why the later take int32 instead of int64? The value is casted to int64 in both functions anyway. The documentation for JumpOp.Imm even says that it compares 64bit values. My expectation would be that they should take the value as int64.

[lmb]

func StoreImm(dst Register, offset int16, value int64, size Size) Instruction

This is probably a bug: #1767

Is there a reason why the later take int32 instead of int64?

The BPF ISA only allows 32 bit immediates / constants, except for the special case of a 64bit LoadImm into a register, which is turned into two BPF instructions. For ease of use we chose to represent Constant as 64bit so that this detail of the ISA doesn't leak into our abstraction.

The reason Imm is confusing is that it needs to be understood together with Imm32. From the top of my head, haven't validated this:

Imm: if (dst == (int64)i32_const) { ... }
Imm32: if ((int32)((uint32)dst) == i32_const) { ... }

The reason that the top bit makes a difference is probably because it is interpreted as the sign bit.