Watch branching and conditional-control-flow decisions across targets

[isomorphisms]

Purpose

Keep one cross-repository observation surface for the current Idriç branching + conditionals + bounded control flow work without turning every application example into a separate target.

ARMv7 Thumb-2 remains the proving ground. Function calls are not part of this milestone. The watch is concerned with comparisons, two-way branches, finite dispatch, bounded loops/backedges, early exit, and nested control flow.

Primary compiler contract: dilapidated-shed/Idric#72
ARM sequencing authority: dilapidated-shed/idric-arm-thumb#31
Fleet compatibility: #7
CPU mutatis-mutandis propagation: #20 / draft PR #22
Shader-specific propagation: #21 / draft PR #23
DEX-vs-physical comparison: #41

Primary watched workload families

The first-class corpus is intentionally small:

1. XML / tokenizer dispatch

   • finite tokenizer states and input classes;
   • branch chains vs tables/state machines;
   • structural-byte scans and bounded loops.

2. Document-tree / selector traversal

   • child/sibling/ancestor/descendant walks;
   • finite predicates;
   • nested traversal and early exit.

3. Fixed-string / exact-byte search

   • one portable search oracle;
   • ordinary scalar branches, packed state, table-driven forms, and later SIMD are alternative lowerings rather than separate semantics.

4. Unicode operator dispatch

   • UTF-8/scalar/token boundary;
   • staged finite dispatch for operators such as ≤, ≥, ≠, ≟, ←, →.

5. Paint / display-list dispatch

   • compact finite paint-command tags;
   • branch/table dispatch at the front;
   • increasingly regular numeric/memory work after dispatch.

These five families should be enough to pressure comparisons, two-way conditionals, finite case, bounded loops/backedges, early exits, nesting, and several different dispatch densities.

Main repository ownership

isomorphisms/Idric

Watch target-independent branching semantics and structure preservation:

• Execute TinyIdris quantity receipt against current Idriç #72 — branching/conditional control-flow contract;
• Track ARM/Thumb follower propagation with per-target mutatis-mutandis policy #20 — preserved multiway dispatch;
• Track shader follower propagation across PowerVR, Switch/Maxwell, and WebGPU/WGSL #21 — fixed search;
• Add shader follower sweep policy #23 — Unicode operator dispatch;
• Add a standard compiler benchmark ladder #25 — selector/traversal structure;
• Roll the compiler ladder across every tracked compiler route #26/Add biology search contrast gym #27 — tokenizer state/class and bulk scanning;
• Mine dEQP / VK-GL-CTS for shader semantic and precision conformance cases #32 — paint/SVG branch-to-data preservation;
• Temporary typed pseudo-register IR experiment for cross-backend lowering #43 — conditional-expression syntax remains separate from lowering.

isomorphisms/idric-arm-thumb

Watch the native proving ground:

• Start the GPU semantic gym with Piglit and VkRunner-style probes #31 — sequencing authority, with the current branch milestone allowed to use self-contained no-call fixtures;
• Exercise Cat Food from a bare cloud container #9/Enforce whole-inventory Cat Food delivery: host builds and phone/tablet runtimes #10 — search lowering alternatives;
• Add deterministic backend and keyboard observations #14 — Unicode operator dispatch;
• Document IRK/RHS validator equivalence #18 — selector/tree traversal;
• Add reproducible Iridium 2014 historical benchmark #19/Track shader follower propagation across PowerVR, Switch/Maxwell, and WebGPU/WGSL #21/Add ARM/Thumb compiler follower sweep policy #22 — XML/tokenizer control flow;
• Track ARM/Thumb follower propagation with per-target mutatis-mutandis policy #20/Add shader follower sweep policy #23 — paint/display-list and later SVG dispatch;
• Add biology search contrast gym #27 — flags remain target-local machinery.

isomorphisms/ib

Watch portable browser oracles:

• Treat DEX vs physical CPU lowering as an open design experiment #41 — bounded document-tree walk;
• Add composable suite, case, tag, target, and profile selectors to the GPU gym #35 — selector traversal;
• Consider Rodinia for broader GPU algorithm stress after the first numerical slice #37/Consider Mesa shader-db for real-world shader codegen comparisons #38 — tokenizer/state-machine + bulk scan;
• Consider HeCBench only after the GPU gym can bound large heterogeneous corpora #39 — paint/SVG branch-to-data workload.

