Int32 vs. Int64 issues

[tshort]

Most people will be running a 64-bit version of Julia, so integer constants and pointers are 64 bit. wasm32 supports 64-bit integers, but pointers are 32 bits, and JavaScript needs Int32's. This complicates compilation. For example, pointer arithmetic involves conversion to UInt64. Some options for handling this include:

Convert pointers to 32 bits for pointer operations

This allows use of Int64's. It may have extra overhead. Before load or store operations, convert to i32.

Convert everything to i32

This might be the leanest code, and it'll probably work. There might be tricky code like overflow detection that might get messed up. It wouldn't allow use of 64-bit integer operations.

Convert integer constants to i32

I don't know if this is even possible. The idea would be to convert integer constants to Int32 and re-run method selection and type inference. This might be a way to encourage more code to use 32-bit integers.

Any other ideas? Any other considerations on 32 vs. 64 bits?

[tshort]

Related: https://github.com/JuliaGPU/CUDAnative.jl/issues/25

[MikeInnes]

I don't think we want to change literals / all user integers just for pointers. We could swap out the representation of Ptr to 32-bit, but we'd have to do that on typed-but-unoptimised code and swap out methods, so it's a bit of extra complication for the current stack.

By far the easiest thing would be to just take your option one and throw in a conversion where needed. I doubt the overhead will be that significant, and if it is we can figure it out later on.