wasmtime / issue #7124 Externally maintained cranelift ba... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #7124 Externally maintained cranelift ba...

Wasmtime GitHub notifications bot (Oct 02 2023 at 07:37):

Feature

Today cranelift has a number of backends for traditional computer architectures: x86, aarch64, riscv64 and some others as well. It would be great if we could have many more, however adding new backends to cranelift-codegen crate faces some difficulties:

Every additional backend makes changing the rest of cranelift harder, as any modification to the functionality or API that backends interact with now mean adjusting every single one of these backends in the same PR. This is nice in that everything is guaranteed to at least continue building. But it can make necessary changes extremely hard/infeasible to make at all, especially if the contributor is not necessarily super familiar with the minutiæ of all the different architectures that have been implemented.

Some types of backends don't really behave like “traditional” architectures: Harvardian machines, machines with segmented memories, stack machines (e.g. WASM). Exploring backends that don’t fit the template of the already in-tree “Oxfordian” architectures may be more painful than necessary to all parties involved.

As thus, we should make sure that implementation and use of backends implemented outside of the wasmtime/cranelift repositroy is relatively painless. This could be at least the following:

Make sure the APIs necessary for something like this are exposed. Notably, this also includes the ability to load the backend implementation easily (so that the backend is usable with e.g. rustc).

(At least a basic) Documentation on not only how to implement an external backend, but to also decide whether a backend should be external or an internal?

Example backend for a simple machine, or a skeleton project that people could look at and build on top of;

etc.

Benefit

Having this infrastructure in place benefits the cranelift project through an eventually increased architecture support, while at the same time not making these additional, and potentially obscure, targets a maintenance burden to the developers upstream.

These backends could move at their own pace for a fair bit of changes too. Although I don’t see how they could avoid needing to keep up with the interface that clift would expect from these backends (especially if these backends wanted to be loaded with a project that integrates a specific version of clift, such as rustc,) but a change like the migration from regalloc to regalloc2 could potentially be made at the backend’s own pace.

Implementation

We at Pagoda have a desire to implement a backend, and although we’re currently hacking on the backend in a fork, it seems that there is a consensus a backend like ours would make most sense as an externally maintained crate.

So far the plan is to figure out the things as we go and contribute changes and/or specific feature requests as they come up. In that sense this issue might act as a tracking issue of sorts.

Alternatives

The alternative of continuing inclusion of all backends in-tree has been considered. There is a concern that these backends may become an excessive maintenance burden, especially as or if the maintainers of the backend become unreachable.

Wasmtime GitHub notifications bot (Oct 02 2023 at 10:26):

bjorn3 commented on issue #7124:

TargetIsa should be implementable out-of-tree. You still need a patch to the cranelift user to use your TargetIsa impl though. You can also have your own impl of Module if you are using a non-conventional architecture. This is a lot more flexible, but Wasmtime doesn't use this as it needs low-level control in ways that targets like Wasm and zkASM can't offer anyway. And Wasmtime has hard coded relocation resolving code. Having a new Module impl for Wasm or zkASM as alternative to cranelift-jit and cranelift-object should be possible. I even made an impl which serializes all functions without compiling to then later deserialize into another Module with only a couple of small Cranelift changes required to Cranelift to allow remapping id's in the deserialized Function. Was pretty easy to hook up to cg_clif for "LTO" support. (LTO without actually doing any cross-module optimizations. Just the delaying all codegen until the final executable is being compiled.)

Last updated: Dec 23 2024 at 12:05 UTC