Bugpoint 重设计

作者：Diego Treviño (diegotf@google.com)

日期：2019-06-05

状态：草稿

简介

随着 bugpoint 的使用日益增多，多年的使用过程中也发现了一些需要改进的地方：使用起来令人困惑、速度慢、并非总是产生高质量的测试用例等等。本文档提出了一种新的方法，其重点更窄：IR 测试用例的最小化。

提议的新设计

狭窄的焦点：测试用例缩减

主要焦点将是一种代码缩减策略，以获得更小的测试用例，同时这些用例仍然具有与原始用例相同的属性。这将通过经典的 delta debugging 以及添加一些 IR 特定的缩减（例如，替换全局变量、删除未使用的指令等）来完成，类似于现有的方法，但具有更深入的最小化。

诚然，如果社区对这个提议有不同意见，旧代码仍然可以保留在工具中，但需要注意的是，文档和设计仍然要朝着 delta 缩减的方向发展。

命令行选项

我们建议将 bugpoint 大量的选项减少到只有两个：一个“有趣性”测试和该测试的参数，类似于其他 delta 缩减工具，如 CReduce、Delta 和 Lithium；该工具应该感觉不那么杂乱，并且在如何操作它方面也应该没有不确定性。

用于缩减代码的“有趣性”测试通过名称给出：--test=<test_name> 如果未给出 --test 选项，程序将退出；此选项类似于 bugpoint 当前的 -compile-custom 选项，该选项允许用户运行自定义脚本。

“有趣性”测试将被定义为一个脚本，当 IR 达到用户定义的行为（例如，在 clang 上编译失败）时返回 0，否则返回非零值。这让用户可以自由地决定对工具而言什么是“有趣”的，从而简化了缩减测试用例的过程。

如果测试接受任何参数（不包括输入 ll/bc 文件），则通过以下标志给出：--test_args=<test_arguments> 如果未指定，则按给定的方式运行测试。值得注意的是，输入文件将作为参数传递给测试，类似于 -compile-custom 当前的运行方式。

实现

该工具的行为将类似于 CReduce 的功能，因为它将有一系列尝试最小化给定测试用例的 passes。我们应该能够模块化该工具的行为，并使其更易于维护和扩展。

此重设计的第一个版本将尝试：

• 丢弃不影响“有趣性”测试的函数、指令和元数据

• 从函数中删除未使用的参数

• 消除未访问的条件路径

• 将变量重命名为更常规的名称（例如 “a”、“b”、“c” 等）

一旦这些 passes 被实现，更具意义的缩减（例如类型缩减）将被添加到工具中，以进一步缩减 IR。

历史 bugpoint 问题的背景

根本原因分析

目前，bugpoint 需要很长时间才能在给定的 IR 文件中找到问题的根源，这主要是因为它尝试通过运行各种策略来分类 bug 来调试输入，这些策略反过来又在输入上运行多个优化器和编译 passes，从而占用大量时间。此外，当 IR 崩溃时，它会尝试通过执行一些次优的 passes（例如，大量无法访问的块）来缩减它，有时甚至完全无法最小化。

“古怪”的界面

Bugpoint 当前的界面让用户感到不知所措和困惑，仅仅帮助屏幕本身最终就令人困惑，而不是提供指导。而且，不仅有大量的功能和选项，而且其中一些功能的工作方式也出乎意料，大多数时候用户最终会使用自定义脚本。为了使该工具在一般情况下更有用且更易于维护，修剪和简化界面将是值得考虑的。