compiler-pilot

ywgrit

Overview

  • Loop engineering
  • Wiki
  • review系统
  • compiler-workflow

Loop Engineering

单轮 Prompt 的问题

  • Agent 每轮都重新理解任务
  • 前一轮的失败原因、dump 证据、benchmark 结果容易丢
  • prompt 越写越长，任务需求、领域知识、工作流规则混在一起
  • llm少次推理承担繁重任务，batch太大，注意力分散

Coding / Review 分离

角色 关注点
Coding Agent 按 plan 实现
Review Agent 找 bug、回归、缺测试、证据断点
Human 判断风险和下一层验证

分离的价值：LLM的workaound特性不可避免，开启新上下文避免agent自我欺骗

Loop中在每一次迭代中应该沉淀什么？

  • 注入的提示
  • 读过的知识
  • dump / GDB / benchmark / perf 结果
  • 尝试过但放弃的方向和原因

Loop Engineering

Wiki

raw source 的缺陷

  • 手册不具备任务导航功能
  • 一个知识点分散在多个文档中，无法直接得到确定信息
  • Agent 每次直接读 source，都要重新检索、重新综合
  • 原始资料不会自动沉淀实践中犯过的错误

Wiki 的核心变化

Raw sources
  ↓
Structured wiki pages
  ↓
Query indexes
  ↓
Task-specific retrieval

RAG 是每次问时重新找资料。
Wiki 是把资料消化成可维护的中间表示。

Wiki 的好处

  • 持久化：一次整理，多次复用
  • 结构化：frontmatter / tags / sources / related
  • 可导航：按问题、领域模块、领域技术点进入
  • 可沉淀：agent 犯错后，把缺失知识补进 wiki
  • 可验证：validate / generate-indices 保持健康

GCCWiki 结构

为什么gccwiki需要联合搜索

联合搜索怎样实现

gccwiki具体查询流程

案例一：Inline Pass 修复

案例二：mysql优化

Review 系统

compiler-workflow

设计原则

  • GCC 开发是 correctness-dominated
  • 默认交付物是可审查文档，而不是补丁
  • pass 开发先参考领域特定知识产出 docs/draft.md
  • bug 修复先参考领域特定知识产出 docs/triage.md
  • 人审后进入 agent loop，agent loop继续参考领域特定知识

四部分组成

组成 作用
draft / triage / plan 把口头任务变成可审查设计
GCCWiki agent 应该知道什么
GCCSkill agent 应该怎么操作
review系统 保证代码质量

GCCWiki 是知识库

GCCSkill 是操作手册

Pass 开发流程

Bug 修复流程

诊断阶段不改 GCC 源码。

docs/draft.md 要回答什么？

  • Pattern Recognition Strategy
  • Transformation Legality Checks
  • IR and Data-Flow Invariants
  • Pass Ordering with anchor-pass evidence
  • Files / APIs / Testing / Open Questions

docs/triage.md 要回答什么？

  • trunk 复现状态
  • oracle validation，排除 UB
  • 最小复现或 reduction 计划
  • failing pass / suspected component
  • dump / GDB evidence
  • root-cause hypothesis

compiler Workflow

TODO

  • 补更多真实 GCC pass / bug 案例
  • 如何将agent的工作反馈沉淀到 wiki❓
  • 如何组织wiki才能高效索引，跟踪agent执行任务的流程🤔
  • 如何保证agent对于wiki维护质量🤔

Q & A