Make IB hot paths compiler/backend optimization test targets

[isomorphisms]

Sequencing status — 2026-08-27

This is a future workload inventory and evidence policy, not an instruction to add another implementation now. Follow isomorphisms/idric-arm-thumb#31. Existing draft semantic experiments may remain review evidence, but they do not settle Idriç strings, byte slices, loops, result ABIs, or backend lowering. The recursive List Char sketch below is a statement of search meaning only; it is not the native implementation plan.

Goal

Treat IB itself as a continuing source of real compiler/backend acceptance and performance workloads, rather than optimizing synthetic examples in isolation.

The first concrete target is exact substring search over browser-owned text. The current IB.Index code already contains a simple strip_prefix primitive and whole-key equality lookup; the missing outer sliding scan is a clean semantic reference for fixed-string search.

This issue should ensure that browser code which can plausibly benefit from lower-level control-flow, packed-state, table-dispatch, SIMD, or other target-specific lowering is identified and represented by an executable test/benchmark before an optimization is accepted as useful for IB.

First target: exact substring scan

Add a deliberately simple Idriç reference implementation shaped like:

contains : List Char → List Char → Bool
contains [] _ = True
contains (_ :: _) [] = False
contains wanted (char :: rest) =
  case strip_prefix wanted (char :: rest) of
    Just _  ⇒ True
    Nothing ⇒ contains wanted rest

Preserve this as the semantic oracle even if the production implementation later uses a byte-oriented or backend-specialized path.

Benchmark at least:

• no match;
• match at beginning;
• match in middle;
• match at end;
• repeated-prefix/adversarial input;
• one-byte pattern;
• short literal;
• pattern around the packed-state machine-word boundary when that optimization is tested.

Record match/no-match and match position/count where applicable, bytes scanned, emitted code where relevant, and wall/cycle evidence on the real target when available.

IB optimization-target audit

Build a small, maintained inventory of browser-owned paths that are credible candidates for compiler/backend speedups. Candidates include, but are not limited to:

• exact lexical/substring search over stored titles, URLs, OCR text, extracted page text, and filenames;
• URL/host parsing and delimiter scans;
• tokenization and parser dispatch;
• MIME/content-type and source-kind dispatch;
• renderer/capability dispatch where it becomes hot;
• history/index scans and filters;
• category/classification feature extraction loops;
• vector-index query loops and top-k filtering where the backend actually owns the relevant numeric operations;
• prepaint/text extraction loops;
• importers for raw URL lists, history exports, and other large sequential text inputs;
• any later grep-like memoization or repeated interior-search path.

This is an audit list, not a demand that every path receive a special instruction. A path becomes an optimization target only when we can preserve semantics and measure a representative workload.

Cross-backend test rule

When an IB workload motivates an Idriç/compiler/backend optimization:

1. keep an ordinary semantic reference/oracle;
2. add a small acceptance fixture in the relevant backend repository;
3. link the backend fixture back to the IB workload/issue;
4. compare against a competent baseline rather than intentionally weak generated code;
5. distinguish code-size wins, latency wins, throughput wins, and regressions;
6. keep target-specific tricks optional so IB remains correct on other backends.

The ARM/Thumb backend is the first concrete consumer of this rule. Existing related work there includes isomorphisms/idric-arm-thumb#9 (table/computed branches for fixed-string grep) and #10 (packed-bit fixed-string search lowering).

Acceptance criteria

• exact substring search has an executable Idriç semantic reference and oracle fixtures;
• the corresponding ARM/Thumb acceptance fixture links back here in a source comment;
• IB has a maintained inventory of plausible backend-optimization targets;
• at least one real IB benchmark can be run before/after a backend optimization;
• optimizations do not replace portable semantics or silently change behavior;
• measured failures/non-wins are retained as evidence so unusual instructions are not used merely because they are interesting.

[isomorphisms]

Draft PR #34 (exact-text-semantic-reference) remains review evidence for one character-level substring contract. It is not the accepted native Idriç byte/search representation and should not be extended merely to make backend work proceed.

Under isomorphisms/idric-arm-thumb#31, later byte-search comparison waits for Gates A–C: explicit byte slices/spans, offset units, bounded repetition, and an ordinary result ABI. The first IB-derived native executable target is the bounded document-tree walk in #41 after Gates A–E.