Page 105 - 《软件学报》2025年第7期

3026 软件学报 2025 年第 36 卷第 7 期

在联系, RQ5 到 RQ6 从触发缺陷的测试用例和修复缺陷的补丁角度分析 DL 编译器的缺陷特征.
RQ1: DL 编译器缺陷的根因类型分布及其随时间的变化趋势如何?
深入研究 DL 编译器缺陷的根因类型, 能够揭示缺陷产生的本质原因, 这是提升编译器质量、减少未来缺陷
的关键. 随着技术的不断进步和 DL 编译器的快速迭代, 新特性的引入与旧功能的弃用可能导致缺陷根因的多样
性和动态变化. 因此, 分析根因的分布及其变化趋势, 对于制定有效的缺陷检测、定位和修复策略至关重要.
RQ2: DL 编译器缺陷的症状分布及其随时间的变化趋势如何?
缺陷的症状直接关联到其对 DL 编译器功能和性能的实际影响. 同时, 了解不同症状的分布及其变化趋势, 有
助于指导测试人员设计针对特定症状类型的 DL 编译器测试方法. 确保关键缺陷被及时发现并修复.
RQ3: DL 编译器缺陷的位置分布及其随时间的变化趋势如何?
DL 编译器包含 3 个主要阶段, 不同阶段存在缺陷的数量存在差异. 明确缺陷的位置分布, 可以帮助开发者识
别代码中的“脆弱点”, 从而让缺陷检测和调试工作更有针对性. 同时, 随着 DL 编译器的不断迭代发展, DL 编译器
不同阶段缺陷分布会发生变化, 研究缺陷位置的变化规律对于适应 DL 编译器不断演化的需求, 优化测试、调试
和定位策略具有重要意义.
RQ4: 缺陷根因、症状、位置三者之间的内在关联如何?
缺陷的根因、症状和位置是理解缺陷全貌的 3 个重要维度. 探索它们之间的内在联系, 可以构建更全面的缺
陷知识图谱, 揭示缺陷产生的深层次原因和规律. 这种综合视角有助于开发更精确的缺陷检测方法、设计更有效
的缺陷修复方法, 并提升 DL 编译器的整体质量和稳定性.
RQ5: 回归测试用例与历史测试用例的差异程度如何?
修复缺陷的过程中, 开发者通常还会增加或修改源码中配套的单元测试用例, 使其能够触发该缺陷. 了解回归
测试用例与历史测试用例的差异程度能够在一定程度上反映已有测试用例与触发新缺陷的差异程度, 并能够为未
来 DL 编译器缺陷检测方法的设计提供指导方向.
RQ6: 修复 DL 编译器缺陷的复杂程度如何?
缺陷修复的复杂程度是衡量缺陷影响范围和修复难度的重要指标. 通过分析真实缺陷的修复补丁大小、修复
过程中涉及的代码量等因素, 可以评估缺陷修复的整体复杂性和所需资源. 这对于制定合理的修复计划、评估自
动化修复技术的可行性和效果具有重要意义. 同时, 该问题的研究还有助于指导未来 DL 编译器设计和开发过程
中如何降低缺陷的复杂性和修复成本.

3.2 数据收集
为了回答以上 6 个研究问题, 本文研究选取了当前 3 款主流的 DL 编译器作为研究对象, 包括 Apache 的
[9]
TVM , Facebook 的 Glow [10] 以及华为的 AKG [14] . 为了分析 DL 编译器缺陷的特点, 我们参考已有工作从 DL 编译
器的 GitHub 仓库中搜集已被合并到项目源码中的拉取请求 (pull request, PR) [19,33] . 为了确保数据的准确性和相关
性, 我们从 PR 中筛选出标题或标签中至少包含一个与缺陷修复相关的关键词 (包括 fix、defect、error、bug、
issue、mistake、incorrect、fault 和 flaw) 的 PR. 本文选择已合并的 PR 作为研究数据来源主要是基于以下两个考
虑: 首先, 已合并的 PR 表明缺陷已经得到了开发者的认可并完成了修复, 因此它们能够真实反映 DL 编译器在实
际使用中遇到的问题; 其次, 这些 PR 通常包含缺陷的描述, 开发者的讨论和缺陷的详细修复过程, 这些信息是深
入分析缺陷的根因, 症状与位置重要的信息源. 然而根据关键词筛选出的 PR 存在非缺陷修复的任务 (如功能增强
或代码重构). 此外, 存在多个缺陷在一个 PR 中被同时修复的情况. 因此, 在后续的数据处理过程中, 我们进一步对
收集到的 PR 进行了详细的筛选, 过滤掉所有非缺陷修复功能的 PR, 并将包含多个缺陷的 PR 拆分开, 以确保我们
分析的数据集专注于缺陷修复且每条数据只包含一个缺陷.
遵循已有研究工作 [8,19,32] 的缺陷分析方式, 本文采用人工标注的方式对缺陷的症状、根因等因素进行标注. 由
于 DL 编译器新增的缺陷数量规模较大, 人工分析的方式无法支持对所有新增缺陷的标注, 为此, 我们从所有收集
到的 PR 中随机筛选了一部分 PR 进行了深入的分析和分类, 表 1 的第 2 行即为手动分析的缺陷相关的 PR 数量,