深入解析 PyPTO Pass 模块分析模板从 PreCheck 到 OPCode 特判的系统化代码分析方法【免费下载链接】pyptoPyPTO发音: pai p-t-oParallel Tensor/Tile Operation编程范式。项目地址: https://gitcode.com/cann/pypto导读PyPTOParallel Tensor/Tile Operation 编程范式在将 Tensor 图逐步编译为可执行代码的过程中依赖framework/src/passes下的数十个 Pass 完成图优化与图变换。面对如此庞杂的 Pass 集合开发者往往难以快速定位某个 Pass 的入口函数、梳理其处理流程、识别其对各 OPCode 的特判逻辑。本文以仓库中 Pass_Analysis_Template.md 为骨架结合framework/src/passes的真实源码系统讲解如何对任意一个 PyPTO Pass 进行概述 → 代码 → 业务 → 特判 → 总结五个维度的结构化分析并给出可直接套用的文档编写规范。读完后你将掌握一套可复用的 Pass 分析方法论能够独立产出一份事实准确、结构统一、便于评审与检索的 Pass 模块分析文档。1. 模板定位它是什么、服务于谁Pass_Analysis_Template.md是pypto-pass-module-analyzer技能定义见 SKILL.md的核心输出规范。该技能的使用场景非常明确当需要理解 PyPTO pass 中某个模块的代码、功能和设计时通过以下触发语句唤起分析 Pass 代码 XXX如分析 Pass 代码 RemoveRedundantReshape分析 XXX Pass 代码、查看 XXX Pass 代码XXX Pass 代码分析技能的执行流程分两种场景场景 1用户提供了输入文档时先确认文档描述的 Pass 模块、总结文档内容再到framework/src/passes中定位对应源码交叉印证场景 2未指定文档时通过pass_manager.cpp中RegDefaultStrategy()注册的 Pass 清单见 pass_manager.cpp向用户展示全部 Pass 供选择或对全部 Pass 逐一分析。最终统一按照本模板的七章结构输出。因此本模板实质上定义了 PyPTO 仓库中Pass 分析文档的写作契约任何一份 Pass 分析文档都必须回答这个 Pass 是什么、代码怎么写、业务上解决什么、对哪些 OPCode 特判、结论与文件清单这五类问题。2. 分析前的必备背景PyPTO Pass 的运行时骨架要正确填写模板首先需要理解模板中出现的概念在 PyPTO 源码中的真实对应物。以下四个文件构成了理解任意 Pass 的底层框架。2.1 Pass 的四种类型模板第 1 章要求填写Pass 类型其取值在 pass_type.h 中定义enum class PassType : int32_t { TYPE_INVALID -1, TYPE_TENSOR_GRAPH 0, TYPE_TILE_GRAPH 1, TYPE_BLOCK_GRAPH 2, TYPE_BOTTOM };结合 pass_manager.cpp 的头文件包含关系可以清晰看出三段式流水线Tensor Graph Pass作用在 Tensor 图上的优化与规整如InferTensorFormat、RemoveRedundantReshape、AutoCast、InferMemoryConflict、RemoveUndrivenView、ExpandFunction、LoopUnroll等Tile Graph Pass作用于 Tile 图分块后的图如GraphPartition、CommonOperationEliminate、NBufferMerge、L1CopyInReuseMerge、SubgraphToFunction等Block Graph PassExecute Graph Pass作用于执行块图如MemoryReuse、InsertSync、OoOSchedule、CodegenPreproc、CopyOutResolve、LastUseMark等。PassName枚举与kPassNameStringMappass_type.h为每个 Pass 提供了机器可读的枚举名与人类可读的字符串名这是后续查找、注册与文档命名的依据。2.2 Pass 基类的生命周期PreCheck / RunOnFunction / PostCheck模板第 2 章将处理流程拆成 PreCheck、RunOnFunction、PostCheck 三个阶段这正是 pass.h 中抽象基类Pass的运行时骨架。基类定义了虚函数virtual Status Run(Function function, const std::string strategy, const std::string identifier, size_t runtimeIdx, const std::string logStrategy); virtual Status PreCheck(Function function); // 可选检查默认返回 SUCCESS virtual Status PostCheck(Function function); // 可选检查默认返回 SUCCESS virtual Status DefaultEnabledPreCheck(Function function); // 默认启用检查 virtual Status DefaultEnabledPostCheck(Function function); // 默认启用检查 virtual void Reset() {}; protected: virtual Status RunOnFunction(Function function) 0; // 纯虚函数必须实现Run的完整执行序列在 pass.cpp 中实现顺序为记录identifier_、strategy_、logStrategy_、passRuntimeIndex_若passDfxconfigs_.disablePass为真直接跳过并返回 SUCCESS执行PreRun打印/导出 Pass 运行前的图PrintFunction、handlePreRunDumpGraph然后依次调用DefaultEnabledPreCheck与PreCheck后者受passDfxconfigs_.preCheck开关控制执行纯虚函数RunOnFunction这是每个 Pass 的核心业务逻辑所在执行PostRun打印/导出 Pass 运行后的图依次调用DefaultEnabledPostCheck与PostCheck受postCheck开关控制。因此模板中PreCheck → RunOnFunction → PostCheck的三阶段划分不是写作上的任意编排而是对Pass::Run实际调用顺序的忠实映射。模板在 PreCheck/PostCheck 小节中要求描述检查失败的处理方式在源码中的对应行为是返回FAILED状态并记录APASS_LOG_ERROR_F日志最终导致RunPass中断编译流程见 pass_manager.cpp。2.3 Pass 的注册与调度模板第 6 章要求列出相关文件其中通常包含 Pass 注册与策略编排文件。PyPTO 采用注册表 策略的调度模型注册REG_PASS(RemoveRedundantReshape)等宏调用pass_manager.cpp通过 pass_registry.h 中的PassRegistrar将派生类以名称 → 工厂函数的形式登记到PassRegistry并做编译期类型检查is_base_of_vPass, DerivedPass与名称一致性断言策略编排RegDefaultStrategy()注册了PVC2_OOO含 45 个 Pass覆盖 Tensor/Tile/Block 三阶段、FunctionUnroll仅LoopUnroll、ExecuteGraphDynAttrToStatic、LoopaxesProc三个策略运行PassManager::RunPass按策略顺序遍历 PassEntry逐一CreatePass、设置调试配置、调用pass-Run并通过MonitorPassCompileScope记录每个 Pass 的编译耗时。GetStrategyPassespass_manager.cpp还体现了 Pass 的NPUArch 架构过滤机制每个 Pass 可以通过SetSupportedArches声明其支持的芯片架构运行时会根据当前平台自动跳过不支持的 Pass。分析文档在适用场景章节应结合此类信息说明 Pass 的生效前提。3. 模板逐章详解每个章节写什么、怎么写、源码依据在哪3.1 第一章Pass 概述概述章节是全文的摘要卡片只需填写三个字段Pass 名称使用kPassNameStringMap中的字符串名如RemoveRedundantReshape保证与注册名、日志名一致Pass 类型从 Tensor Graph Pass / Tile Graph Pass / Block Graph Pass 中选取依据是PassType枚举及其在pass_manager.cpp中的 include 分组简要描述用 12 句话概括业务功能。可参考类注释与构造函数的命名如RemoveRedundantReshape类在 remove_redundant_reshape.h 中继承Pass并以RemoveRedundantReshape作为注册名。3.2 第二章代码分析3.2.1 主要功能本节需要回答三个问题Pass 解决什么问题、主要处理目标是什么、输入输出有何特点。分析切入点包括类头文件中的成员函数声明如RemoveRedundantReshape声明了RemoveReshape私有方法初步勾勒职责边界RunOnFunction的函数体这是每个 Pass 的大脑单元测试与集成测试中对图结构变化的断言可以反推 Pass 的输入/输出不变量。3.2.2 处理流程三阶段PreCheck 阶段区分两类检查——DefaultEnabledPreCheck默认强制执行用于校验 Pass 运行的前提条件是否满足与PreCheck由配置项preCheck控制的可选检查。分析时应说明PreChecker 的作用、检查的具体内容如断言图中不存在某类非法结构、失败后的处理方式返回FAILED终止编译并打印错误日志。RunOnFunction 阶段这是分析的重头戏。应描述入口函数的主要流程、遍历 Operation 的方式是遍历 Function 内所有 Operation 还是按特定容器/图结构遍历、核心处理步骤如识别可删除的 Reshape 节点 → 判断是否满足删除条件 → 重连边并删除节点。PostCheck 阶段说明DefaultEnabledPostCheck与PostCheck验证的具体内容通常是Pass 运行后图结构仍然合法所有 Tensor 的 use-def 链完整无悬空引用等不变量校验。3.2.3 关键函数的核心逻辑对每个关键函数按统一格式输出功能 / 输入 / 输出 / 算法复杂度 / 核心逻辑。模板特别强调算法复杂度要与 Function 中的 Operation、Tensor 或 Incast/Outcast 数量挂钩——这是 PyPTO 分析文档的特色要求因为 Pass 通常需要对图中的每个节点做遍历复杂度自然以O(N)N 为 Operation 数、O(N·M)对每对 Operation 组合做分析等形式表达。建议按如下结构组织函数 1[函数名称]通常是RunOnFunction功能Pass 的入口与总调度输入Function引用内含 Operation 与 Tensor 图输出StatusSUCCESS/FAILED并产生图的副作用修改算法复杂度与图中 Operation/Tensor 数量相关核心逻辑分步骤描述遍历与变换过程。函数 2[关键业务函数]如RemoveReshape描述被RunOnFunction调用的具体变换逻辑。3.2.4 核心流程图模板提供两种呈现方式Mermaid 流程图或分步文字描述。推荐优先使用 Mermaid模板已给出graph TD示例骨架将 PreCheck → 条件判断 → RunOnFunction 各步骤 → PostCheck 的流转画出来。流程图应体现判断条件分支如Reshape 是否冗余与代码中的实际if分支一一对应保证流程图可追溯、可校对。3.3 第三章业务分析本章将代码分析结论翻译成业务语言包含三小节适用场景什么样的图结构会触发此 Pass、什么样的模式会被优化、什么情况下需要运行。可结合 Pass 在策略中的位置说明如RemoveRedundantReshape在PVC2_OOO中紧跟InferTensorFormat可推断其处理前提是格式推导完成后的图优化效果从性能提升、内存节省、代码简化等维度归纳收益。注意只能陈述源码可证实的效果如删除冗余节点减少后续 Pass 与代码生成的工作量禁止编造性能数据典型应用场景模板明确要求必须包含具体示例通过输入图结构 → 输出图结构 → 优化效果三段式描述用 Operation 与 Tensor 组合成的逻辑视图展示 Pass 前后的差异。例如 RemoveRedundantReshape 的典型场景Reshape(A) → Op → Reshape链中若中间形状未发生实际数据重排则可删除冗余的 Reshape 节点直接连通。示例应当以图中真实存在的 OPCode如OP_VIEW、OP_ASSEMBLE、OP_RESHAPE为基础绘制。3.4 第四章OPCode 特判分析模板最具特色的章节模板与技能说明SKILL.md共同定义了 OPCode 特判分析的完整方法论三类必须重点记录的视图类 OPCodeOPCode含义需要特判的原因推断OP_VIEW视图操作创建张量视图视图不产生实际数据拷贝很多 Pass 需跳过或特殊处理以避免破坏视图语义OP_ASSEMBLE组装操作组装张量涉及多个输入张量的拼接需保证组装语义不被变换破坏OP_RESHAPE重塑操作改变张量形状形状变换节点是 Pass 图变换的常见锚点需判断是否冗余、是否可融合搜索特判代码的四种模式来自技能说明直接特判if (op-GetOpcode() Opcode::OP_XXX)集合特判if (xxxOps.count(op-GetOpcode()) 0)否定特判if (op-GetOpcode() ! Opcode::OP_XXX)多重特判if (op-GetOpcode() Opcode::OP_XXX || op-GetOpcode() Opcode::OP_YYY)记录格式每个特判条目必须包含五个要素——特判的 OPCode、特判条件、特判位置给出函数名即可不需行号、处理逻辑、业务含义。特判分类将收集到的特判按处理方式归类为跳过处理、特殊处理、禁止操作、兼容处理四类并在总结章节的注意事项中呈现。3.5 第五七章总结、相关文件与附录总结提炼核心价值、主要特点、使用建议与适用范围同时汇总第四章梳理的注意事项尤其是视图类 OPCode 的特殊处理逻辑相关文件区分主要实现文件如framework/src/passes/tensor_graph_pass/remove_redundant_reshape.h/.cpp与辅助文件如 Pass 基类、注册器、策略管理器、对应测试文件附录包括术语表解释 Tensor Graph、Tile Graph、Incast/Outcast、OPCode 等术语、参考资料与修改历史格式为年/月/日修改内容。4. 输出文件的命名与格式规范技能定义了严格的输出文件命名规则SKILL.md分析文档产出时必须遵守位于PVC2_OOO策略中的 Pass查询 pass_manager.cpp 中BuildPvc2OooPassEntries的 Pass 顺序文件命名为{序号}_{PASS名称}.md序号为两位数字从00开始。例如按该策略顺序InferTensorFormat对应00_InferTensorFormat.md、RemoveRedundantReshape对应01_RemoveRedundantReshape.md不在PVC2_OOO策略中的 Pass统一以99_开头如99_DynAttrToStatic.md。格式层面的两条硬性要求不要输出大段代码需要的地方只输出函数名输出完成后要重新检查一次文档格式是否统一。5. 结合源码的实战示例以 RemoveRedundantReshape 为例为了直观演示模板填写方法下面以真实源码RemoveRedundantReshape为样本给出各章节的填写要点Pass 概述名称RemoveRedundantReshape类型 Tensor Graph Pass功能为删除图中冗余的 Reshape 节点。其头文件 remove_redundant_reshape.h 表明该类重写了DefaultEnabledPreCheck、PreCheck、PostCheck、RunOnFunction四个虚函数并额外定义了RemoveReshape业务函数——这就是代码分析章节的函数清单来源处理流程PreCheck校验图中 Reshape 节点及形状信息的合法性RunOnFunction遍历所有OP_RESHAPE节点并调用RemoveReshape判断冗余性PostCheck校验删除后图的连通性与语义完整性OPCode 特判该 Pass 的核心特判对象正是视图类 OPCode 中的OP_RESHAPE——对GetOpcode() Opcode::OP_RESHAPE的节点做冗余判定如连续两次 Reshape 可合并、形状未改变的 Reshape 可删除同时需检查其相邻的OP_VIEW/OP_ASSEMBLE节点以保证视图语义不被破坏相关文件主要实现文件为framework/src/passes/tensor_graph_pass/remove_redundant_reshape.h与.cpp辅助文件包括 Pass 基类framework/src/passes/pass_interface/pass.h、注册表framework/src/passes/pass_mgr/pass_registry.h、策略管理器framework/src/passes/pass_mgr/pass_manager.cpp以及framework/tests下的对应单元测试。6. 总结与实践建议Pass_Analysis_Template.md的价值在于把读懂一个 Pass这件看似模糊的工作拆解为七个可执行、可检查、可复用的步骤。使用时的关键实践建议先定位再分析通过kPassNameStringMap、RegDefaultStrategy与REG_PASS宏三处信息交叉确认 Pass 的类型、策略位置与注册名称避免张冠李戴流程对应源码PreCheck/RunOnFunction/PostCheck 三阶段必须与 pass.cpp 中PreRun/PostRun的实际调用顺序对应注意区分默认检查与可选检查特判穷尽搜索在 Pass 源码中系统性搜索GetOpcode()/GetOpCode()判断与Opcode::OP_常量重点记录OP_VIEW、OP_ASSEMBLE、OP_RESHAPE三类视图类 OPCode 的特判条件、位置与处理逻辑并归入跳过/特殊/禁止/兼容四类示例必须落地典型应用场景必须给出具体的输入/输出图结构与优化前后对比杜绝空泛描述遵守命名与格式按PVC2_OOO序号或99_前缀命名输出文件正文只给函数名不给大段代码输出后统一复核格式。按此方法产出的 Pass 分析文档既是团队评审的交流载体也是后续开发者快速上手某个 Pass 模块的第一手资料更可为 OPCode 特判等易错点提供长期的代码级备忘。相关文件索引模板本体Pass_Analysis_Template.md技能说明SKILL.mdPass 基类pass.h、pass.cppPass 类型与名称映射pass_type.hPass 注册与策略pass_registry.h、pass_manager.cpp示例 Pass 实现remove_redundant_reshape.h、framework/src/passes/tensor_graph_pass/remove_redundant_reshape.cppPass 源码目录framework/src/passes/含tensor_graph_pass/、tile_graph_pass/、block_graph_pass/、pass_check/、pass_mgr/等子目录【免费下载链接】pyptoPyPTO发音: pai p-t-oParallel Tensor/Tile Operation编程范式。项目地址: https://gitcode.com/cann/pypto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 深入解析 PyPTO Pass 模块分析模板：从 PreCheck 到 OPCode 特判的系统化代码分析方法
深入解析 PyPTO Pass 模块分析模板从 PreCheck 到 OPCode 特判的系统化代码分析方法【免费下载链接】pyptoPyPTO发音: pai p-t-oParallel Tensor/Tile Operation编程范式。项目地址: https://gitcode.com/cann/pypto导读PyPTOParallel Tensor/Tile Operation 编程范式在将 Tensor 图逐步编译为可执行代码的过程中依赖framework/src/passes下的数十个 Pass 完成图优化与图变换。面对如此庞杂的 Pass 集合开发者往往难以快速定位某个 Pass 的入口函数、梳理其处理流程、识别其对各 OPCode 的特判逻辑。本文以仓库中 Pass_Analysis_Template.md 为骨架结合framework/src/passes的真实源码系统讲解如何对任意一个 PyPTO Pass 进行概述 → 代码 → 业务 → 特判 → 总结五个维度的结构化分析并给出可直接套用的文档编写规范。读完后你将掌握一套可复用的 Pass 分析方法论能够独立产出一份事实准确、结构统一、便于评审与检索的 Pass 模块分析文档。1. 模板定位它是什么、服务于谁Pass_Analysis_Template.md是pypto-pass-module-analyzer技能定义见 SKILL.md的核心输出规范。该技能的使用场景非常明确当需要理解 PyPTO pass 中某个模块的代码、功能和设计时通过以下触发语句唤起分析 Pass 代码 XXX如分析 Pass 代码 RemoveRedundantReshape分析 XXX Pass 代码、查看 XXX Pass 代码XXX Pass 代码分析技能的执行流程分两种场景场景 1用户提供了输入文档时先确认文档描述的 Pass 模块、总结文档内容再到framework/src/passes中定位对应源码交叉印证场景 2未指定文档时通过pass_manager.cpp中RegDefaultStrategy()注册的 Pass 清单见 pass_manager.cpp向用户展示全部 Pass 供选择或对全部 Pass 逐一分析。最终统一按照本模板的七章结构输出。因此本模板实质上定义了 PyPTO 仓库中Pass 分析文档的写作契约任何一份 Pass 分析文档都必须回答这个 Pass 是什么、代码怎么写、业务上解决什么、对哪些 OPCode 特判、结论与文件清单这五类问题。2. 分析前的必备背景PyPTO Pass 的运行时骨架要正确填写模板首先需要理解模板中出现的概念在 PyPTO 源码中的真实对应物。以下四个文件构成了理解任意 Pass 的底层框架。2.1 Pass 的四种类型模板第 1 章要求填写Pass 类型其取值在 pass_type.h 中定义enum class PassType : int32_t { TYPE_INVALID -1, TYPE_TENSOR_GRAPH 0, TYPE_TILE_GRAPH 1, TYPE_BLOCK_GRAPH 2, TYPE_BOTTOM };结合 pass_manager.cpp 的头文件包含关系可以清晰看出三段式流水线Tensor Graph Pass作用在 Tensor 图上的优化与规整如InferTensorFormat、RemoveRedundantReshape、AutoCast、InferMemoryConflict、RemoveUndrivenView、ExpandFunction、LoopUnroll等Tile Graph Pass作用于 Tile 图分块后的图如GraphPartition、CommonOperationEliminate、NBufferMerge、L1CopyInReuseMerge、SubgraphToFunction等Block Graph PassExecute Graph Pass作用于执行块图如MemoryReuse、InsertSync、OoOSchedule、CodegenPreproc、CopyOutResolve、LastUseMark等。PassName枚举与kPassNameStringMappass_type.h为每个 Pass 提供了机器可读的枚举名与人类可读的字符串名这是后续查找、注册与文档命名的依据。2.2 Pass 基类的生命周期PreCheck / RunOnFunction / PostCheck模板第 2 章将处理流程拆成 PreCheck、RunOnFunction、PostCheck 三个阶段这正是 pass.h 中抽象基类Pass的运行时骨架。基类定义了虚函数virtual Status Run(Function function, const std::string strategy, const std::string identifier, size_t runtimeIdx, const std::string logStrategy); virtual Status PreCheck(Function function); // 可选检查默认返回 SUCCESS virtual Status PostCheck(Function function); // 可选检查默认返回 SUCCESS virtual Status DefaultEnabledPreCheck(Function function); // 默认启用检查 virtual Status DefaultEnabledPostCheck(Function function); // 默认启用检查 virtual void Reset() {}; protected: virtual Status RunOnFunction(Function function) 0; // 纯虚函数必须实现Run的完整执行序列在 pass.cpp 中实现顺序为记录identifier_、strategy_、logStrategy_、passRuntimeIndex_若passDfxconfigs_.disablePass为真直接跳过并返回 SUCCESS执行PreRun打印/导出 Pass 运行前的图PrintFunction、handlePreRunDumpGraph然后依次调用DefaultEnabledPreCheck与PreCheck后者受passDfxconfigs_.preCheck开关控制执行纯虚函数RunOnFunction这是每个 Pass 的核心业务逻辑所在执行PostRun打印/导出 Pass 运行后的图依次调用DefaultEnabledPostCheck与PostCheck受postCheck开关控制。因此模板中PreCheck → RunOnFunction → PostCheck的三阶段划分不是写作上的任意编排而是对Pass::Run实际调用顺序的忠实映射。模板在 PreCheck/PostCheck 小节中要求描述检查失败的处理方式在源码中的对应行为是返回FAILED状态并记录APASS_LOG_ERROR_F日志最终导致RunPass中断编译流程见 pass_manager.cpp。2.3 Pass 的注册与调度模板第 6 章要求列出相关文件其中通常包含 Pass 注册与策略编排文件。PyPTO 采用注册表 策略的调度模型注册REG_PASS(RemoveRedundantReshape)等宏调用pass_manager.cpp通过 pass_registry.h 中的PassRegistrar将派生类以名称 → 工厂函数的形式登记到PassRegistry并做编译期类型检查is_base_of_vPass, DerivedPass与名称一致性断言策略编排RegDefaultStrategy()注册了PVC2_OOO含 45 个 Pass覆盖 Tensor/Tile/Block 三阶段、FunctionUnroll仅LoopUnroll、ExecuteGraphDynAttrToStatic、LoopaxesProc三个策略运行PassManager::RunPass按策略顺序遍历 PassEntry逐一CreatePass、设置调试配置、调用pass-Run并通过MonitorPassCompileScope记录每个 Pass 的编译耗时。GetStrategyPassespass_manager.cpp还体现了 Pass 的NPUArch 架构过滤机制每个 Pass 可以通过SetSupportedArches声明其支持的芯片架构运行时会根据当前平台自动跳过不支持的 Pass。分析文档在适用场景章节应结合此类信息说明 Pass 的生效前提。3. 模板逐章详解每个章节写什么、怎么写、源码依据在哪3.1 第一章Pass 概述概述章节是全文的摘要卡片只需填写三个字段Pass 名称使用kPassNameStringMap中的字符串名如RemoveRedundantReshape保证与注册名、日志名一致Pass 类型从 Tensor Graph Pass / Tile Graph Pass / Block Graph Pass 中选取依据是PassType枚举及其在pass_manager.cpp中的 include 分组简要描述用 12 句话概括业务功能。可参考类注释与构造函数的命名如RemoveRedundantReshape类在 remove_redundant_reshape.h 中继承Pass并以RemoveRedundantReshape作为注册名。3.2 第二章代码分析3.2.1 主要功能本节需要回答三个问题Pass 解决什么问题、主要处理目标是什么、输入输出有何特点。分析切入点包括类头文件中的成员函数声明如RemoveRedundantReshape声明了RemoveReshape私有方法初步勾勒职责边界RunOnFunction的函数体这是每个 Pass 的大脑单元测试与集成测试中对图结构变化的断言可以反推 Pass 的输入/输出不变量。3.2.2 处理流程三阶段PreCheck 阶段区分两类检查——DefaultEnabledPreCheck默认强制执行用于校验 Pass 运行的前提条件是否满足与PreCheck由配置项preCheck控制的可选检查。分析时应说明PreChecker 的作用、检查的具体内容如断言图中不存在某类非法结构、失败后的处理方式返回FAILED终止编译并打印错误日志。RunOnFunction 阶段这是分析的重头戏。应描述入口函数的主要流程、遍历 Operation 的方式是遍历 Function 内所有 Operation 还是按特定容器/图结构遍历、核心处理步骤如识别可删除的 Reshape 节点 → 判断是否满足删除条件 → 重连边并删除节点。PostCheck 阶段说明DefaultEnabledPostCheck与PostCheck验证的具体内容通常是Pass 运行后图结构仍然合法所有 Tensor 的 use-def 链完整无悬空引用等不变量校验。3.2.3 关键函数的核心逻辑对每个关键函数按统一格式输出功能 / 输入 / 输出 / 算法复杂度 / 核心逻辑。模板特别强调算法复杂度要与 Function 中的 Operation、Tensor 或 Incast/Outcast 数量挂钩——这是 PyPTO 分析文档的特色要求因为 Pass 通常需要对图中的每个节点做遍历复杂度自然以O(N)N 为 Operation 数、O(N·M)对每对 Operation 组合做分析等形式表达。建议按如下结构组织函数 1[函数名称]通常是RunOnFunction功能Pass 的入口与总调度输入Function引用内含 Operation 与 Tensor 图输出StatusSUCCESS/FAILED并产生图的副作用修改算法复杂度与图中 Operation/Tensor 数量相关核心逻辑分步骤描述遍历与变换过程。函数 2[关键业务函数]如RemoveReshape描述被RunOnFunction调用的具体变换逻辑。3.2.4 核心流程图模板提供两种呈现方式Mermaid 流程图或分步文字描述。推荐优先使用 Mermaid模板已给出graph TD示例骨架将 PreCheck → 条件判断 → RunOnFunction 各步骤 → PostCheck 的流转画出来。流程图应体现判断条件分支如Reshape 是否冗余与代码中的实际if分支一一对应保证流程图可追溯、可校对。3.3 第三章业务分析本章将代码分析结论翻译成业务语言包含三小节适用场景什么样的图结构会触发此 Pass、什么样的模式会被优化、什么情况下需要运行。可结合 Pass 在策略中的位置说明如RemoveRedundantReshape在PVC2_OOO中紧跟InferTensorFormat可推断其处理前提是格式推导完成后的图优化效果从性能提升、内存节省、代码简化等维度归纳收益。注意只能陈述源码可证实的效果如删除冗余节点减少后续 Pass 与代码生成的工作量禁止编造性能数据典型应用场景模板明确要求必须包含具体示例通过输入图结构 → 输出图结构 → 优化效果三段式描述用 Operation 与 Tensor 组合成的逻辑视图展示 Pass 前后的差异。例如 RemoveRedundantReshape 的典型场景Reshape(A) → Op → Reshape链中若中间形状未发生实际数据重排则可删除冗余的 Reshape 节点直接连通。示例应当以图中真实存在的 OPCode如OP_VIEW、OP_ASSEMBLE、OP_RESHAPE为基础绘制。3.4 第四章OPCode 特判分析模板最具特色的章节模板与技能说明SKILL.md共同定义了 OPCode 特判分析的完整方法论三类必须重点记录的视图类 OPCodeOPCode含义需要特判的原因推断OP_VIEW视图操作创建张量视图视图不产生实际数据拷贝很多 Pass 需跳过或特殊处理以避免破坏视图语义OP_ASSEMBLE组装操作组装张量涉及多个输入张量的拼接需保证组装语义不被变换破坏OP_RESHAPE重塑操作改变张量形状形状变换节点是 Pass 图变换的常见锚点需判断是否冗余、是否可融合搜索特判代码的四种模式来自技能说明直接特判if (op-GetOpcode() Opcode::OP_XXX)集合特判if (xxxOps.count(op-GetOpcode()) 0)否定特判if (op-GetOpcode() ! Opcode::OP_XXX)多重特判if (op-GetOpcode() Opcode::OP_XXX || op-GetOpcode() Opcode::OP_YYY)记录格式每个特判条目必须包含五个要素——特判的 OPCode、特判条件、特判位置给出函数名即可不需行号、处理逻辑、业务含义。特判分类将收集到的特判按处理方式归类为跳过处理、特殊处理、禁止操作、兼容处理四类并在总结章节的注意事项中呈现。3.5 第五七章总结、相关文件与附录总结提炼核心价值、主要特点、使用建议与适用范围同时汇总第四章梳理的注意事项尤其是视图类 OPCode 的特殊处理逻辑相关文件区分主要实现文件如framework/src/passes/tensor_graph_pass/remove_redundant_reshape.h/.cpp与辅助文件如 Pass 基类、注册器、策略管理器、对应测试文件附录包括术语表解释 Tensor Graph、Tile Graph、Incast/Outcast、OPCode 等术语、参考资料与修改历史格式为年/月/日修改内容。4. 输出文件的命名与格式规范技能定义了严格的输出文件命名规则SKILL.md分析文档产出时必须遵守位于PVC2_OOO策略中的 Pass查询 pass_manager.cpp 中BuildPvc2OooPassEntries的 Pass 顺序文件命名为{序号}_{PASS名称}.md序号为两位数字从00开始。例如按该策略顺序InferTensorFormat对应00_InferTensorFormat.md、RemoveRedundantReshape对应01_RemoveRedundantReshape.md不在PVC2_OOO策略中的 Pass统一以99_开头如99_DynAttrToStatic.md。格式层面的两条硬性要求不要输出大段代码需要的地方只输出函数名输出完成后要重新检查一次文档格式是否统一。5. 结合源码的实战示例以 RemoveRedundantReshape 为例为了直观演示模板填写方法下面以真实源码RemoveRedundantReshape为样本给出各章节的填写要点Pass 概述名称RemoveRedundantReshape类型 Tensor Graph Pass功能为删除图中冗余的 Reshape 节点。其头文件 remove_redundant_reshape.h 表明该类重写了DefaultEnabledPreCheck、PreCheck、PostCheck、RunOnFunction四个虚函数并额外定义了RemoveReshape业务函数——这就是代码分析章节的函数清单来源处理流程PreCheck校验图中 Reshape 节点及形状信息的合法性RunOnFunction遍历所有OP_RESHAPE节点并调用RemoveReshape判断冗余性PostCheck校验删除后图的连通性与语义完整性OPCode 特判该 Pass 的核心特判对象正是视图类 OPCode 中的OP_RESHAPE——对GetOpcode() Opcode::OP_RESHAPE的节点做冗余判定如连续两次 Reshape 可合并、形状未改变的 Reshape 可删除同时需检查其相邻的OP_VIEW/OP_ASSEMBLE节点以保证视图语义不被破坏相关文件主要实现文件为framework/src/passes/tensor_graph_pass/remove_redundant_reshape.h与.cpp辅助文件包括 Pass 基类framework/src/passes/pass_interface/pass.h、注册表framework/src/passes/pass_mgr/pass_registry.h、策略管理器framework/src/passes/pass_mgr/pass_manager.cpp以及framework/tests下的对应单元测试。6. 总结与实践建议Pass_Analysis_Template.md的价值在于把读懂一个 Pass这件看似模糊的工作拆解为七个可执行、可检查、可复用的步骤。使用时的关键实践建议先定位再分析通过kPassNameStringMap、RegDefaultStrategy与REG_PASS宏三处信息交叉确认 Pass 的类型、策略位置与注册名称避免张冠李戴流程对应源码PreCheck/RunOnFunction/PostCheck 三阶段必须与 pass.cpp 中PreRun/PostRun的实际调用顺序对应注意区分默认检查与可选检查特判穷尽搜索在 Pass 源码中系统性搜索GetOpcode()/GetOpCode()判断与Opcode::OP_常量重点记录OP_VIEW、OP_ASSEMBLE、OP_RESHAPE三类视图类 OPCode 的特判条件、位置与处理逻辑并归入跳过/特殊/禁止/兼容四类示例必须落地典型应用场景必须给出具体的输入/输出图结构与优化前后对比杜绝空泛描述遵守命名与格式按PVC2_OOO序号或99_前缀命名输出文件正文只给函数名不给大段代码输出后统一复核格式。按此方法产出的 Pass 分析文档既是团队评审的交流载体也是后续开发者快速上手某个 Pass 模块的第一手资料更可为 OPCode 特判等易错点提供长期的代码级备忘。相关文件索引模板本体Pass_Analysis_Template.md技能说明SKILL.mdPass 基类pass.h、pass.cppPass 类型与名称映射pass_type.hPass 注册与策略pass_registry.h、pass_manager.cpp示例 Pass 实现remove_redundant_reshape.h、framework/src/passes/tensor_graph_pass/remove_redundant_reshape.cppPass 源码目录framework/src/passes/含tensor_graph_pass/、tile_graph_pass/、block_graph_pass/、pass_check/、pass_mgr/等子目录【免费下载链接】pyptoPyPTO发音: pai p-t-oParallel Tensor/Tile Operation编程范式。项目地址: https://gitcode.com/cann/pypto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考