From b76ffd59cfcbf7438ec20c4079283c37c188d45f Mon Sep 17 00:00:00 2001 From: Chris Fallin Date: Sat, 3 Dec 2022 18:10:59 -0800 Subject: [PATCH] README update. --- README.md | 18 ------------------ 1 file changed, 18 deletions(-) diff --git a/README.md b/README.md index f2d885b..af6537b 100644 --- a/README.md +++ b/README.md @@ -49,24 +49,6 @@ The backend operates in three stages: allocation (using a simple linear-scan algorithm) to assign all SSA values to locals such that no live-ranges overlap in the same local. - We use Wasm locals rather than the stack for most dataflow. We can use the - stack in a limited way, opportunistically, but doing more requires - sophisticated scheduling (moving operators so they occur at the right time), - which we haven't yet implemented. - - We could allocate a local per SSA value, but this is very wasteful. First, - there is a limit to the number of locals supported by most engines. Second, - "baseline" compilation strategies typically just allocate a stackslot per - local, and so this would create huge, sparsely-used frames. - - Instead, we reuse locals by tracking live-ranges of each SSA value and - assigning non-overlapping ranges to the same local. This is actually a very - simple register allocator. It remains simpler than other production - allocators by (i) only tracking a single span for each SSA value, rather than - a discontiguous set of spans, and (ii) freely reaching for new locals when - needed rather than "spilling" (it behaves as if the register file is - infinite). - ## Comparisons / Related Work - Like [Binaryen](https://github.com/WebAssembly/binaryen) but with an SSA IR,