Function pointers are i64, and require a function table with i64 indices. However, it's unclear if anyone would ever need that many functions though, and this puts a burden on engines to support 64-bit table indices which might not otherwise be needed in many places.
Function pointers are i64, but the function table still uses i32 indices, and we convert i64 to i32 before indirect calls.
Function pointers are i64, and the static linker picks whether to use 32-bit or 64-bit tables, and rewrites the code as needed to make this work. However, it seems like this would be awkward for dynamic linking.
Function pointers are i32 (while data pointers remain i64). This is ok by the C standard and compatible with POSIX's dlsym, but could break other assumptions. It would save some memory when function pointers are stored in structs or arrays. This would probably require more work in LLVM and Clang to support.
With wasm64 discussions happening, one question for the wasm64 C ABI is how to represent function pointers.
Some options:
i64
, and require a function table withi64
indices. However, it's unclear if anyone would ever need that many functions though, and this puts a burden on engines to support 64-bit table indices which might not otherwise be needed in many places.i64
, but the function table still usesi32
indices, and we converti64
toi32
before indirect calls.i64
, and the static linker picks whether to use 32-bit or 64-bit tables, and rewrites the code as needed to make this work. However, it seems like this would be awkward for dynamic linking.i32
(while data pointers remaini64
). This is ok by the C standard and compatible with POSIX'sdlsym
, but could break other assumptions. It would save some memory when function pointers are stored in structs or arrays. This would probably require more work in LLVM and Clang to support.