fix(joinir): Phase 241-EX - Remove hardcoded 'sum' check from Pattern3

Remove legacy hardcoded 'sum' carrier validation that was blocking array_filter patterns with different accumulator names (e.g., 'out'). Before: Pattern3 required carrier named 'sum' to exist After: Pattern3 uses carrier_info generically (any carrier name works) Test results: - phase49_joinir_array_filter_smoke: PASS ✅ - phase49_joinir_array_filter_fallback: PASS ✅ - phase49_joinir_array_filter_ab_comparison: PASS ✅ - Full suite: 909/909 PASS, 0 FAIL Also: Archive old roadmap documentation (67k lines moved to docs/archive/) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-11 00:48:42 +09:00
parent a7dbc15878
commit 811dfebf98
387 changed files with 106 additions and 5551 deletions
--- a/docs/archive/roadmap/phases/phase-21.6/README.md
+++ b/docs/archive/roadmap/phases/phase-21.6/README.md
@ -0,0 +1,51 @@
+# Phase 21.6 — Dual‑Emit Parity & C‑line Readiness
+
+Goal: Produce identical MIR(JSON) from both provider (Rust) and selfhost (Hako) builder paths, measure generation cost, and keep AOT (ny‑llvmc) fast/green. All work is semantics‑preserving; defaults remain unchanged.
+
+## Checklists
+
+- [ ] Dual‑emit parity on representative apps (MIR(JSON) normalized SHA1 equal)
+- [ ] Resolver‑first ON passes quick/integration
+- [ ] Selfhost‑first fallback ok (provider/legacy on failure)
+- [ ] AOT obj/exe via ny‑llvmc (crate backend) green
+- [ ] Docs updated (bench guides, env vars, quick recipes)
+
+## Scripts
+
+- Dual emit + compare + bench: `tools/perf/dual_emit_compare.sh <input.hako> [rounds]`
+- MIR emit bench: `tools/perf/bench_hakorune_emit_mir.sh <input.hako> [rounds]`
+- AOT bench: `tools/perf/bench_ny_mir_builder.sh <mir.json> [rounds]`
+- MIR diff: `tools/perf/compare_mir_json.sh <a.json> <b.json>`
+
+## Env Knobs
+
+- `HAKO_USING_RESOLVER_FIRST=1` (resolver‑first)
+- `HAKO_SELFHOST_BUILDER_FIRST=1` (selfhost→provider→legacy)
+- `HAKO_MIR_BUILDER_BOX=hako.mir.builder|min`
+- `NYASH_LLVM_BACKEND=crate`（ny‑llvmc）
+- `HAKO_LLVM_OPT_LEVEL=0|1`（AOT O0 既定）
+
+## Benchmarks — Tracking
+
+Record normalized parity and generation times here (edit in place).
+
+Legend: SHA1 = normalized JSON digest; Parity=Yes when SHA1 equal; Times are medians unless noted.
+
+| Benchmark (Hako)                         | Resolver | Parity | Provider p50 (ms) | Selfhost p50 (ms) | Notes |
+|------------------------------------------|----------|--------|-------------------|-------------------|-------|
+| apps/examples/json_query/main.hako       | off/on   |        |                   |                   |       |
+| apps/examples/json_pp/main.hako          | off/on   |        |                   |                   |       |
+| apps/examples/json_lint/main.hako        | off/on   |        |                   |                   |       |
+| apps/examples/json_query_min/main.hako   | off/on   |        |                   |                   |       |
+
+How to fill:
+1) Run `tools/perf/dual_emit_compare.sh <file> 5`
+2) Copy p50s from the summary lines and mark Parity based on `compare_mir_json.sh` output.
+3) Note any diffs (callee kinds/order/phi/meta) in Notes.
+
+## Next Steps
+
+- [ ] If parity holds on the above set, extend to apps/tests subset
+- [ ] If diffs remain, categorize and align either provider or selfhost output
+- [ ] Keep AOT line green under `HAKO_LLVM_OPT_LEVEL=0` and optional `=1` spot checks
+
--- a/docs/archive/roadmap/phases/phase-21.6/core_numeric_boxes.md
+++ b/docs/archive/roadmap/phases/phase-21.6/core_numeric_boxes.md
@ -0,0 +1,90 @@
+# Phase 21.6 — Core Numeric Boxes (Draft)
+
+Status: proposal (to refine at 21.6 kickoff)
+
+## Goal
+
+Provide explicit, low‑level numeric boxes that:
+
+- Give Nyash a “fair” core for int/f64 benchmarks against C.
+- Stay compatible with the existing ArrayBox API (no breaking changes).
+- Can be used both explicitly in `.hako` and (later) as conservative AotPrep targets.
+
+This phase focuses on design + minimal implementation; aggressive auto‑rewrites stay behind opt‑in flags.
+
+## Scope (21.6)
+
+- Design and add **IntArrayCore** numeric core (NyRT + Hako wrapper):
+  - NyRT: `IntArrayCore` box（Rust）with internal layout `Vec<i64>`（contiguous, row‑major semantics）。
+  - Hako: `IntArrayCoreBox` in `nyash.core.numeric.intarray`, wrapping NyRT via externcall:
+    - `static new(len: i64) -> IntArrayCoreBox` → `nyash.intarray.new_h`
+    - `length(self) -> i64` → `nyash.intarray.len_h`
+    - `get_unchecked(self, idx: i64) -> i64` → `nyash.intarray.get_hi`
+    - `set_unchecked(self, idx: i64, v: i64)` → `nyash.intarray.set_hii`
+  - Semantics: i64‑only、固定長（構造変更なし）。境界チェックは NyRT 側（Fail‑Fast）に限定し、Hako 側は数値カーネル専用の薄いラッパーに留める。
+
+- Design and add **MatI64** (matrix box) on top of IntArrayCore:
+  - Internal layout: `rows: i64`, `cols: i64`, `stride: i64`, `core: IntArrayCoreBox`.
+  - Minimal API:
+    - `new(rows: i64, cols: i64) -> MatI64`
+    - `rows(self) -> i64`, `cols(self) -> i64`
+    - `at(self, r: i64, c: i64) -> i64`
+    - `set(self, r: i64, c: i64, v: i64)`
+  - Provide one reference implementation:
+    - `MatOps.matmul_naive(a: MatI64, b: MatI64) -> MatI64` (O(n³), clear structure, not tuned).
+
+- Bench alignment:
+  - Add `matmul_core` benchmark:
+    - Nyash: MatI64 + IntArrayCore implementation.
+    - C: struct `{ int64_t *ptr; int64_t rows; int64_t cols; int64_t stride; }` + helper `get/set`.
+  - Keep existing `matmul` (ArrayBox vs raw `int*`) as “language‑level” benchmark.
+
+Out of scope for 21.6:
+
+- Auto‑rewrite from `ArrayBox` → `IntArrayCore` / `MatI64` in AotPrep (only sketched, not default).
+- SIMD / blocked matmul / cache‑tuned kernels (can be separate optimization phases).
+- f64/complex variants (only type skeletons, if any).
+
+## Design Notes
+
+- **Layering**
+  - Core: IntArrayCore (and future F64ArrayCore) are “muscle” boxes: minimal, numeric‑only. NyRT では IntArrayCore（Rust）、Hako では IntArrayCoreBox として露出。
+  - Matrix: MatI64 expresses 2D shape and indexing; it owns an IntArrayCoreBox.
+  - High‑level: ArrayBox / MapBox / existing user APIs remain unchanged.
+
+- **Hako ABI vs Nyash implementation**
+  - IntArrayCore lives as a NyRT box (C/Rust implementation) exposed via Hako ABI (`nyash.intarray.*`).
+  - IntArrayCoreBox, MatI64 and MatOps are written in Nyash, calling IntArrayCore via externcall while exposing boxcall APIs to user code.
+  - This keeps heavy lifting in NyRT while keeping the 2D semantics in `.hako`.
+
+- **Fair C comparison**
+  - For `matmul_core`, C should mirror IntArrayCore/MatI64:
+    - Same struct layout (ptr + len / rows + cols + stride).
+    - Same naive O(n³) algorithm.
+  - This separates:
+    - “Nyash vs C as languages” → existing `matmul` (ArrayBox vs `int*`).
+    - “Core numeric kernel parity” → new `matmul_core` (IntArrayCore vs equivalent C).
+
+## AotPrep / Future Work (21.6+)
+
+Not for default in 21.6, but to keep in mind:
+
+- Add conservative patterns in Collections/AotPrep to detect:
+  - `ArrayBox<i64>` with:
+    - Fixed length.
+    - No structural mutations after initialization.
+    - Access patterns of the form `base + i*cols + j` (or similar linear forms).
+  - Allow opt‑in rewrite from such patterns to IntArrayCore/MatI64 calls.
+
+- Keep all auto‑rewrites:
+  - Behind env toggles (e.g. `NYASH_AOT_INTARRAY_CORE=1`).
+  - Semantics‑preserving by construction; fall back to ArrayBox path when unsure.
+
+## Open Questions for 21.6 Kickoff
+
+- Exact module names:
+  - `nyash.core.intarray` / `nyash.core.matrix` vs `nyash.linalg.*`.
+- Bounds checking policy for IntArrayCore:
+  - Always on (fail‑fast) vs dev toggle for light checks in hot loops.
+- Interop:
+  - Whether MatI64 should expose its IntArrayCore (e.g. `as_core_row_major()`) for advanced users.