bjorn3 commented on issue #6176:
https://github.com/bytecodealliance/wasmtime/issues/5793 is for the Value type generic, right? Not for the State trait. In cg_clif's usage I give the interpreted code direct access to the compiler's address space. For this I implemented the checked_load and checked_store methods of the State trait. I also needed to change a couple of other methods compared to InterpreterState to allow accessing data objects, to allow directly reading functions and data objects from a Module implementation that can be serialized and deserialized and to allow specifying arbitrary rust code to handle libc function calls. The last thing depends on a cranelift-interpreter change I haven't opened a PR for yet.
As for the exact use case of cg_clif, currently I used it to prototype exception support in cranelift (for my bachelor thesis) without having to immediately implement it in any backend. This allowed me to discover several optimization passes that needed changes. But even outside this I will probably want to land support for the interpreter in cg_clif.
afonso360 commented on issue #6176:
Oh, that's right! I had it in my mind that it was about both since the only other user of
State
wasImmutableRegisterState
which was used for SCCP (I think!), but it looks like that issue only coversValue
.I think we should probably revisit this when we start making progress on https://github.com/bytecodealliance/wasmtime/issues/5793, just to make sure we can keep folks happy. Thanks for sharing!
As for the exact use case of cg_clif, currently I used it to prototype exception support in cranelift (for my bachelor thesis) without having to immediately implement it in any backend. This allowed me to discover several optimization passes that needed changes. But even outside this I will probably want to land support for the interpreter in cg_clif.
Wow! This is an awesome use case! I look forward to reading that! :rocket:
Last updated: Dec 23 2024 at 12:05 UTC