sunfishcode opened Issue #2712:
In WebAssembly, a
br
instruction with a depth equal the the current control-flow stack depth is equivalent to areturn
. However, in the current fuel implementation, these are handled differently:
return
consumes 0 fuel, while abr
to the control-flow stack depth consumes 1.return
updates the fuel usage field inVMInterrupts
, while abr
,br_if
, orbr_table
to the control-flow stack depth does not, even though they also exit the function
sunfishcode labeled Issue #2712:
In WebAssembly, a
br
instruction with a depth equal the the current control-flow stack depth is equivalent to areturn
. However, in the current fuel implementation, these are handled differently:
return
consumes 0 fuel, while abr
to the control-flow stack depth consumes 1.return
updates the fuel usage field inVMInterrupts
, while abr
,br_if
, orbr_table
to the control-flow stack depth does not, even though they also exit the function
alexcrichton commented on Issue #2712:
FWIW the current heuristic for fuel consumed per-op is pretty primitive. It's based on the lucet one but slightly adjusted.
The thinking behind
return
taking 0 fuel is that the cost was already incurred with the originalcall
, but we could pretty easily just update it to cost 1 fuel as well. In general my hope is that folks don't rely on the precise amount of fuel consumed by instructions too too much because it can make changes to the code generator brittle and/or future peformance improvements somewhat more difficult.For the second point, though, I believe that all of these branching/control-flow opcodes update fuel correctly, even if
br
goes to the exit of the function. Was a bug seen in the wild though?
sunfishcode commented on Issue #2712:
Ah, no, this is just from me diving into the middle of the code. Good point about
br
going to the exit and being handled there.
Last updated: Nov 22 2024 at 17:03 UTC