测试代码生成器优化
我已经为LLVM代码生成器后端编写了一个低级优化。基本上，优化将在基本块级别对汇编指令进行重新排序，以允许稍后(现有的)优化更有效地优化结果代码。有许多测试用例我想要验证，我想为测试过程提供一些建议，因为这是我第一次尝试这样的事情。
到目前为止我考虑过的事情：
- 编译用C编写的基准测试程序，并检查使用
-S选项生成的结果。我已经做到了这一点，并将优化后的结果与原始结果进行了比较。这种方法允许我看到我的优化是有效的，但即使我写了自定义的不可执行的C文件，我也不能检查所有我想要的指令顺序测试用例。 - 将基准编译到LLVM程序集，编辑它，然后将ASM降低到目标机器程序集。这可能是可行的，但由于LLVM和目标ASM之间的抽象级别不同，我怀疑我是否能够通过在LLVM ASM上进行黑客攻击来检查所有的测试用例，直到它生成我想要的东西。
- 使用目标ASM测试用例作为LLVM的输入，并使用新的优化重新编译。我找不到一个选项让LLVM或gcc (他们的大多数选项LLVM都接受)接受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。
回答 2
Stack Overflow用户
发布于 2011-05-22 10:58:13
基准测试是其中的一种，您可以提出一个基准测试，根据您试图证明的内容，让任何语言或工具看起来是好是坏。
首先，我通常在没有操作系统的arm平台上工作，所以对执行进行计时非常简单，有时会精确到时钟，再加或减一个来比较编译器或选项。
特别是当你进入带有缓存的平台时，情况只会变得更糟。如果您在启动代码中添加或删除nops，导致整个程序更改其在内存中的位置，这意味着所有内容都会更改其缓存对齐方式，而没有任何编译器优化更改，您有时会发现由于缓存而导致的性能差异比编译器或后端优化中的差异更多。
我通常运行dhrystone，但不要用它来宣告成功或失败。如果你使用浮点或带有软fpu的油石，你可能也想做一个油石。
正如上面已经有人提到的，自我检查测试是一个好主意。现实世界的代码也是如此。例如，压缩例程，获取一些文本(可能是古腾堡项目中的一本书的一部分)，压缩它，然后解压缩它并将输出与输入进行比较，您可以通过在主机等控制平台上压缩它来添加额外的验证，并将压缩大小硬编码到测试中，如果测试中的压缩版本不匹配，但它仍然无法获得正确的输出。我还使用了jpeg库将图像从jpeg转换为jpeg，如果图像不希望在有损压缩后恢复到其原始状态，那么您可以只做一次传输和校验，或者验证大小，或者携带预期输出的副本并进行比较。Aes和des加密和解密。
有许多开源项目可以与修改后的编译器一起使用，以将其与常用编译器或其他编译器进行比较。作为现实世界的代码，这是你的编译器无论如何都会用到的东西。请注意，当你访问toms硬件或其他基准测试站点时，有许多不同的基准测试，渲染某些内容所需的时间，编译gcc或linux或执行数据库搜索所需的时间，以及一堆现实世界中的应用程序。并且不同的应用程序得到不同的分数，非常罕见的是一个平台/解决方案横扫测试电池。
当您进行更改时性能下降时，这是您检查汇编程序并试图找出原因的时候。记住Michael Abrash (和其他人)所说的，无论你认为你的汇编程序有多好，你仍然需要对它进行计时。也要尝试一些疯狂的事情，你肯定会很慢，因为有时你会发现它们很快，原因是你从来没有想过。
Stack Overflow用户
发布于 2011-06-14 23:35:38
你要找的是LLVM's opt command吗？
https://stackoverflow.com/questions/6084052
复制相似问题