walnut-burgundy/computer-science

Use this mainly as the decision journal / algorithm comparison source, especially #23/#24, #29, #35/#36, #42, and #58.

CPU followers: mutatis mutandis, not copy-the-Thumb-code

Use #20 / draft PR #22 for x86-64, AArch64, RISC-V, Wasm, DEX/ART and later CPU/virtual targets.

The working intuition that Thumb is a cramped alleyway and some followers are superhighways is useful only as a hypothesis. It must not become a baked-in monotonicity assumption. More registers, wider encodings, conditional select, or different branch machinery may help on some followers; another target may make the same source decision worse, illegal, or structurally different.

For every reviewed ARM branching change classify follower consequences as:

• apply
• adapt
• already-covered
• not-applicable
• defer-measurement

Propagate semantic contracts, reusable fixtures/oracles, compiler seams, and verification methods. Do not propagate Thumb flags, ABI, layout, encodings, or branch tricks as universal rules.

Fragment-shader implication check

Shaders are not CPU followers, but branching decisions may expose shared semantic distinctions that the fragment-shader backend should reconsider.

Use #21 / draft PR #23 to ask, when relevant:

• does the shader IR preserve the same semantic choice/finite dispatch/bounded iteration distinction?
• would actual branching diverge lanes/quads?
• would masks/selects be better than branch control flow?
• do uniformity or derivative rules constrain the transformation?
• does discard/early-fragment termination change legality or behavior?
• do PowerVR, Maxwell, and WGSL/driver compilers make materially different choices?

The result may be adapt, already-covered, not-applicable, or defer-measurement; never translate an ARM branch sequence instruction-for-instruction into a fragment shader.

Secondary examples are not separate targets

Mailbox parsing, Field Mouse, bioawk/genomics, and other applications may remain useful secondary fixtures, baselines, or stress tests. They do not enlarge the primary corpus unless they expose a materially different control-flow/representation problem.

Evidence layers

Keep these independent:

1. exact semantic oracle;
2. checked one-step-at-a-time compiler form;
3. target lowering / assembly / object / shader / bytecode;
4. emulator/host execution where meaningful;
5. real target execution where available;
6. follower review outcome.

Use PASS / FAIL / SKIP / NOT_VERIFIED honestly.

Decision-impact check

When a branching/control-flow choice changes, report:

• which layer changed: source semantics, checked compiler handoff, target lowering, or workload representation;
• which of the five primary workload families are affected;
• whether the change is Thumb-specific or target-independent;
• CPU follower outcomes under Track ARM/Thumb follower propagation with per-target mutatis-mutandis policy #20;
• whether the fragment-shader side under Track shader follower propagation across PowerVR, Switch/Maxwell, and WebGPU/WGSL #21 has a genuine semantic implication or no relevance;
• whether any secondary application reveals a new class not already covered.

If none of the five primary families is affected and no new cross-target semantic distinction is exposed, do not create additional work merely for completeness.

[isomorphisms]

Semantic follower rule

Do not reduce this watch to a code-diff follower. The preferred first pass is language-model semantic inference from the design history: current conversation context where available, contemporaneous decision-journal entries, issue bodies/comments, and the stated intent of the branch/conditional experiment.

For each meaningful ARM/Thumb decision, ask before looking for a textual analogue elsewhere:

1. What semantic or compiler distinction did we actually choose or preserve?
2. Why did we choose it under the current Thumb constraints?
3. Which other targets or execution models might care about the same distinction for a different reason?
4. Does the cramped-alley → superhighway intuition predict an easier realization elsewhere, and what evidence could falsify that prediction?
5. Could a shader/fragment path care because the same choice changes divergence, masking, uniformity, derivatives, early termination, or work distribution even though there is no code-level correspondence?
6. Which repositories should merely be inspected, versus actually changed?

Only after forming that semantic hypothesis should the sweep inspect code/IR/diffs and classify apply, adapt, already-covered, not-applicable, or defer-measurement.

A code change with no textual counterpart can still have a semantic follower implication; conversely, similar-looking code need not imply anything. Preserve the reasoning/provenance so later models can audit whether the inferred connection was useful or spurious.