Page 106 - 《软件学报》2025年第7期
P. 106

沈庆超 等: 深度学习编译器缺陷实证研究: 现状与演化分析                                                   3027


                 并在表   1  的最后一行中列出了从中识别出的缺陷数量. 经过严格的筛选和分析, 我们从                       914  个缺陷相关的    PR  中
                 识别出   613  个缺陷, 包括  437  个  TVM 缺陷、84  个  Glow 缺陷和  92  个  AKG 缺陷.

                                                     表 1 缺陷数据统计

                                              编译器        PR数量        缺陷数量
                                               TVM         663         437
                                               Glow        127         84
                                               AKG         124         92
                                               总和          914         613

                 3.3   分类与标注过程
                    为了获取缺陷的根因、症状和缺陷在              DL  编译器  3  个阶段中的位置, 本文遵循已有研究工作的方式             [8,20,32] , 采
                 用人工标注的方式对每个缺陷进行标注. 具体来说, 为了标注缺陷的根因与症状, 本工作使用已有工作                              [34−36] 中的根
                 因和症状分类法作为初始分类法, 然后按照标注数据的实际特性对其进行调整, 使其适应新增                              DL  编译器缺陷的
                 特征  [21] . 为了标注缺陷出现的位置, 我们使用第        2  节中定义的  3  个不同编译阶段作为      DL  编译器位置类别. 对于每
                 个  DL  编译器中的源码文件, 我们通过阅读文档、源码及注释, 理解每个源码文件的功能, 并将其归纳到                            DL  编译
                 器的不同编译阶段. 以上所有过程均为两位作者共同完成.
                    基于上述方式获取的缺陷根因、症状与位置类别, 以及每个源码文件对应的编译阶段, 两位作者根据已有研
                 究的开放编码方案      [20] , 分别独立地对于每个缺陷进行人工分析和标记. 具体而言, 针对每个缺陷, 两位作者首先深
                 入理解缺陷修复的代码变更、与缺陷关联的问题                  (issue) 的描述内容和开发者在      PR  或  issue 中的讨论. 在标记过
                 程中, 为了评估两位作者之间标注结果的一致性, 本文采用                 Cohen’s Kappa 系数  [37] 作为衡量标准. 在初步标记的前
                 5%  数据中, Cohen’s Kappa 系数仅为  40%, 这显示了初始标注过程中存在一定比例的不一致性. 因此, 我们组织了
                 一次针对性的标记培训. 随后, 在包含前           5%  数据的前   10%  标记结果中, Cohen’s Kappa 系数显著提升至      86%, 标
                 注的一致性得到了显著提高. 通过进一步的讨论和修正不一致之处, 在后续的标记工作中, Cohen’s Kappa 系数均
                 保持在   94%  以上. 对于每次标记过程中出现的不一致点, 两位作者都会与第                  3  位作者进行深入讨论, 以确保所有
                 缺陷都能得到一致且准确的标记结果.
                    此外, 我们采用半自动化的统计策略, 理化分析触发缺陷的回归测试用例修改程度和修复缺陷的补丁的大小.
                 具体而言, 在分析回归测试用例与已有测试用例的差异程度时, 我们首先通过人工检查判定回归测试用例属于完
                 全新增的类别还是基于已有测试用例修改得到的. 对于基于已有测试用例进行修改得到的回归测试用例, 我们进
                 一步统计其代码变更的行数. 代码变更的行数新增的代码行数与删除的代码行数总和. 需要注意的是, 一行代码的
                 修正涉及两行代码的变更, 包括删除原先错误的代码和新增一行正确的代码. 鉴于缺陷修复补丁的大小受到代码
                 注释、不同函数大小等多种因素的显著影响, 我们决定采用受影响的函数个数作为度量标准. 具体而言, 我们通过
                 分析每个缺陷修复过程中涉及的文件更改行号, 并与相应版本的文件进行比对, 从而精确计算出每个缺陷修复所
                 影响的函数数量. 这种方法能够更为准确地反映缺陷修复补丁的实际规模和影响范围.

                 4   结果与分析

                 4.1   RQ1: 根因

                 4.1.1    根因分类结果
                    基于上述分类和标注, 我们确定了以下             13  个引起  DL  编译器缺陷的根因.
                    ● 逻辑错误. 此类缺陷一般涉及多个语句或代码块中的逻辑. 代码逻辑指的是算法的实现逻辑, 例如在计算图
                 上的优化. 根据缺陷发生的位置, 将这类缺陷分为两个子类. (1) 错误的优化代码逻辑: 如第                         2  节中所述, 优化是
                 DL  编译器的核心功能. DL     编译器通常包含计算图级别的           High-level 优化和硬件级别的    Low-level 优化等多级优
                 化策略. 这一子类缺陷发生在各种优化实现的位置. (2) 错误的非优化代码逻辑: 此类缺陷包括除了优化代码以外
   101   102   103   104   105   106   107   108   109   110   111