Wasm Support

[Joe_Groff]

@kateinoigakukun

WebAssembly MVP doesn't support loading multiple wasm files now and there is no stable ABI for dynamic linking. And also doesn't provide GOT or something related to PIC.
However, LLVM generates virtual static GOT on wasm memory space if the frontend compiler emits IR as PIC. Now, swiftc emits IR as PIC even for wasm, so we have to use something like AbsoluteIndirectPointer to reference through static GOT.

As you said, there is some potential for performance improvement if swiftc emits IR as non-PIC using direct absolute pointer.

Update 2020/02/20 21:38 JST

(I misunderstood what you said, sorry)

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

Do you mean we should use RelativeIndirectablePointer instead of absolute pointer if there is GOT on WASM?

Well, if all wasm code is eventually linked into one object file for deployment, then there shouldn't ever strictly be a need for a GOT (though Swift or LLVM may end up incidentally generating entries because it assumes a symbol might come from a dynamic library in many cases). You might be able to fend off these unnecessary GOT entries in the short term by marking all symbols as dsolocal in the generated LLVM IR, and changing the logic in Swift IRGen's getAddrOfLLVMVariableOrGOTEquivalent to always generate direct references when targeting WASM.

If WASM in the future does end up having a dynamic linking story, then we would still probably want to keep the places where we use RelativeIndirectablePointer as true-const to minimize startup time, but maybe we can avoid solving that problem until the future. A future WASM with dynamic linking support might end up growing full support for PIC too, you never know.

@kateinoigakukun

I see, I basically agree with you at this point. I’ll try this way!

BTW what module should be patched, IRGen or IR lowering module in LLVM? As I said above post, it was quite hard to patch IRGen because I had to modify many places. Do you have any rough plans for this way?

To me, it seems more natural to change the LLVM calling convention lowering for swiftcc functions.