I have some mutable runtime state (what i mean with runtime is that it will only be accessed at runtime/execution) I would like to update between different calls to translate_operator
. Basically, when translating a custom operator/wasm function, some of these operators need to access, and some need to write to, this global state. Is this possible? Maybe you can point me to an example in code_translator.rs
?
The closest might perhaps be the implementation of fuel? Runtime mutable state is typically stored in VMContext
which is per-instance state, and then there's VMRuntimeLimits
which is Store
-shared state
How would I access these in translate_operator
?
Per instance would be fine. So VMContext
sounds like it would be suitable. How do I use it?
You'd probably start by modifying VMOffsets<P>
and the various comments there. That's available throughout translation and provides the offset from the VMContext
pointer of where your data lies
Is there a reason I can't use state.get_global
or builder.ins().global_value
, i.e. manually creating a global wasm value? I thought I could then load or overwrite the global wasm value in the translations of the operators. I guess the problem I faced with that approach was that I didn't know where to define/declare the global value.
I believe those refer to globals already in the wasm module itself, which you aren't able to add to at the translation phase right now
@Fritz Rehde another issue with creating magic wasm globals is that that state is then observable via the API; wasmtime would present an incorrect view (expose internal details) to the embedder
Thanks for your messages. You're right, creating wasm globals is probably quite unidiomatic, and I think I'm actually fine creating local variables (they would be accessible in the same wasm function, right?). I'm a bit confused on the API: I think I have to declare_var
, def_var
and then use_var
. But the declare_var(Variable, Type)
takes a variable as parameter, not sure what to pass there, since I would intuitively expect to get a variable back from that, which I can then pass to def_var
and use_var
.
I think this has become/always was more of cranelift
question, should I move it there?
Hmm, actually, I think Variable
is not the right way of doing what I want to do, I think Variable
is meant more for variables in the wasm module itself, not state I want to create during compilation. I have tried adding an Option<Value>
attribute to the FuncTranslationState
, but that panics when the value is accessed in value_type
.
I can explain some more about the problem I am trying to solve, maybe you have some other ideas on how to solve this: Let's say I have an Operator::SegmentNew
. The first time that operator is present in a wasm function, I want to "tag" that index with a random tag. That is currently already implemented, and works simply by calling let tagged_index = builder.ins().arm64_irg(index);
. However, I want to now save this Value
(irg generates the random tag at runtime only), so I can use it again when handling the next instance of Operator::SegmentNew
. There, I will need to perform some arithmetic operations on the Value
(e.g. band_imm
, badd_imm
), use it, and then write it back to the place where I'm storing it between the operator calls.
Like I said, currently I just have an Option<Value>
member in FuncTranslationState
, but that doesn't work because just saving it there doesn't add the Value
properly to the DataFlowGraph
, which is required for when performing operations band_imm
.
Last updated: Dec 23 2024 at 14:03 UTC