Fritz Rehde (Sep 11 2023 at 13:51): Fritz Rehde (Sep 11 2023 at 13:51):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?
Alex Crichton (Sep 11 2023 at 14:10):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
Fritz Rehde (Sep 11 2023 at 14:12):How would I access these in translate_operator?
Fritz Rehde (Sep 11 2023 at 15:04):Per instance would be fine. So VMContext sounds like it would be suitable. How do I use it?
Alex Crichton (Sep 11 2023 at 15:08):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
Fritz Rehde (Sep 11 2023 at 15:12):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.
Alex Crichton (Sep 11 2023 at 15:27):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
Chris Fallin (Sep 11 2023 at 16:02):@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
Fritz Rehde (Sep 11 2023 at 20:51):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.
Fritz Rehde (Sep 11 2023 at 21:09):I think this has become/always was more of cranelift question, should I move it there?
Fritz Rehde (Sep 12 2023 at 09:48):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.
Fritz Rehde (Sep 12 2023 at 18:16):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: Oct 23 2024 at 20:03 UTC