Wasmtime GitHub notifications bot (Mar 05 2025 at 22:46): Wasmtime GitHub notifications bot (Mar 05 2025 at 22:46):fitzgen added the cranelift label to Issue #10339.
Wasmtime GitHub notifications bot (Mar 05 2025 at 22:46):fitzgen added the cranelift:area:clif label to Issue #10339.
Wasmtime GitHub notifications bot (Mar 05 2025 at 22:46):fitzgen opened issue #10339:
This would force us to translate all unnecessary uses of
ir::Globalinto regular CLIF instructions.Note: We have to keep
cranelift_codegen::ir::Globals around for special things like the stack limit check, which are not (and can't ever really be) represented in regular CLIF instructions, since they happen inside of function prologues or what not.However, we end up using
ir::Globals in lots of other places where we could just use regular CLIF instructions instead. For example, we use them to represent Wasm globals in our Wasm to CLIF translation layer. This is annoying because now we have to fit Wasm globals into different kinds ofir::Globals, and it would just be easier to emit the CLIF instructions to get/set the Wasm global directly. These unnecessaryir::Globaluses just introduce extra abstraction layers that don't buy us anything, add instructions that require legalization processing in the mid-end, make it harder to follow code through the compiler pipeline because there are extra and unnecessary rewrites, etc...I propose that we remove the
global_valueCLIF instruction (the instruction that turns anir::Globalinto anir::Value). Every use ofglobal_valuecould instead just be the constant or (chained) load that it would otherwise be legalized into, and emitting that already-legalized code will be easier to follow and also mildly more efficient since it doesn't need that legalization anymore. It also means we can remove the associated legalization code.
Wasmtime GitHub notifications bot (Mar 05 2025 at 22:58):cfallin commented on issue #10339:
Strong support for this one! I've mentioned previously my understanding of the rationale for global values: to express values that need to be used in parts of the IR outside of instructions: e.g., the example you give of stack limit checks; also the size argument for dynamically-sized vector types. There used to be more such cases -- e.g. when heaps were a core-Cranelift concept. But there's no reason to restrict ourselves to the static sublanguage for values that are only used in normal program flow.
If we make this cleanup, it's tempting to wonder about the remaining uses of GVs themselves: dynamically-sized vectors have stalled, and it's unclear if we want to keep them long-term (or perhaps we could have a more scoped mechanism for them); stack-limit checks are always going to need support as long as Wasmtime supports no-virtual-memory environments but again maybe there's a way that we can scope the feature down to describe exactly what Wasmtime needs. (This could include changing Wasmtime's strategy too, e.g. pass the limit in a register and force interruption use-cases to use epochs rather than stack-limit changes, but that's a larger discussion.)
Last updated: Apr 18 2025 at 11:03 UTC