测试代码生成器优化

Question

我为 LLVM 代码生成器后端编写了一个低级优化。基本上，优化将在基本块级别对汇编指令重新排序，以允许以后（现有）优化更有效地优化结果代码。我想验证许多测试用例，我想对测试过程提出一些建议，因为这是我第一次尝试这样的事情。

到目前为止我考虑过的事情：

1. 编译用 C 编写的基准测试并检查使用 -S 选项生成的 ASM。我已经这样做了，并将结果与​​我的优化结果与原始结果进行了比较。这种方法可以让我看到我的优化是有效的，但是即使我编写了自定义的不可执行的 C 文件，我也无法检查所有我想要的指令排序测试用例。

2. 将基准编译为 LLVM 程序集，对其进行编辑，然后将 ASM 降低到目标计算机程序集。这可能可行，但由于 LLVM 和目标 ASM 之间的抽象级别不同，我怀疑我是否能够通过破解 LLVM ASM 来检查所有测试用例，直到它生成我想要的为止。

3. 使用目标 ASM 测试用例作为 LLVM 的输入，并使用新的优化重新编译。我找不到 LLVM 或 gcc（LLVM 接受的大多数选项）接受 ASM 作为输入的选项。

在验证低级 ASM 编译器优化时，测试特定 ASM 测试用例的好策略是什么？ LLVM（或 gcc）是否有一些命令行选项可以简化此过程？

---

编辑：澄清一下，我不是在问自动生成 ASM 测试用例；我的问题是我有那些测试用例（例如ASM_before.s 和reference_ASM_after.s），但我需要能够将ASM_before.s 传递到LLVM 并确保优化的输出ASM_after.s 与已知良好的reference_ASM_after.s 匹配。我正在寻找一种方法来做到这一点，而不必将ASM_before.s“反编译”为高级语言，然后将其（通过优化）编译为ASM_after.s。

Answer 1

基准测试是其中一种滑坡，您可以提出一个基准来使任何语言或工具看起来好或坏，具体取决于您要证明的内容。

首先，我通常在没有操作系统的 arm 平台上工作，因此执行时间非常简单，有时精确到时钟，加减一个来比较编译器或选项。

特别是当您进入带有缓存的平台时，情况会变得更糟。如果您在启动代码中添加或删除 nop，导致整个程序更改其在内存中的位置，这意味着所有内容都会更改其缓存对齐方式，而无需任何编译器优化更改，您有时会发现缓存导致的性能差异比编译器或后端的差异更大优化。

我通常会运行 dhrystone，但不会以此宣布胜利或失败。如果您使用浮点数或带有软 fpu 的磨刀石，您可能也想做磨刀石。

正如上面有人已经提到的，自检是个好主意。真实世界的代码也是如此。例如压缩例程，获取一些文本（可能是古腾堡项目的一本书的一部分），压缩它，然后解压缩并将输出与输入进行比较，您可以通过在主机等控制平台上压缩它来添加额外的验证如果被测压缩版本不匹配，则将压缩大小硬编码到测试中，但它得到正确的输出，但仍然失败。我还使用 jpeg 库将图像从 jpeg 转换为 jpeg，如果预计图像不会通过有损压缩恢复到其原始状态，那么您只需进行一次传输和校验和或验证大小或携带一份副本预期输出和比较。 aes和des加解密。

您可以将大量开源项目与修改后的编译器一起使用，以将其与库存编译器或其他编译器进行比较。作为真实世界的代码，无论如何，它都是您的编译器将使用的那种东西。请注意，当您访问 toms 硬件或其他基准测试站点时，会有许多不同的基准测试、渲染某些东西所需的时间、编译 gcc 或 linux 或执行数据库搜索所需的时间，以及一堆现实世界的应用程序。并且各种应用程序获得了不同的分数，很少有一个平台/解决方案能横扫一系列测试。

当您进行更改时性能下降时，您需要检查汇编程序并尝试找出原因。记住 Michael Abrash（和其他人）所说的，无论你认为你的汇编程序有多好，你仍然需要计时。也可以尝试一些你肯定会很慢的疯狂的事情，因为有时你会因为你从未想过的原因发现它们很快。

Answer 2

是LLVM's opt command你在寻找什么？