ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

PyPTO Pass 业务流分析报告撰写指南:从模板到源码级依赖验证

PyPTO Pass 业务流分析报告撰写指南:从模板到源码级依赖验证 PyPTO Pass 业务流分析报告撰写指南从模板到源码级依赖验证【免费下载链接】pyptoPyPTO发音: pai p-t-oParallel Tensor/Tile Operation编程范式。项目地址: https://gitcode.com/cann/pypto导读PyPTOParallel Tensor/Tile Operation 编程范式的编译流程本质上是数十个 Pass 按照既定策略依次作用于 IR中间表示的过程。当需要理解某个业务场景如冗余算子消除、切图合图、动态 shape 处理等中哪些 Pass 参与、按什么顺序执行、彼此如何依赖、数据与状态如何流转时仅靠阅读零散代码很难形成全局视图。本文以仓库内 pass-workflow-report-template.md 为骨架结合 SKILL.md 定义的分析流程与framework/src/passes/下的真实源码完整讲解如何撰写一份业务概述—Pass 清单—执行流程—依赖关系—数据流转—状态变化—价值与场景的 Pass 业务流分析报告。读完本文你将掌握一套可直接复用的业务流分析方法论并能对照源码验证报告中每一个依赖结论。1. 为什么需要 Pass 业务流分析PyPTO 把设备侧程序的优化与代码生成拆解为一系列职责单一、可独立开关的 Pass。从源码结构看这些 Pass 按图类型划分为四个阶段定义见 pass_type.hTensor Graph PassTYPE_TENSOR_GRAPH作用在张量图上负责格式推导、自动类型转换、冗余 reshape 消除等Tile Graph PassTYPE_TILE_GRAPH作用在 tile 图上负责图切分、buffer 合并、子图生成等Block Graph PassTYPE_BLOCK_GRAPH作用在块图上负责同步插入、内存复用、代码生成预处理等Execute Graph Pass面向最终执行图负责动态属性静态化、循环轴处理等。单个 Pass 内部逻辑容易读懂但一个真实业务例如一次完整的图编译往往串联几十个 Pass理解整体执行顺序、模块间数据依赖与状态传递才是难点。业务流分析报告正是把这种纵向编译流水转化为横向业务视图的标准载体它回答三个问题——该业务涉及哪些 Pass它们按什么顺序执行它们之间流转了什么数据与状态2. 分析流程总览三步产出报告根据 SKILL.md 的定义业务流分析遵循定位文档 → 解析设计 → 源码验证 → 生成报告的流程可归纳为三步定位业务流程文档在用户指定目录及 docs 文档目录中查找与业务场景如冗余 op 消除、切图合图、动态参数处理相关的设计文档解析业务流程设计提取业务名称/目标/触发条件/适用范围列出参与 Pass根据 pass_manager.cpp 中的默认执行策略确定执行顺序根据 Pass 源码所在目录判定其所处阶段结合源代码验证在 framework/src/passes 中查找相关 Pass 源码验证文档描述与代码实现的一致性并补充文档未详述的实现细节。最后按照报告模板组织成文。模板中涉及的分析要点业务概述、Pass 清单、执行流程、依赖关系、数据流转、状态变化、业务价值、典型场景、注意事项、相关文件与下方各章节一一对应。3. 报告骨架一业务概述与 Pass 清单报告开头用一张信息卡交代业务背景字段包括业务名称、业务目标、触发条件与适用范围。例如分析默认策略编译这一业务时业务目标将输入 Function 的 IR 依次经过格式推导、图切分、同步插入等 Pass输出可直接进入代码生成的图触发条件调用PassManager::RunPass且策略名为PVC2_OOO适用范围AICore 侧默认图编译路径。随后用表格列出全部参与 Pass模板第 2 章表格字段为序号、Pass 名称、阶段、主要功能。阶段划分可依据 pass_type.h 的PassType枚举也可依据 pass_manager.cpp 中头文件按阶段分组的注释// tensor graph pass、// tile graph pass、// execute graph pass。Pass 的规范名称如InferTensorFormat、GraphPartition、InsertSync来自 pass_type.h 中的kPassNameStringMap分析时应统一使用该映射中的字符串保证报告与日志、配置中的名称一致。4. 报告骨架二执行流程与整体流程图4.1 以默认策略为锚点确定执行顺序报告中的执行顺序不能凭空推断而应以 pass_manager.cpp 中注册的默认策略为权威依据void PassManager::RegDefaultStrategy() { RegisterStrategy(PVC2_OOO, BuildPvc2OooPassEntries()); RegisterStrategy(FunctionUnroll, BuildPassEntries({PassName::LOOP_UNROLL})); RegisterStrategy(ExecuteGraph, BuildPassEntries({PassName::DYN_ATTR_TO_STATIC, PassName::LOOPAXES_PROC})); }其中PVC2_OOO是主策略在 pass_manager.cpp 的BuildPvc2OooPassEntries()中按序定义了 48 个 Pass从INFER_TENSOR_FORMAT格式推导开始经REMOVE_REDUNDANT_RESHAPE、AUTO_CAST、EXPAND_FUNCTIONTensor Graph 阶段到GRAPH_PARTITION、N_BUFFER_MERGE、L1_COPY_IN_REUSE_MERGETile Graph 阶段再到OOO_SCHEDULE、INSERT_SYNC、GLOBAL_MEMORY_REUSE、CODEGEN_PREPROCBlock/Execute 阶段结束。分析具体业务时可先确认该业务走的是主策略还是仅其中若干 Pass再据此裁剪流程。4.2 用 mermaid 绘制整体流程图模板第 3.1 章提供了可直接复用的 mermaidgraph TD骨架将各 Pass 按执行顺序串联并用subgraph将同阶段 Pass 分组。下面给出一个以PVC2_OOO策略前中后段为代表的示意完整报告应列出该业务实际涉及的全部 Pass值得注意的两点源码事实顺序不是一成不变的pass_manager.cpp 的GetStrategyPasses会根据当前 NPU 架构Platform::Instance().GetSoc().GetNPUArch()过滤掉不支持当前架构的 Pass因此报告应注明默认策略下、当前架构为 XXX 时这一前提阶段可提前终止ShouldTerminateAtStagepass_manager.cpp允许在ExpandFunctionTensor Graph 阶段末或SubgraphToFunctionTile Graph 阶段末处按编译阶段选项提前结束流水报告中的流程图应区分完整流水与阶段截断流水两种形态。5. 报告骨架三依赖关系分析5.1 三类依赖的表达模板第 4 章要求分别列出前置依赖、数据流与状态依赖典型表达方式前置依赖[Pass2] 依赖 [Pass1] 的输出数据流[数据A]Pass1 → Pass2状态依赖[Pass1] 设置的状态被 [Pass4] 使用。5.2 源码中的依赖校验机制依赖关系并非只在报告里存在框架在注册策略时就会校验。核心实现在 pass_dependency.cpp机制分两类前置依赖Pre-Dependency某 Pass 必须在若干 Pass 之后执行注册于RegisterPreDependencies()pass_dependency.cppregisterDependency(PassName::EXPAND_FUNCTION, {PassName::AUTO_CAST, PassName::INFER_MEMORY_CONFLICT}); registerDependency(PassName::GRAPH_PARTITION, {PassName::DUPLICATE_OP, PassName::SPLIT_LARGE_FANOUT_TENSOR, PassName::SPLIT_RESHAPE, PassName::PROCESS_ATOMIC, PassName::BUILD_TREE_FROM_REDUCE}); registerDependency(PassName::SUBGRAPH_TO_FUNCTION, {PassName::GRAPH_PARTITION, PassName::REPLACE_TENSOR, PassName::PRE_GRAPH_PROCESS, PassName::INFER_DYN_SHAPE}); registerDependency(PassName::INSERT_SYNC, {PassName::OOO_SCHEDULE, PassName::COPY_OUT_RESOLVE});例如SUBGRAPH_TO_FUNCTION依赖GRAPH_PARTITION、REPLACE_TENSOR、PRE_GRAPH_PROCESS、INFER_DYN_SHAPE四个前置 Pass——这恰好印证了切图合图业务中子图生成必须发生在图切分、动态 shape 推断之后。顺序依赖Sequence-Dependency某 Pass 之后必须紧跟一段有序 Pass 序列注册于RegisterSequenceDependencies()pass_dependency.cppregisterDependency(PassName::GRAPH_PARTITION, {PassName::GRAPH_PARTITION, PassName::REDUCE_COPY_MERGE, PassName::N_BUFFER_MERGE, PassName::L1_COPY_IN_REUSE_MERGE, PassName::INTRA_SUBGRAPH_ADAPTER, PassName::GENERATE_MOVE_OP});这表示GRAPH_PARTITION之后应顺序跟随后续的 copy 合并、buffer 合并等切图配套 Pass。校验入口是 pass_dependency.h 中声明的CheckStrategyDependency它在 pass_manager.cpp 的RegisterStrategy中被调用若策略中缺少必要前置 Pass 或顺序错乱会输出形如In strategy %s, %s is missing dependencies...的警告日志pass_dependency.cpp。撰写报告时可把源码中已注册的依赖对直接作为依赖关系章节的事实依据并标注其源码位置。6. 报告骨架四数据流转与状态变化6.1 数据流转表模板第 5.1 章用数据项—来源 Pass—变化描述—目标 Pass四列刻画数据流转。分析方法是对每个 Pass考察其RunOnFunction定义于 pass.h对Function中的 IR 做了何种变换以及产出的数据如新 op、新子图、buffer 分配信息被后续哪个 Pass 消费。以PVC2_OOO策略为例可抽象出如下典型数据流数据项来源 Pass变化描述目标 PassTensor 格式信息InferTensorFormat推导并标注每个 tensor 的 formatRemoveRedundantReshape / AutoCast冗余 reshapeRemoveRedundantReshape消除可合并/可省略的 reshape 节点AutoCast子图划分结果GraphPartition将 tile 图划分为子图ReduceCopyMerge / NBufferMerge子图 FunctionSubgraphToFunction将子图封装为独立 FunctionVFFusionClusterIdentify / InferParamIndex同步点InsertSync在块图中插入同步指令CodegenPreproc6.2 状态变化与状态机图模板第 6 章要求用stateDiagram-v2表达 IR 在流水中的状态演化并配状态名称—初始值—设置 Pass—变化条件—使用 Pass表格。模板提供的状态机骨架Initial → Processing → Validated → Optimized是通用占位实际报告中应替换为与业务真实对应的状态。一个可参考的改写示例状态表的填写要点是初始值写 Pass 执行前 IR 的形态变化条件写触发状态跃迁的 Pass 名称即设置 Pass使用 Pass写读取该状态的下游 Pass从而与第 5 章的依赖关系形成闭环。7. 报告骨架五各 Pass 详细说明模板第 7 章要求对每个 Pass 给出功能、输入、输出、关键逻辑、与其他 Pass 的关系五个要素。撰写时建议从以下源码点提取素材输入/输出查看 pass.h 中Run与PreCheck/PostCheck的签名Pass 的输入输出本质上是Function承载 IR不同 Pass 的差异在于读写 IR 的哪些属性关键逻辑定位各 Pass 在 framework/src/passes/tensor_graph_pass、framework/src/passes/tile_graph_pass、framework/src/passes/block_graph_pass 下的实现文件描述其核心变换如GraphPartition的切分策略、InsertSync的同步点选取与其他 Pass 的关系直接引用 pass_dependency.cpp 中已注册的依赖条目避免臆造依赖架构适配说明该 Pass 是否通过GetSupportedArches()pass.h限制了可运行的 NPU 架构这决定了它在某架构下是否会被跳过。例如SubgraphToFunction的条目可写为功能——将切图后的子图封装为独立 Function输入——经过GraphPartition、ReplaceTensor、PreGraphProcess、InferDynShape处理后的 tile 图输出——封装完成的子图 Function关键逻辑——完成子图到 Function 的边界收敛与其他 Pass 的关系——前置依赖四个 Pass见 pass_dependency.cpp其执行位置同时是ShouldTerminateAtStage定义的 Tile Graph 阶段终止点pass_manager.cpp。8. 报告骨架六业务价值、典型场景与注意事项业务价值模板第 8 章从性能提升如CommonOperationEliminate消除公共子表达式、NBufferMerge减少 buffer 拷贝、资源优化如GLOBAL_MEMORY_REUSE复用全局内存、功能增强如INFER_DYN_SHAPE支持动态 shape 业务三个维度总结。注意价值表述应以源码实现的功能为准禁止虚构性能数据。典型应用场景模板第 9 章结合 SKILL 中列举的业务场景类型给出 23 个实例如冗余 op 消除业务RemoveRedundantReshape→RemoveRedundantOp→CommonOperationEliminate的消冗链路切图合图业务GraphPartition及其顺序依赖链动态参数处理业务PreGraphProcess→InferDynShape→SubgraphToFunction。注意事项模板第 10 章至少覆盖以下四点——① 执行顺序以 pass_manager.cpp 的策略注册为准且会被架构过滤pass_manager.cpp和阶段截断ShouldTerminateAtStage影响② 依赖结论应引用 pass_dependency.cpp 的注册数据文档与代码不一致时以代码为准并在报告中标注③ Pass 可被ResetAllPasses()pass_manager.cpp重置跨策略复用的 Pass 状态不可假设持续保留④ 报告中的 Pass 名称统一使用 pass_type.h 的PassNameStr映射与日志和配置保持一致。9. 相关文件索引撰写报告时可快速查阅以下文件报告模板.agents/skills/pypto-pass-workflow-analyzer/references/pass-workflow-report-template.md分析流程说明.agents/skills/pypto-pass-workflow-analyzer/SKILL.mdPass 类型与名称定义framework/src/passes/pass_interface/pass_type.hPass 基类接口framework/src/passes/pass_interface/pass.h策略注册与执行入口framework/src/passes/pass_mgr/pass_manager.cpp、framework/src/passes/pass_mgr/pass_manager.h依赖校验实现framework/src/passes/pass_mgr/pass_dependency.cpp、framework/src/passes/pass_mgr/pass_dependency.hPass 注册机制framework/src/passes/pass_mgr/pass_registry.cpp各阶段 Pass 实现目录framework/src/passes/tensor_graph_pass、framework/src/passes/tile_graph_pass、framework/src/passes/block_graph_pass【免费下载链接】pyptoPyPTO发音: pai p-t-oParallel Tensor/Tile Operation编程范式。项目地址: https://gitcode.com/cann/pypto创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表