Pull Request

描述

TilingFunc 拆分编译场景中，每个翻译单元原先都会展开完整的 autofuse_tiling_func_common.h，多 group 并发编译时会重复解析与当前 .cpp 无关的标准库、运行时声明和结构体定义。本 PR 引入显式源码依赖模型，将公共内容拆为自包含原子头，并按生成代码的实际依赖渲染每个翻译单元，降低 host 编译的预处理、解析时间和峰值内存。

修改方案

显式依赖模型

新增 autofuse/common/tiling_source_dependencies.h，统一描述和渲染生成源码：

自包含原子头与按需 include

• 生成 State、Log、PGO、Solver、API 五类原子头，autofuse_tiling_data.h 保持独立。
• 原子头之间不互相 include，仅包含定义自身所必需的标准头和外部头。
• group、tail、solver、entry 根据实际生成的代码片段登记依赖；可选的变量关系、PGO runtime、CV fusion、workspace 表达式仅在使用对应能力时引入相关头文件。
• Operator Cache 的 HIT/MISS/SAVE 日志、命中计数和缓存老化行为保持不变。

TF、Inductor 与兼容路径

• TF 路径由 asc_codegen_compile.py 按固定 key 将原子头和 .cpp 直接落盘；原子格式不再落盘 autofuse_tiling_func_common.h。
• Inductor 路径通过 marker stream 传输固定 key，由 compile_adapter.py 解析并落盘；marker 不进入实际编译文件。
• 未携带 State key 的既有输入继续使用 common 格式；Base、Entry、Tail key 保留为历史输入兼容项。

flowchart LR
    A[ATT 与 Codegen 生成代码片段] --> B[登记正文与直接依赖]
    B --> C[统一合并去重与渲染]
    C --> D[State Log PGO Solver API 原子头]
    C --> E[按需 include 的翻译单元]
    D --> F{消费路径}
    E --> F
    F -->|TF| G[按固定 key 直接落盘]
    F -->|Inductor| H[marker 解析后落盘]
    F -->|Legacy| I[common 格式兼容]
    G --> J[host compile]
    H --> J
    I --> J

变更类型

• Bug 修复
• 新功能
• 代码风格更新
• 重构
• 构建过程或辅助工具的变动
• 文档内容更新

关联的 Issue

无。

测试验证

编译性能收益

使用相同生成正文和相同翻译单元数量，以“每个翻译单元包含完整 common 头”为基线。测试环境为 CANN 9.1、GCC 9；串行编译 5 轮、8 并发编译 7 轮，取中位数；RSS 为单个编译进程峰值。

TF 和 Inductor 场景的预处理展开代码分别减少约 10.7 万行和 12.2 万行，include tree 节点分别下降 15.4% 和 21.4%。

五组原子头 marker 的协议开销为 460 bytes，相对单组 marker 净增约 368 bytes；在 unique topn 和 multi concat 的 host_impl 中分别约占 0.22% 和 0.15%。marker 解析后不进入 .h/.cpp，不影响 host 编译。

核对清单

• 代码遵循项目代码风格
• 已完成相关自测和回归测试
• 已更新相关测试
• 标题使用合适的类型标签
• 已阅读并遵守贡献指南

变更范围