There are a number of operations in Wasm that are i32 only, mainly because they are deemed booleans, primarily among them if, br_if and select. Because pointers were 32-bit, and testing a null-pointer is a very frequent operation, these could be used with pointers.

But so far in this proposal we do not have this functionality. 32-bit code like:

local.get $ptr
if

Now has to be emitted as:

local.get $ptr
i64.eqz
i32.eqz
if

Or (1 more byte):

local.get $ptr
i64.const 0
i64.ne
if

Though I'm sure this has no consequences in most engines, it is extra code size, and if we want Memory64 to be on equal footing, I think it be worth considering 64-bit versions of these instructions (or making them polymorphic).

More minor concerns being that it requires special casing in producers, and is just less readable.

It may not be super frequent in C/C++/Rust code, but imagine higher level languages that emit null checks on each memory access.

We already have code in Binaryen that emits extra truncates for checking alignment, for example.

Another instruction to consider is call_indirect that always takes an i32 index. Thing is, that index is what many producers will consider a function pointer. For example, we already have code in LLVM to emit truncates here, because we store these indices in an i64 for uniformity with other kinds of pointers in the wasm64 target. This is less likely to be performance sensitive than the above example though, but could be considered out of uniformity.

Question is, when?

1. It could be added to the current proposal because it is a minor change.
2. It should be a follow-up proposal because it would endanger Memory64 to be delayed.
3. It's not worth it and is not needed at all.

Opinions?