Documentation

WebAssembly type of a WebAssembly value that WebAssembly code could either expect on the evaluation stack or leave on the evaluation stack.

Singleton type useful for programming with WasmType at the type level.

List of WebAssembly types used to describe the sequence of WebAssembly values that a block of code may expect on the stack or leave on the stack.

The type of a WebAssembly function, loop, block, or conditional. This type says what values the code expects to pop off the stack and what values it promises to push. The WebAssembly standard requires that this type appear explicitly in the code.

For simplicity, we record other metadata in WasmCodeGenState by need, instead of carrying them along with SymName.

Represents whether a symbol is a data symbol or a function symbol. Unlike linkers for other targets, wasm-ld does panic at link-time if it finds symbol kind inconsistency between the definition site and other use sites.

Currently we solely rely on isCFunctionLabel to determine a symbol's kind, but it does take extra effort to make it work. The main source of inconsistency arises from hand-written Cmm sources, where it's possible to refer to external entities like xxx_info and xxx_closure without explicit import CLOSURE declarations. The Cmm parser will implicitly assume those are foreign function labels, and then this will break the WebAssembly backend. #22368 provides more context on this issue.

tl;dr for any GHC contributor that accidentally triggers wasm-ld errors when hacking Cmm: whatever data symbols are used in new code, just add the corresponding import CLOSURE declarations at the top of that Cmm file.

WebAssembly doesn't really have proper read-only memory regions yet. Neverthless we add the .rodata logic here, wasm-ld will aggregate all .rodata sections into a single one, which adds possibility for runtime checks later, either via a customized runtime, or via code instrumentation. See https://github.com/llvm/llvm-project/blob/b296aed8ae239c20ebdd7969e978f8d2a3b9c178/lld/wasm/Writer.cpp#L856

Neither Cmm or Wasm type system takes integer signedness into account, therefore we always round up a CmmLit to the right width and handle it as an untyped integer.

The w type variable in the Wasm IR stands for "platform word type", so TagI32 on wasm32, and TagI64 on wasm64. This way, we can make the codegen logic work on both wasm32/wasm64 in a type-safe manner.

Representation of WebAssembly control flow. Normally written as WasmControl s e pre post Type parameter s is the type of (unspecified) statements. It might be instantiated with an open Cmm block or with a sequence of Wasm instructions. Parameter e is the type of expressions. Parameter pre represents the values that are expected on the WebAssembly stack when the code runs, and post represents the state of the stack on completion.

The default WasmAsmConfig must be extracted from the final WasmCodeGenState.