编译器优化故障的测试与定位

最新推荐文章于 2024-05-11 14:04:46 发布

仓颉编程语言

最新推荐文章于 2024-05-11 14:04:46 发布

阅读量1k

点赞数 1

分类专栏：技术文章文章标签：编程语言内存优化编译器

本文链接：https://blog.csdn.net/pl_lab_001/article/details/121426169

版权

作者 | 江贺

整理 | Hana

作者简介：

江贺，大连理工大学软件学院教授，博士生导师，研究领域：智能软件工程（软件大数据处理、编译系统测试、工业软件测试）

个人主页：大连理工大学主页平台管理系统江贺--jianghe--首页

本次技术分享来自 SIG-编程语言测试技术沙龙，本文内容为提取讲演视频后的文章，视频也已经发布在 B 站，欢迎大家点开学习。

SIG-编程语言测试技术沙龙回顾｜编译器优化故障的测试与定位_哔哩哔哩_bilibiliSIG-编程语言测试技术沙龙回顾｜编译器优化故障的测试与定位https://www.bilibili.com/video/BV1io4y1X7t3

# Introduction #

今天想分享的主题是 编译器故障的检测和定位。

当前编译器的发展现状如下图示，大家可以看出编译器的发展趋势正在由通用型转向领域特定型。

但是我们分析发现，这些编译器实际上依旧占据着主流的应用市场：

国内也涌现出很多的编译器：

神威睿智编译器 基于申威指令系统开发 [1] 了基于 GCC 和 Open64 的产品编译器，以及针对国产主机的二进制翻译系统（PowerPC/X86）；

龙芯中科 也有基于自有架构后端定制了优化的编译器，包括基于 GCC 和 Open64 的产品编译器，以及 DigitalBridge 进程级二进制翻译系统（X86）；

寒武纪 [2] 针对 AI 构建了自己的编译工具链，包括 CNCC（寒武纪 BANG C 语言编译器，基于 Clang 和 LLVM 开发）和 CNAS（寒武纪 MLISA 语言编译器）；

华为也推出了自研的方舟编译器 [3]。

编译器的质量会大大影响其使用和流行程度，因此在做编译器的过程中，编译器的质量是一个非常重要的要求。

确保编译器的质量有两种方式：第一种方式就是做 可信验证，这种方式的好处在于它理论上是可以完全保证编译器质量的（如 CompCert [4]），但是无法规模化应用；更常用的办法是 对编译器做测试，虽然无法保证完备性，但它可以大规模化。

# 编译器测试

编译器测试一般会有三个阶段，

测试用例生成 如何生成测试用例来触发编译器故障
Test Oracle 问题 即测试准则问题 [5]。当输入测试用例后，编译器产生的输出与我们的预期输出是否一样
测试用例约减 当我们发现了一个编译器的故障后，通常来讲测试用例可能会很长，但是要提交给社区时，必须做一些相关的约减，将测试用例减到方便开发者阅读和定位的范围内（比如 20 行左右）。

## 编译器测试的主要方法

这里简单介绍一下三种主流编译器测试技术：

Random Differential Testing (RDT) 即随机差异测试。简单说，就是用同个编程语言的不同的编译器（比如 GCC 和 LLVM）来进行比较，若编译器的行为不一致，则表示至少其中一个编译器是存在故障的。

Different Optimization Levels (DOL) 即优化级别测试。是 RDT 的一个变种，具体方法是对比同一个编译器的不同优化等级，若行为不一致，则表示至少有一种编译器优化存在故障。

Equivalent Modulo Inputs (EMI) [6] 即等价取模测试，由 UC Davis 的苏振东教授团队提出。EMI 的方法与 RDT 等不同，是对程序进行变换，然后观察被测编译器，是否会跑出不同的结果。

# 编译器架构

编译器可以分为前端、中间层及后端。业界对编译器中间这一层的分析和测试比较多，针对前端和后端的分析测试在学术界相对不是特别多。工业界也是如此，由于后端架构的多样，中间代码到指令集的翻译需要适配不同的架构，这个过程需要很严肃的测试是否有故障；另外，像 LLVM 编译器的中间优化大概有 150 多个，GCC 大概有 250 个，中间优化对传统编译器来说是相当重要的一部分，同时也是出现故障可能性很大的一部分。