Wasmtime GitHub notifications bot (Aug 30 2026 at 14:35): Wasmtime GitHub notifications bot (Aug 30 2026 at 14:35):oddcoder opened issue #14236:
Feature
I need BPF back end code generator that is not a 100MB in size, cranelift looks ideal (based on AI prototypes).
BPF is small RISC style ISA that should be relatively straightforward to implement.
Benefit
I am working on a scripting language that compiles down to BPF and is meant to be stapable to production systems. I need a lightweight optimizing JIT capable of producting BPF assembly to be loaded in relatively constrained environments.
Currently the alternatives are one of the following:
A- compile down to bpf byte code and ship it. Sometimes that can be impractical when having diverse machines with diverse kernel versions.
B- Strap a full LLVM toolchain to to the script so that it compiles on target
Implementation
I have no idea yet how to do it yet. I hope you would surprise me by saying this a) exists b) is WIP and is fully resourced.
If not, AI was able to prototype an implementation via traversing IR and generating assembly. So least I know it is doable.
I read a bit about ISLE, and I am kind of familiar with term rewriting in general due to previous experience with proof tactics in coq.
I patched cranelift to expose its internals for an out of tree implementation of a backend. I will be doing my own implementation in traqilet/crates/bpf, by copying alot from the structure of existing backends and will PR the back-end bit by bit.
Alternatives
I am not aware of any reasonable alternatives.
Wasmtime GitHub notifications bot (Aug 30 2026 at 14:42):bjorn3 commented on issue #14236:
Wasmtime GitHub notifications bot (Aug 30 2026 at 15:29):oddcoder commented on issue #14236:
If any users spring up with strong needs and contributors are present to work on this, we can always re-open the discussion.
well that settles it.
I am still doing the reading bits and exploring the code base but if there is a particular entry point you recommend let me know
Wasmtime GitHub notifications bot (Aug 31 2026 at 21:04):cfallin commented on issue #14236:
@oddcoder could you detail your thoughts on adapting to eBPF's restrictions, especially around control flow? At first pass, at least, I think I would come to this with a stronger opinion than the one I wrote in #1129 a few months ago: eBPF is different enough, and niche enough, and far enough from the use-cases that the full-time maintainers of Cranelift are able to devote time to, that in my opinion, it would be unlikely to be accepted. But if you can put together a convincing design that maps Cranelift's abstractions (arbitrary control flow and jumps, fixed machine registers, a stack with frames that we can manage) to the eBPF ISA, we're happy to hear more.
Wasmtime GitHub notifications bot (Aug 31 2026 at 21:54):oddcoder commented on issue #14236:
Ebpf restrictions are only a concern of the Linux kernel bpf loader, bound
to change, and were never part of the ISA
https://docs.kernel.org/bpf/standardization/instruction-set.html or its
standerization efforts in ietf/rfc/9669.Code generator backend (if it ever support ebpf) would only concern itself
with lowering IR to ISA, while disabling certain optimizations passes (loop
unrolling comes to mind)I do not have concrete plan, I am working on this project over weekends.
But roughly speaking, implementation would follow that of riscv code
generator. Ebpf has core instructions with bunch of extensions (64bit,
atomics).Would that make sense for an intial plan? Do you have any major concerns ?
Message ID: @.***>
>
Wasmtime GitHub notifications bot (Aug 31 2026 at 21:59):cfallin commented on issue #14236:
Code generator backend (if it ever support ebpf) would only concern itself
with lowering IR to ISA, while disabling certain optimizations passes (loop
unrolling comes to mind)OK; without more detail on how you plan to, e.g., map register allocation, or our ABI and stackframe handling, or ... to eBPF, it's hard to say how realistic the plan is.
Note that we don't have a loop unroller, so that part of your message is not applicable.
I do not have concrete plan, I am working on this project over weekends.
But roughly speaking, implementation would follow that of riscv code
generator. Ebpf has core instructions with bunch of extensions (64bit,
atomics).OK. You're of course welcome to work on it! Just noting my perspective and highlighting the design questions that would be good to nail down first before sinking too much time into it.
Wasmtime GitHub notifications bot (Sep 06 2026 at 14:53):oddcoder commented on issue #14236:
Hello again,
how you plan to, e.g., map register allocation
I followed recommendation documents attached to rfc9669: https://github.com/ietf-wg-bpf/ebpf-docs/blob/main/rst/abi.rst
leading to the following diff:
or our ABI and stackframe handling
I did not get to that point yet. But it would help alot if you can articulate which part of BPF will not work with cranelift.
Wasmtime GitHub notifications bot (Sep 06 2026 at 17:26):cfallin commented on issue #14236:
Those docs are pretty sparse -- I see the "read-only frame pointer register" but nothing about how the stack is supposed to be used. The "read-only" aspect plus the first-class notion of functions implies to me that BPF seems to have something more like Wasm's runtime-managed callstack. In contrast, Cranelift's ABI code expects to construct and deconstruct stack frames itself, in the way that native ISAs work. You can probably hack around it if BPF lets you define a frame size and then have arbitrary access (again, I didn't see any definitions in the linked docs) but e.g. Cranelift's exception support and its tailcall support will not be possible to map. I suspect the callsite handling will need to change substantially too.
Let us know what you find -- I can't spend a lot of time researching this myself, just giving my thoughts from what I see so far.
Last updated: Sep 20 2026 at 18:08 UTC