emit.ml:1918 drops the allocation registry's notes in a release build -- the checker builds a Tast.Rt it cannot know is unwanted, because it does not know whether this is a dev build. The x86 backend had no counterpart and emitted the calls for real: correct, since the registry answers nothing when it is disabled, but one call per container operation into a function that returns immediately. The guard is emit.ml's byte for byte, strict > 17 included: bare flan_dev_reg_note is the runtime's own C entry point and is never a Tast.Rt, and what check.ml builds is the _vec, _map and _pool wrappers. emit.ml drops the note before the arguments are walked so that taking the address of the container does not leave an escaped alloca behind; here the arguments are not touched until call_rt, so answering () is already early enough. Measured, call sites of flan_dev_reg_note in the disassembly: vec.flan 46 -> 1 (--dev: 46) maps.flan 55 -> 1 (--dev: 55) registry.flan 36 -> 1 (--dev: 36) The one left in each is not emitted code -- it is inside the runtime's own flan_dev_reg_note_vec. An LLVM release build of vec.flan has the same one, so the two backends now agree. HANDOFF-x86-debug.md is the stub for item 6, which is next, and it leads with the finding that changes that item's plan: .loc does not work against a backend that emits .byte blobs, so the line table has to be written out by hand.
Description
Languages
OCaml
67.2%
Emacs Lisp
15.2%
C
10.4%
HTML
2.9%
Standard ML
2.8%
Other
1.5%