Follow-up to #921 / #922. The fix did exactly what was needed — thank you. Reporting the result, because it turns out to be a very small ask.
What #922 revealed
Re-ran --emit-wcet on the same object (a whole dissolved gust:os composite, 31 functions) with synth 0.55.0. The 9 previously-opaque unmodeled-op declines resolve to two opcodes:
| opcode |
functions |
I64Const |
6 |
I64Str |
3 |
With byte offsets, exactly as specified:
gust:os/time@0.1.0#elapsed op=I64Const offset=62
gust:os/time@0.1.0#resolution op=I64Const offset=56
exec_admit op=I64Str offset=118
exec_poll_round op=I64Const offset=24
func_26 op=I64Const offset=374
Before #922 the only way to learn this was to hand-bisect a 31-function object. It took one run afterwards.
The ask, now that it's concrete
Add cycle costs for I64Const and I64Str to the Cortex-M3/M4 model. Both look like they should be mechanical — an immediate materialisation and a 64-bit store, neither data-dependent.
The leverage is disproportionate. Current state of that object:
BOUNDED 1
callee-unbounded 11 cascade — resolves when its leaves do
unmodeled-op 9 <- these two opcodes
loop 8 needs trip counts (scry loop-bound inference)
call 2 by design — those two reach imports
The 11 callee-unbounded are downstream of the 17 leaves. So two opcodes plausibly unblock 9 functions directly and contribute to freeing 11 more — from 1 bounded toward roughly 20, with the residue being the 8 genuine loop-bound cases and the 2 seam calls that should decline.
Minor observation, not a request
reason=loop declines carry no extra fields — no head_offset in the payload for these. #922's comment mentions head_offset on bounded functions sharing the same coordinate space, so possibly it's only emitted there by design. If a loop decline could carry the backward-branch offset, locating the trip-count candidate would be as cheap as locating these opcodes just became.
Reproducible in three commands from a committed input; happy to re-run against any candidate.
Follow-up to #921 / #922. The fix did exactly what was needed — thank you. Reporting the result, because it turns out to be a very small ask.
What #922 revealed
Re-ran
--emit-wceton the same object (a whole dissolvedgust:oscomposite, 31 functions) with synth 0.55.0. The 9 previously-opaqueunmodeled-opdeclines resolve to two opcodes:I64ConstI64StrWith byte offsets, exactly as specified:
Before #922 the only way to learn this was to hand-bisect a 31-function object. It took one run afterwards.
The ask, now that it's concrete
Add cycle costs for
I64ConstandI64Strto the Cortex-M3/M4 model. Both look like they should be mechanical — an immediate materialisation and a 64-bit store, neither data-dependent.The leverage is disproportionate. Current state of that object:
The 11
callee-unboundedare downstream of the 17 leaves. So two opcodes plausibly unblock 9 functions directly and contribute to freeing 11 more — from 1 bounded toward roughly 20, with the residue being the 8 genuine loop-bound cases and the 2 seam calls that should decline.Minor observation, not a request
reason=loopdeclines carry no extra fields — nohead_offsetin the payload for these. #922's comment mentionshead_offseton bounded functions sharing the same coordinate space, so possibly it's only emitted there by design. If a loop decline could carry the backward-branch offset, locating the trip-count candidate would be as cheap as locating these opcodes just became.Reproducible in three commands from a committed input; happy to re-run against any candidate.