我要准备给领导讲 ccec （华为 NPU 编译器，基于 llvm）实现结构 （1）代码结构...
تم الإنشاء في: ١٦ أغسطس ٢٠٢٦
تمت الإجابة باستخدام GPT-5.6 Thinking بواسطة Chat01
سؤال
我要准备给领导讲 ccec （华为 NPU 编译器，基于 llvm）实现结构
（1）代码结构
（2）ccec特性能力
（3）多代际支持
应该具体需要哪些方面？
الفكرة
الإجابة
你现在列的三个方向是对的，但如果是给领导讲，建议不要只按“代码目录 / feature 列表 / 芯片型号”展开，而要形成一条主线：
CCEC 是什么 → 一份代码怎么变成 NPU 指令 → 华为在 LLVM 上做了哪些关键增强 → 新一代 NPU 来了以后怎么低成本接入。
公开资料可以确认，CCEC 是昇腾算子编译链中的编译器，工具链里能看到 clang/ccec、lld、llvm-objdump、llvm-ar 等 LLVM 系工具，因此“基于 LLVM、围绕 NPU Target 做扩展”是很适合用来组织汇报的视角。(Ascend Community)
我建议你具体准备下面这些内容。
一、代码结构：不要讲“有哪些目录”，要讲“职责怎么分层”
最好先画一张总架构：
textAscend C / CCE Source │ ▼ ┌─────────────────────┐ │ Driver / Clang FE │ │ 参数、语法、Builtin │ └──────────┬──────────┘ │ LLVM IR ▼ ┌─────────────────────┐ │ LLVM Middle-End │ │ 通用优化 + NPU优化 │ └──────────┬──────────┘ │ optimized IR ▼ ┌─────────────────────┐ │ CCE Backend │ │ ISel / Schedule │ │ RegAlloc / CodeGen │ └──────────┬──────────┘ │ ▼ CCE Object │ lld / linker ▼ Kernel Binary
然后代码结构重点讲下面几个维度，而不是把源码树截图放上去。
| 模块 | 建议讲什么 | 领导真正需要理解的点 |
|---|---|---|
| LLVM Base | 基于哪个 LLVM 分支、保留多少 upstream 代码 | CCEC 不是从零写编译器 |
| Driver | ccec/clang 参数、target选择、编译pipeline构建 | 编译入口 |
| Clang Frontend | NPU builtin、关键字、attribute、address space、intrinsic | 怎么把 NPU 编程模型暴露给开发者 |
| IR层 | LLVM IR，以及是否存在 CCE 特有 intrinsic/metadata | 前端和后端如何解耦 |
| Optimization | LLVM通用Pass + CCE/NPU专用Pass | 性能能力主要在哪里产生 |
| Backend | TargetLowering、ISel、DAG/GISel、调度、寄存器分配、CodeGen | 怎么真正映射到 NPU ISA |
| MC/Assembler | 指令编码、ELF、relocation等 | 怎么产生机器码 |
| Linker | lld / cce linker | kernel如何形成最终二进制 |
| Runtime ABI | kernel入口、参数传递、metadata等 | 编译器与 Runtime 的边界 |
| Test | LLVM lit/unit/ISA/性能测试 | 怎么保证改一代芯片不影响另一代 |
公开的 CCEC 工具链说明里，也明确列出了 ccec(clang)、lld、llvm-objdump、llvm-ar、llvm-nm、llvm-size 等组件，因此你可以顺势说明：整体仍然保持 LLVM 工具链形态，但核心差异集中在 NPU 前端语义、优化和 Backend。 (Ascend Community)
这里最好再准备一个非常具体的 “一条指令的源码旅程”。
比如任选一个你们源码里比较典型的 Vector Add / MatMul intrinsic：
textAscend C API ↓ Clang Builtin ↓ LLVM Intrinsic ↓ CCE Lowering ↓ MachineInstr ↓ ISA Instruction
然后现场打开源码，沿着这条路径把 4～5 个关键文件串起来。
这比讲几十个目录有效得多。
二、CCEC 特性能力：建议分成“四层能力”
不要变成：
支持 A、支持 B、支持 C……
领导很难形成认知。
应该回答：
CCEC 相比普通 LLVM Backend，多解决了哪些 NPU 特有问题？
1. 编程模型能力
包括：
语言/API层
例如：
- Ascend C / CCE 编程模型
__aicore__一类 kernel 语义- builtin / intrinsic
- 特殊 address space
- GM / UB / L1 等不同存储空间
- Vector / Cube / Scalar 等计算单元
- Pipe / Queue / Event / barrier 等同步模型
这里核心讲：
普通 CPU LLVM 看到的是“指令 + 寄存器 + Cache”，CCEC 需要理解 计算单元 + 存储层次 + 数据搬运 + Pipeline。
这是 NPU 编译器和 CPU 编译器最大的认知差异之一。
2. CodeGen 能力
这部分最好结合硬件结构讲。
textLLVM IR │ ├── Vector计算 ├── Cube计算 ├── Scalar计算 ├── Load/Store └── Synchronization ↓ Target Lowering ↓ Instruction Selection ↓ Instruction Scheduling ↓ Register Allocation ↓ Machine Code
重点可以挑：
① Instruction Selection
怎么把 LLVM operation / intrinsic 映射成 CCE ISA。
② Instruction Scheduling
NPU 往往有多个执行单元，所以不是简单决定：
textA B C
而是在解决：
textMTE : Load A ─ Load B ───────────── Cube: ───────── MMAD ────────────── Vec : ─────────────── PostProcess ─ MTE : ───────────────────── Store ─
也就是：
数据依赖 + 资源冲突 + latency + pipeline overlap。
③ Register / Resource Allocation
不仅是传统 LLVM register allocation，还要关注 NPU 特有资源约束。
3. Optimization 能力
这部分建议单独拉出来，因为这是领导通常最关注的：
“我们自研编译器的价值到底在哪里？”
建议分成：
textLLVM通用优化 + NPU通用优化 + 芯片代际特定优化
例如可以梳理你们实际代码中的：
textCanonicalization DCE CSE Loop Optimization Vectorization Instruction Combine Intrinsic Combine Memory Optimization Instruction Scheduling Software Pipeline Memory Reuse Load/Store Optimization Instruction Fusion
但一定不要只列 Pass 名字。
最好每类都回答：
text优化前是什么？ ↓ Pass做什么？ ↓ 优化后是什么？ ↓ 性能收益是什么？
这样就从“代码介绍”变成“技术价值介绍”。
4. 工具链能力
CCEC 不只是一个 compiler executable。
官方资料显示 CCEC 配套提供 linker、objdump、objcopy、nm、size、strip 等工具，因此可以把它描述成一套围绕 CCE kernel 的 LLVM-style toolchain。(Ascend Community)
这里可以讲：
textCompiler Assembler Linker Object tools Debug Dump Disassemble Profiling support Diagnostic
领导一般不需要知道参数，但要知道：
它覆盖了开发 → 编译 → 链接 → 调试 → 定位的完整闭环。
三、多代际支持：这个其实可以成为你整场汇报最有技术含量的一部分
这一部分千万不要只讲：
text支持 310 支持 910 支持 910B 支持 A2 支持 A3
那只是“产品列表”。
真正要讲的是：
同一套 compiler 如何同时容纳多套硬件能力。
可以画一个三层模型：
textCommon Compiler ┌────────────────────────────────┐ │ LLVM Common Optimization │ │ CCE Common Optimization │ │ Common CodeGen Framework │ └────────────────┬───────────────┘ │ Target Abstraction ┌────────────────────────────────┐ │ ISA Feature │ │ Register │ │ Pipeline │ │ Memory │ │ Latency / Cost Model │ └──────┬──────────┬──────────┬───┘ │ │ │ Gen1 Gen2 Gen3
这里你需要系统回答 6 个问题。
| 问题 | 要展示的设计 |
|---|---|
| 不同代芯片怎么识别？ | SoC / CPU / feature机制 |
| ISA新增怎么办？ | instruction definition + feature gating |
| 指令行为变化怎么办？ | lowering / pattern按feature区分 |
| latency变化怎么办？ | scheduling model |
| 存储/寄存器资源变化怎么办？ | target resource model |
| 优化策略变化怎么办？ | common pass + generation-specific pass |
公开接口中已经能看到明显的硬件版本抽象。例如 Ascend C 的平台接口提供 GetSocVersion() 获取硬件平台型号，并允许针对不同 SoC 设计不同 tiling 策略；当前文档还特别提到 A3 与 A2 在部分接口中的二进制复用设计。(Ascend Community)
ATC 侧同样有明确的 --soc_version target SoC 机制，当前公开文档覆盖 Atlas A2、A3 等产品。(Ascend Community)
所以你的 CCEC 汇报里，可以进一步往源码层追：
text-soc-version / -mcpu / feature │ ▼ TargetMachine │ ▼ SubtargetInfo / \ ISA Feature HW Feature │ │ ▼ ▼ Instruction Scheduler Selection Cost Model
具体名字以你们 CCEC 实际实现为准，但一定要把这条链路找出来。
四、我最建议你重点讲清楚的“多代际设计原则”
这一页会非常加分。
最理想的架构不是：
cppif (soc == Gen1) { ... } else if (soc == Gen2) { ... } else if (soc == Gen3) { ... }
到处散落这样的判断。
而应该是：
textFeature │ ┌─────────────┼─────────────┐ ▼ ▼ ▼ HasInstA HasCubeV2 HasMTEV3 │ │ │ └─────────────┼─────────────┘ ▼ Compiler Pipeline
也就是从：
“按芯片型号写代码”
演进成：
“按硬件能力 Feature 写代码”。
比如：
textGen1 = Base Gen2 = Base + NewVectorISA + LargerUB Gen3 = Base + NewVectorISA + NewCubeISA + NewPipeline
这样才能回答领导最关心的问题：
下一代芯片出来，需要改多少 compiler？
五、建议额外增加一个主题：CCEC 的“Common vs Custom”
这其实非常适合管理层。
直接画：
text┌───────────────────────────────┐ │ LLVM upstream │ │ Clang / IR / Pass / CodeGen │ │ MC / LLD / Object Tools │ └──────────────┬────────────────┘ │ reuse ▼ ┌───────────────────────────────┐ │ CCEC Common Layer │ │ NPU programming model │ │ NPU optimization │ │ CCE backend │ └──────────────┬────────────────┘ │ ▼ ┌───────────────────────────────┐ │ Generation Specific Layer │ │ ISA / Schedule / Feature │ │ Cost Model / Workaround │ └───────────────────────────────┘
然后回答三个比例：
复用 LLVM 什么？
CCEC 自己实现什么？
每代芯片新增什么？
这三个问题一回答清楚，领导基本就理解 CCEC 的技术架构了。
六、如果让我给领导讲，我会最终压缩成大约 8 页
你的汇报结构我会设计成：
P1：CCEC 定位
textAscend C ↓ CCEC ↓ CCE ISA ↓ Ascend NPU
一句话：
CCEC 是连接 NPU 编程模型与硬件 ISA 的核心编译层。
P2：整体编译 Pipeline
textSource → Clang → LLVM IR → Optimization → CCE Backend → Object → Link → Kernel Binary
P3：代码架构
重点展示：
textLLVM Common CCE Common Generation Specific
P4：Frontend / IR
展示：
textAPI → builtin → intrinsic → IR
P5：Backend
展示：
textLowering → ISel → Scheduling → RegAlloc → Emit
这页最好拿一条真实指令走全过程。
P6：核心优化能力
挑 3～5 个真正影响性能的优化，不要铺几十个 Pass。
P7：多代际支持
这是重点：
textTarget → Subtarget → Feature → ISA → Schedule → Optimization
再画：
textCommon / | \ Gen1 Gen2 Gen3
P8：演进价值
最后不要停在技术实现，要落到：
textLLVM复用 ↓ 降低基础编译器开发成本 Feature化硬件抽象 ↓ 降低新芯片接入成本 Common / Gen解耦 ↓ 降低多代维护成本 统一Compiler Infrastructure ↓ 持续积累优化能力
这才是领导视角下的结论。
你在准备材料时，我尤其建议你从 CCEC 源码中实际找出 5 条主线：ccec main/driver → TargetMachine 创建、一个 Ascend builtin → LLVM intrinsic、一个 intrinsic → CCE instruction、一个 CCE-specific optimization pass、soc/version → subtarget/feature → Gen-specific CodeGen。
只要这 5 条源码路径能够真正讲透，你的“代码结构、特性能力、多代际支持”三部分就全部串起来了，而且不会变成泛泛的 LLVM 架构介绍。公开资料目前主要能确认 CCEC 的工具链定位和 SoC 平台机制，具体源码目录、内部 Pass 名称和多代 Target 类结构仍应以你手里的 CCEC 源码为准，不建议根据公开博客猜内部实现。(Ascend Community)