Wasm Support

[kateinoigakukun (Yuta Saito)]

@Joe_Groff

Is this because of a fundamental limitation of the wasm format, or because of missing support in LLVM?

It's due to the design of WebAssembly and LLVM support.
If LLVM supports substruction relocation type on WebAssembly like R_X86_64_PC32 or X86_64_RELOC_SUBTRACTOR, this issue can be solved easily.

But LLVM doesn't support this relocation type because of the design of WebAssembly.

First, R_X86_64_PC32 and X86_64_RELOC_SUBTRACTOR are mainly used to generate PIC but WebAssembly doesn't require PIC because it doesn't support dynamic linking. In addition, the memory space also begins at 0, so it's unnecessary to relocate at load time. All absolute addresses can be embedded in wasm binary file directly.

WebAssembly natively achieves the motivation of Relative Pointer without Relative Pointer.

@Joe_Groff

(a) reduce metadata size on 64-bit platforms, because it's always 32-bit

Now we target only wasm32, not including wasm64 because there is no fixed spec for wasm64 and no runtime supporting 64bit.
IMHO we should discuss about wasm32 and wasm64 separately and it's no use discussing non-existing architecture.

@Joe_Groff

(b) reduce load time overhead by representing references to symbols in the same binary in a way that can be directly encoded in the on-disk image format.

As I said above, WebAssembly doesn't need to relocate at load time, so wasm binary format can contain absolute address directly.
And relative pointer has time overhead on dereferencing to calculate real absolute address. On the other hand, if absolute pointers are embedded in binary file directly, there is no overhead at both load time and accessing time.

For these reasons, WebAssembly natively achieves the motivation of Relative Pointer and has a superior runtime performance without Relative Pointer.

@Joe_Groff

Would it be possible to make it so that swiftcc functions in LLVM are always lowered with an extra argument and return for the swifterror argument, regardless of whether they have one or not, so that they still do not need a thunk?

I've tried this way also, but it was quite hard to switch the number of arguments for all functions. Here is the WIP patch for this way Comparing apple:9466d120ce1b1d79543864938b28bb500f8af4c8...kateinoigakukun:katei/swifterror · apple/swift · GitHub .
I spent quite a few weeks to solve this issue in this way, but I couldn't list up all function emission code because there is no common helper to emit function in IRGen. (maybe I overlooked)

And I know there is runtime overhead when using thunk, but I don't know that which is more expensive, thunk function or extra argument. What do you think about this?

Update: 2020/02/19 15:21 JST

I think adding extra arguments to all functions costs more than using thunk because the former way has dispatch overheads for every function call and the latter has overhead only when type conversion needed.

@Joe_Groff

Is it practical to provide something that looks enough like multiple kernel threads to fool the tests?

No, there isn't.

IMO it's impossible even if there are user level multiple threads because WASI doesn't support signal yet. If we can hook abortion, it may work well.