Skip to content

docs: .ccr V8 §11.4 对账表 + .coi 的 C-10 引用漂移同步(#165 的续,两笔) - #166

Merged
dslsdzc merged 4 commits into
developfrom
feature/ccr-v8-recon
Sep 23, 2026
Merged

dslsdzc merged 4 commits into
developfrom
feature/ccr-v8-recon

Conversation

@dslsdzc

@dslsdzc dslsdzc commented Sep 22, 2026

Copy link
Copy Markdown
Owner

这是什么

#165 的续(follow-up)。#165 已落地维护者 2026-09-23 的四条裁定 + 一条文字修正;本 PR 落地随后那次对账的两个半。

为什么存在 / 为什么拆成两笔

因为对账的产出是一个动作。 两半分开落,会让引用漂移继续活着——.coi 档的读者仍会看到一条已被撤回的建议。

⇒ 两笔同批、各自一条提交信息、各只含一个文件(可逐笔核):

提交 文件 量
7abe30a3 docs/maintainer/design/ccr-v8-open-relational-lattice.md 1 file, 70+/1−
45613cb4 docs/maintainer/design/coi-optimization-knowledge-sidecar.md 1 file, 8+/0−
合计 2 files 78+/1−

第一半:V8 档 §11.4 对账 + U-18

判据 = 两档之间不得有第二份权威(「.ccr 里到底有哪些面」只能一处说了算)。12 项逐项给「.coi 档说法(带行号)| 本档说法(带节号)| 判定」:

  • ✅ 对齐 5:relation metadata(该档明确让渡权威)· RelationDomain vs 执行域(两档独立同构)· 「格」(该档引本档为权威)· .ccr→.coi 依赖方向 · 串表
  • 🟠 接缝 4:字符串/符号面粒度 · 面数口径(该档 6 行按段 vs 本档 4 面按语义)· 两套溯源机制 · cache-semantics.md 条款 1–7
  • 🔴 第一类命中 3(只登记不裁决)

写清的三件事:

  1. 读数范围:已读 §〇 / §一 / §四 ELF 后端全面修复 + panic handler + Arena 内存模型设计 #1#2#4 / §五 全节 / §9.1 / §15.3 + 各节标题;未读 §六–§八 / §十–§十四 / §十六–§廿六
    ⇒ 并明写「本表不声称全档穷尽」(这是本表能被信的前提),另加反向禁止:不得据「12 项」推断「两档已全面对齐」。
  2. 命中的判定依据:同一件事、两处各有一个说法、且两处各自自洽 ⇒ 命中——命中 ≠「谁错」,它说的是「读者会各引各的」。
  3. 命中 3 单独标出:引文逐字准确 ✓ 但引的是已撤回的建议
    —— 该档引 V8 档 42bc97cf 版的 C-10 结论 3,而 V8 档已改
    ⇒ 失效形态 = 「引文准确 + 引用陈旧」,不得与「引错对象」混入同一档(本仓已有「引文行号漂移」「引文内容错」两类先例,本条是第三类:被引方自己改了、引用方无从得知)。

§11.4.2 两条反向约束(本档接收 → 落在 V8 落地批的约束面):

  • C-11a .ccr 不得含对 .coi 的引用 ⇒ 四面清单不得新增「.coi 引用面」;版本/身份判别式不得把 .coi 存在性纳入输入
  • C-11b .coi 私有串表与 .ccr intern 池分离 ⇒ 落地批不得为省事合并两档串池(会同时违反本条与 C-1 的逐字节判据面)

U-18 由「未核」改为「已核 + 3 条命中待裁」。

第二半:.coi 档的 C-10 引用同步

  • 纯增量 8 insertions / 0 deletions,实质内容一字未动(逐行 diff 已确认:8 行全是 +,无一行 -)
  • 落点 = .coi 档 §〇.1 引 V8 档「核实结论 3」那处紧邻位置(引文块与 📌 块之间),不在别处另起一节
  • 内容:该建议已由 V8 档 dc19982b(现 6b54107e)撤回 —— 不再走「V8 侧改名」,改为「等 .coi 把 opt_meta 整节搬出 .ccr」;
    撤回理由 = 改名与搬迁同时做,会在迁移期引入第三种叫法
  • 并明写对本档结论无影响(「.coi 如何消解 C-10」的结论不受影响——它本来就是根因级处置;仅「V8 侧那条建议」作废)

⚠ 三条命中待维护者裁(本 PR 只登记,不裁决)

  1. .ccr 是否只装 target-independent(该档 :144「stores target-independent program relations」 vs V8 v2 §一.1「表达 HDFG 及其分析/映射产生的关系」+ 实体例 @deploy.gpu0 / tag target.register)
    —— 有工程后果:该档把「目标特定优化知识」划归自己,其部分理由正是这条边界 ⇒ 若 V8 的 .ccr 也可装 target-specific relation,边界判据松动,两档归属结论可能相反。
  2. 类型面 / 接口面 归谁(该档 :558/:559 以「语义面」为表头列「属于 .ccr」 vs V8 档 §十四 U-17「未定」)
  3. C-10 引用陈旧(= 本 PR 第二半已同步的那条)

⚠ 命中 1/2 涉及的内容,本 PR 一律未动(等裁定同批落,避免造出第三种说法);V8 档 U-17 亦未动。

自检(先立判据、后取数)

  • 停手闸:jj diff --from develop@origin --to @ = 2 files, 78+/1− ✓(先核过这条才推;若成 379+/62− 说明 rebase 点错,会停手)
  • 两笔各自的文件集已逐笔核:各只含一个文件,无越界 ✓
  • rebase 前后核 sha256、不核 commit id:4f40a371d50489850cc12c4f / d97919ea6a0651235beefedf 两值未变 ⇒ 内容零漂移 ✓
  • 零源码改动;无编译、无测试(纯文档批)

链:develop@origin(6b54107e,= #165 的 squash)→ 7abe30a3 → 45613cb4

…18 已核

按 lead 指示把对账结果落进本档。判据 = **两档之间不得有第二份权威**(「`.ccr` 里到底有哪些面」只能一处说了算)。

- 新增 **§十一.4**:对账表 **12 项**,逐项给「`.coi` 档说法(带行号)| 本档说法(带节号)| 判定」
  - ✅ **对齐 5**:relation metadata(该档明确让渡权威)· `RelationDomain` vs 执行域(两档独立同构)·
    「格」(该档引本档为权威)· `.ccr`→`.coi` 依赖方向 · 串表
  - 🟠 **接缝 4**:字符串/符号面粒度 · 面数口径(该档 6 行按段 vs 本档 4 面按语义)· 两套溯源机制 ·
    `cache-semantics.md` 条款 1–7
  - 🔴 **第一类命中 3**(**只登记不裁决**,已转维护者)
- 按 lead 要求写清**三件事**:
  ① **读数范围**(已读 §〇 / §一 / §四 #1#2#4 / §五 全节 / §9.1 / §15.3 + 各节标题;
     未读 §六–§八 / §十–§十四 / §十六–§廿六)+「**本表不声称全档穷尽**」声明
     —— 这句是**这张表能被信的前提**,必须留
  ② 命中的**判定依据**:**同一件事两处措辞、都自洽、读者会各引各的**(**不是「谁错」**)
  ③ **命中 3 单独标出**:**引文逐字准确 ✓ 但引的是本档已撤回的建议**——该档引本档 `42bc97cf` 版 C-10
     的「核实结论 3」;本档已于 `dc19982b` 改为「等 `opt_meta` 搬出、**不再走 V8 侧改名**」
     ⇒ 失效形态 = **「引文准确 + 引用陈旧」**,**不得与「引错对象」混入同一档**
- 新增 **§11.4.2 两条反向约束(本档接收 → 落在 V8 落地批的约束面)**:
  **C-11a** `.ccr` 不得含对 `.coi` 的引用(禁 sidecar 指针/期望哈希/「需配套」标记位;load 不得因 `.coi` 缺失而失败)·
  **C-11b** `.coi` 私有串表与 `.ccr` intern 池**分离**(判据 = `.coi` 串表增删不改 `.ccr` 任何字节)
- **§十四 U-18 由「未核」改为「已核 + 3 条命中待裁」**
- ⚠ **未改** U-17 及任何与命中 1/2 相关的既有内容(等维护者裁,同批落,避免造出第三种说法);
  ⚠ **未动** `.coi` 档(它已在 develop 上,改它要开新 PR)

顺带修复:上一编辑曾误删 `## 十二、三态计数与自查` 标题,已复原并复核 15 个 `##` 齐全。

三态计数不变(A = 9 / 7 / 21 · B = 46);**38 张表逐行 pipe 校验 0 失配**。零源码改动。无编译、无测试。
本笔**只加一条同步注,零实质内容改动**(`8 insertions(+), 0 deletions(-)`)。

- **落点**:§〇.1 引「V8 规格 §九 C-10」及其「我的核实结论 3」那处**旁边**(引文块与 📌 块之间),
  即该引用**紧邻**位置——不在别处另起一节
- **内容**:该建议已由 V8 规格档 **`dc19982b`** 撤回——**不再走「V8 侧改名」**,
  改为「**等 `.coi` 把 `opt_meta` 整节搬出 `.ccr`**」;
  **撤回理由 = 改名与搬迁同时做,会在迁移期引入第三种叫法**
- **明写对本档结论无影响**:下方「本文展开——`.coi` 如何消解 C-10」的结论**不受影响**
  (它本来就是根因级处置);**仅「V8 侧那条建议」作废**,本档实质内容无需改动
- **为什么与 §11.4 同批落**:这是**同一轮对账的产出**,拆成两个 PR 会**让引用漂移继续活着**——
  本档读者仍会看到一条**已被撤回的建议**
  (该失效形态已由 V8 规格档 §十一.4 命中 3 登记为「**引文准确 + 引用陈旧**」,
  与「引错对象」**不同档**)

⚠ **未动**本档任何实质内容——命中 1(`.ccr` 是否只装 target-independent)与命中 2(类型/接口面归属)
仍**等维护者裁**,现在动它们会**造出第三种说法**。
无编译、无测试(纯文档)。
维护者 2026-09-23 对 §11.4 的**命中 1 / 命中 2** 作出裁定。本笔只落这两条命中的处置;**命中 1/2 以外内容未动**。

**裁定原文(逐字,四条)**

1. **CCR 禁止 target-specific relation。**
2. **target-specific optimization knowledge → COI。**
3. **target 本身的 capability/topology/semantics → Target Model。**
4. **TYPE/IFACE 属于 Core 的通用语义 relation domain;关系进 CCR,合法性由 checker 负责。**

**落点(逐条对应;凡本文展开处已标)**

- **§〇.6 新增裁-5**:裁定原文逐字 + 落点表 + 两条连带效果
- **§五 5.1**(命中 1):加 **target-independence 约束**(裁定第 1 条)+ **三分流表**(第 2 / 3 条);
  判据形状新增第 4 条(机械钉子)——⚠ 明写该钉子的方向**取决于下方 (甲)/(乙) 裁决**
- **§三 3.3**(命中 2):TYPE/IFACE 性质按裁定改写(原「不得读成 RelationDomain 雏形」**已由裁定取代**);
  并保留「**现行载体** vs **V8 归属**」两分,**两者不得互推**
- §11.4.1 两条命中各加「✅ 已裁」块 · §11.4 计数块末记三条命中的收口状态
- §十四 **U-17 结项** · **U-18 更新**(三条命中均已收口)· §12.2 新增自查行 24

**本文在落点内新登记的两条待确认项(均未自行裁决)**

① **裁-5 第 3 条的档名对齐**:裁定写「**Target Model**」;`.coi` 档 §5.3 把同类内容记作
   「硬件能力描述 → HIT 表 / hw-map / `CapabilityDomain`」(`:581`)与「**canonical target model**」(`:582`)
   ⇒ **疑似同一物**,**标为疑似**,待维护者确认后再统一档名。
② 🔴 **`locatedAt(x, r12)` 与「禁止 target-specific」的关系**:v2 原文**自己的** relation 例含 `locatedAt(x, r12)`
   (`r12` 是**目标寄存器**),而 `.coi` §5.2「分配决策(var → 物理寄存器)」行(`:568`)把同类信息判为
   **优化知识、应迁 `.coi`** ⇒ **两处同向指向**「寄存器位置这类信息应出 `.ccr`」。
   两种读法:**(甲)** 该约束只针对**优化类关系**,结构性的 `locatedAt` 不受限;**(乙)** 严格字面 ⇒ v2 原文该例须撤。
   **本文按 (甲) 读并标为展开**;**(乙) 若成立,§三 3.2 的 v2 原文引例需维护者同批处置**——**本文不自行处置引例**。

**连带(本文展开)**

- 裁-5 第 1 条**同时坐实** `.coi` 档 §5.1 的前提(「`.ccr` 只装 target-independent」**现在是裁定、不再是默认**)
  ⇒ **该档无需改动**
- 命中 2 的处置方向 = **「V8 侧补明性质」**,**不是**「让 `.coi` 改」(该档 `:558`/`:559` 与裁定一致)

**自检**

- 本笔只动一个文件:**`1 file changed, 102+/8−`**(`.coi` 档**未动**)
- **★推前判据** `jj diff --from develop@origin --to @` = **2 files, 180+/9−**
  (原 78+/1−;涨幅 **+102/+8 = 本笔**,**对上上面列出的 8 处落点**)
- 三态计数 **10 / 7 / 21**(已实现 +1 = §三 3.3 新写的现状断言,**已按本档规矩补 `file:line`**)
- 表格 **39 张**逐行 pipe 校验 **0 失配**
- 无编译、无测试(纯文档)
§11.4 计数块末登记的待确认项 ①(裁-5 第 3 条的档名对齐)由 **本批 lead 裁定**收口。

**裁定内容(非维护者原话,出处分级如下)**

- **档名:统一用「Target Model」**(lead 裁定,2026-09-23)
- **`.coi` 档 §5.3 那两行(`:581` 硬件能力描述 · `:582` canonical target model)不冲突、不改**——
  它们在 `.coi` 档里是**非目标(non-goal)表述**:该档原文非目标清单列有「a canonical target model」

**本文落纸前的独立核验(不凭转述)**

- `.coi:664` = `- a canonical target model;`,**确在非目标清单内**(§七 原文 §4 段);
- 该档 `:1009` 自注更直接写明「**原文 §4 明列 `.coi` 不是 canonical target model**」⇒ **lead 的读法有出处** ✓

⇒ 与裁-5 第 3 条是**同一件事的两面**:**`.ccr` 不装 · `.coi` 不是 · 另有 Target Model 承担**。

**改动(2 处)**

1. **§五 5.1**:原「⚠ 第 3 条的档名**待对齐**(本文登记,不裁决)」→ **「✅ 已裁」**,
   含档名统一、`.coi` 那两行的非目标性质、以及「**`.coi` 档不得改动**(它那两行本来就对)」;
   并明写**本文此后一律用「Target Model」**(不再写「疑似 = canonical target model」)。
2. **§11.4 计数块末**:待确认项 **2 条 → 1 条**(① 已裁;② `locatedAt(x,r12)` 的 (甲)/(乙) 仍**维护者裁定中**,
   本文**暂按 (甲) 读并保留「本文展开」标注**,见 §五 5.1 的 🔴 登记)。§十四 U-18 尾部的指针同步为「余下 1 条」。

**未动**:`.coi` 档(本笔 **1 file changed**)· ② 的 (甲) 读法与标注 · 命中 3 · 任何命中 1/2 以外的内容。

**自检**

- 本笔:**1 file changed, 13+/9−**(全在 V8 档)
- **★推前判据** `jj diff --from develop@origin --to @` = **2 files, 184+/9−**(原 180+/9−;净 **+4**)
  —— 净涨幅 **+4** = §五 那处注净增 3 行 + 计数块净增 1 行,**对得上**(本笔的 13+/9− 中多数是被改写的、原属上一笔的新增行)
- 三态计数 **10 / 7 / 21**(未变)· 表格 **39 张 0 失配**
- 无编译、无测试(纯文档)
@dslsdzc
dslsdzc merged commit 9f66a6d into develop Sep 23, 2026
4 checks passed
@dslsdzc
dslsdzc deleted the feature/ccr-v8-recon branch September 23, 2026 04:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant