Wasm Support

Hello, everyone. I want to share the current status of Wasm support of the compiler.

Swift Calling Convention

We sent several patches to LLVM for supporting swiftcc on Wasm, and we've finally removed all workarounds for swiftcc in Swift compiler.

https://reviews.llvm.org/D76049

Relative Pointer

As I talked with Joe Groff above, we had decided to use absolute pointer instead of relative pointer at that time due to missing a location relative relocation type.

However, this is a hacky solution and it will break metadata memory layout on 64bit arch, and also fragile for dynamic linking situation.

So we added a location relative relocation type to Wasm obejct file spec, and implemented it in LLVM and lld. This enabled Swift compiler to emit relative pointer to data symbols.

https://reviews.llvm.org/D96659

But there is still a problem when emitting relative function pointer.
Since WebAssembly is a harvard architecture and its data and code address spaces are completely isolated, so relative offsets between relative pointer itself address and the referent function address couldn't be represented.

To address this, I propose forcing relative function to always be indirect on harvard architectures. This is similar to GOTed indirectable relative pointer, but it emits indirect pointer even though the reference and referent are in the same image.
Of course, this indirection would add some amount of runtime performance and size overheads for extra loading and trampoline indirect pointers in data, but as far as I understand, those relative function pointer resolutions are not in performance-critical areas (correct?).

WDYT this approach, runtime people? it would be appreciated if someone could review the change.
CC: @Joe_Groff, @John_McCall
https://github.com/apple/swift/pull/41995/

16 Likes