waffle: initial Bytecode Alliance-hosted version. #1

…gister) allocation.

… for function param

…ow supports/generates loops too)

…ols.

This partially reverts the previous commit. Also fix the logic in `DebugLocReader::get_loc`.

DWARF addresses are relative to the start of the code section

This commit rewrites `stackify` (Ramsey control-flow algorithm) with explicit-stack control flow, using a state-machine stack, rather than direct recursion. This avoids stack overflow for large function bodies.

…from set when popping from queue)

This allows using a function body as a source for a transform without necessarily requiring a recompilation as well.

…module, to keep memory usage down

…her length field is included between CodeSection::raw() and function().

Fixes #7.

Prevent const prop of const op

Add memory.copy and memory.fill support

…l flow. Wasm supports expressing only reducible control flow via its structured control flow mechanisms (forward-branches out of blocks and backward-branches to loop headers, in addition to structured if/else diamonds). waffle accepts an arbitrary CFG as its IR, and this CFG is perfectly capable of expressing irreducible CFGs. For example, the canonical irreducible CFG ```plain 1 / \ / \ 2 ----> 3 <--- ``` (that is, the graph with edges 1->2, 1->3, 2->3, 3->2) cannot be expressed in Wasm as direct control flow. Instead, a compiler that targets Wasm needs to either use indirection -- `i32` values as target tags that are fed into switches (`br_table`s), usually -- or code duplication. For the former case, we could build a loop body out of blocks 2 and 3 that accepts a header parameter that selects between 2 or 3; this "lowered loop" iterates twice as many times as the original loop. For the latter case, we could duplicate either block 2 or 3 and then "fall into" the main loop, for example by doing: ```plain 1 _ / \ | \/ \ | 2 <---- 3' | | | | | 3 \_/ ``` The advantage of the label-variable approach is that it does not duplicate code; it adds a small constant overhead to code size per irreducible loop instead. The disadvantage is that it adds runtime cost, which is a potentially significant performance cliff if an unexpected irreducible side-edge is added for some reason. In addition, it has some significant implementation complexity: - All entrances to a loop are indirected through the one header block. When we support blockparams and perform the reducibility transform on the CFG, we need to find the *union* of all blockparam signatures of all side-entrances and rewrite block targets to use "default" zero-values for the gaps (unused parameters for the dynamically-selected target). This is very awkward, and potentially impossible when we have non-nullable values (e.g. GC refs) in the future. - When a side-entrance to a *nested* loop occurs, we need to indirect through multiple header blocks. This adds complexity to the transform too because we need to "fixpoint" the transform somehow: the branch targets of the header block's `br_table` also need to be transformed. In this PR, instead, I opted for the code-duplication approach. It has at most 2x code-size overhead (duplicate all but the header block in a loop, if we have a side-entrance one block later in the loop body), but has zero runtime overhead. In addition, it avoids the complexities above. This PR adds the Reducifier, a transform whose approach is described in a module-level comment in `backend/reducify.rs`. In brief, the idea is to: 1. Compute an approximate loop-nest over the CFG, computing "header sets" for every block that describe the loops the blocks belong to. We do this by first computing a reverse postorder, then finding RPO backedges (edges from rpo-index `i` to rpo-index `j` such that `j <= i`), adding the header (target with lower RPO index) to all header-sets "under" the edge (rpo-indices from `i` to `j` inclusive), then fixing up loop nesting in one final pass over the header-sets in RPO order with a stack that tracks the nest, "pushing out" the extent of outer loops to cover inner loops that start within their extent. In the above canonical irreducible CFG, blocks 2 and 3 will have header-sets of either `{2}` or `{3}`, depending on which of the two valid reverse postorders the initial RPO computation chose (which depends on which out-edges are visited first). 2. Find irreducible edges given these header sets: these are edges from `B1` to `B2` such that header `H` is in `headers(B2)` but not `headers(B1)`, and `H != B2`. (Intuitively, a "side-entrance".) If no such edges exist, the CFG is reducible; early-out without modifications. 3. Perform a context-sensitive code-duplication pass. We define a *context set* per block that is like the header set, but the dual: it denotes "side-entered loops". (Formally, moving across an edge `(From, To)`, we compute `ToContext = headers(To) & !{To} & (FromContext U !headers(From))`: this adds to the context when we side-enter a loop, and removes from the context when we jump back to the loop header or leave the loop.) As part of this, we perform a limited "max-SSA" pass on a set of cut-blocks computed as side-entrances and exits (that is, exactly blocks where we change context), so that when we duplicate code, we don't have to reason about fixing up SSA across stapled-together duplicated code fragments. This results in a reducible CFG, which we can then compile with the rest of waffle's backend.

@sunfishcode

Per @sunfishcode's offline comment -- the tradeoff makes sense for us for now but we should explicitly document / warn about it.

Support irreducible control flow by converting it to reducible control flow.

This avoids crashing on very long function bodies.

…mmand. "Every Wasm compiler library contains an incomplete, bug-ridden implementation of half of wasip1", the saying goes. (Or was that about Lisp implementations?) Let's remove the very hacky implementation here: it was only useful to debug waffle during bringup but shouldn't really exist as a user-facing functionality at this point.

This was useful to help debugging at one point, especially differential comparison of before- and after-transform function bodies, but it's an awkward way of doing it (with a new kind of value definition in the IR) and is largely unused at this point, so let's remove it.

…ods.

…ts` mini-suite.

Commits on Apr 1, 2023

Add print-func command to waffle-util.

cfallin committed Apr 1, 2023

Configuration menu

View commit details

Copy full SHA for 1311069

Browse repository at this point

Copy the full SHA

1311069 View commit details

Browse the repository at this point in the history

waffle: initial Bytecode Alliance-hosted version. #1

waffle: initial Bytecode Alliance-hosted version. #1

Commits on Nov 22, 2022

Commits on Nov 23, 2022

Commits on Nov 29, 2022

Commits on Nov 30, 2022

Commits on Dec 1, 2022

Commits on Dec 2, 2022

Commits on Dec 4, 2022

Commits on Feb 2, 2023

Commits on Feb 3, 2023

Commits on Feb 7, 2023

Commits on Feb 8, 2023

Commits on Feb 11, 2023

Commits on Feb 12, 2023

Commits on Feb 13, 2023

Commits on Feb 14, 2023

Commits on Feb 15, 2023

Commits on Feb 17, 2023

Commits on Feb 22, 2023

Commits on Feb 24, 2023

Commits on Feb 25, 2023

Commits on Feb 26, 2023

Commits on Feb 28, 2023

Commits on Mar 1, 2023

Commits on Mar 2, 2023

Commits on Mar 24, 2023

Commits on Apr 1, 2023

Commits on Apr 8, 2023

Commits on Apr 9, 2023

Commits on Apr 14, 2023

Commits on Apr 15, 2023

Commits on Apr 17, 2023

Commits on Apr 19, 2023

Commits on Mar 27, 2024

Commits on Mar 28, 2024

Commits on Mar 29, 2024

Commits on Apr 1, 2024

Commits on Apr 2, 2024

Commits on Apr 13, 2024

Commits on May 7, 2024

Commits on May 9, 2024

Commits on May 12, 2024

Commits on May 14, 2024

Commits on May 18, 2024

Commits on Jun 22, 2024

Commits on Jun 23, 2024

Commits on Jun 27, 2024

Commits on Jul 29, 2024

Commits on Aug 30, 2024

Commits on Aug 31, 2024

Commits on Sep 3, 2024

Commits on Sep 4, 2024

Commits on Sep 5, 2024

Commits on Sep 12, 2024