Wasm Support

[Joe_Groff]

Thanks for the replies Yuta!

@kateinoigakukun

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.

That sounds great, then I agree using an absolute pointer in place of relative is the way to go. However, does WASM support loading and linking multiple wasm files on the client side? How does symbol resolution work in that case? If there's the equivalent of an import table or GOT, it might still be interesting to have something like RelativeIndirectablePointer, but with an absolute address, to still be able to avoid up-front load time costs for cold metadata structures.

@kateinoigakukun

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 https://github.com/apple/swift/compare/9466d120ce1b1d79543864938b28bb500f8af4c8...kateinoigakukun:katei/swifterror .
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.

I wouldn't expect an extra added argument and return to have that much overhead, and it seems like it'd be a reasonably tractable peephole optimization for WASM code generators to elide the argument materialization if it were passed an undef value. I would be concerned that, even if you patch up the compiler to thunk instead of assuming the ABIs match up, we still assume that nonthrowing functions are ABI-compatible with throwing functions fairly pervasively through the runtime, and that existing Swift code in the wild may also be relying on that assumption.

If it helps, it's also worth noting that the value in the memory pointed to by the swifterror argument is generally not significant in the calling convention, only the value at the time the function returns. You could probably avoid materializing an argument altogether and just treat it as undefined on function entry and only materialize an extra return. Another possibility might be, if WASM has a native encoding for alternative returns to represent exception handling, to utilize that to represent error returns and throws instead.

@kateinoigakukun

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.

In that case, I would simply disable the tests for now.