Stream: git-wasmtime

Topic: wasmtime / Issue #1155 Develop a replacement for the grap...


view this post on Zulip Wasmtime GitHub notifications bot (Feb 03 2021 at 18:23):

bjorn3 commented on Issue #1155:

The new backend framework uses regalloc.rs.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 03 2021 at 19:14):

cfallin commented on Issue #1155:

Fixed by @julian-seward1 and @bnjbvr with regalloc.rs -- thanks!

view this post on Zulip Wasmtime GitHub notifications bot (Feb 03 2021 at 19:14):

cfallin closed Issue #1155:

Cranelift's existing register allocator has proven to be a limiting factor for
achievable code quality. Typically it limits the performance of compiled
WebAssembly inputs to around 80% of that achieved when compiling WebAssembly
via SpiderMonkey's Ion pipeline instead.

In particular, the allocator generates excessive spilling. This is because it
doesn't implement live range splitting. Investigations have shown that while
it would be possible to implement splitting, this would make the allocator run
significantly more slowly. But the allocator already dominates Cranelift's
compilation time, and is already uncompetitively slow. So this isn't a
promising route.

The current plan is to implement two new allocators:

(1) A traditional linear-scan register allocator, in the style of Poletto and
Sarkar's paper [A], but not tune it much, at least at first.

(2) At the same time, implement a backtracking, top-down allocator similar to
that used by SpiderMonkey's Ion pipeline, and in LLVM 3.0's optimising
mode, as summarised at [B]. Experience with Ion indicates that this
allocator provides good quality allocation whilst being significantly
faster than graph colouring schemes. Hence it seems like a good choice.

The purpose of doing (1) is threefold:

Whether, and to what extent, it is necessary to translate out of SSA prior to
doing register allocation is currently under investigation.

In order to avoid any interruption in service for existing CL users, the
existing register allocator will be kept alive until such time as a new
implementation can do better, both in code quality and compile time.

[A] http://web.cs.ucla.edu/~palsberg/course/cs132/linearscan.pdf
[B] http://blog.llvm.org/2011/09/greedy-register-allocation-in-llvm-30.html


Last updated: Nov 22 2024 at 16:03 UTC