Zek*_*eke 19 testing assembly gcc code-generation llvm
我已经为LLVM代码生成器后端编写了一个低级优化.基本上,优化将在基本块级重新排序汇编指令,以允许稍后(现有)优化更有效地优化结果代码.我想验证一些测试用例,我想对测试过程提出一些建议,因为这是我第一次尝试这样的测试.
到目前为止我考虑过的事情:
编译用C编写的基准测试,并检查使用该-S选项生成的ASM .我已经完成了这项工作,并将结果与我的优化结果进行了比较.这个方法让我看到我的优化工作,但即使我编写自定义的非可执行C文件,我也无法检查所有我想要的指令排序测试用例.
将基准编译到LLVM程序集,编辑它,然后将ASM降低到目标机器程序集.这可能有效,但是由于LLVM和目标ASM之间的抽象级别不同,我怀疑我能够通过攻击LLVM ASM来检查所有测试用例,直到它生成我想要的内容为止.
使用目标ASM测试用例作为LLVM的输入,并使用新的优化重新编译.我无法为LLVM或gcc(LLVM接受的大多数选项)找到一个选项来接受ASM作为输入.
在验证低级ASM编译器优化时,测试特定ASM测试用例的好策略是什么？LLVM(或gcc)是否有一些命令行选项可以使这个过程更容易？
编辑:为了澄清,我不是要求自动生成ASM测试用例; 我的问题是我有那些测试用例(例如,ASM_before.s和reference_ASM_after.s),但我需要能够传入ASM_before.sLLVM并确保优化的输出ASM_after.s与已知的好reference_ASM_after.s.我正在寻找一种方法来做到这一点,而无需"反编译" ASM_before.s成高级语言,然后将其编译(优化)到ASM_after.s.
基准测试是那些滑坡之一,你可以提出一个基准来使任何语言或工具看起来好或坏,取决于你想要证明什么.
首先,我通常在没有操作系统的手臂平台上工作,所以很容易计算执行时间,有时直到时钟,加上或减去一个来比较编译器或选项.
特别是当你进入带缓存的平台时,事情会变得更糟.如果在启动代码中添加或删除nops,导致整个程序在内存中更改其位置意味着一切都会更改其缓存对齐,而不进行任何编译器优化更改,有时会发现由于缓存而导致的性能差异比编译器或后端的差异更多优化.
我通常会运行dhrystone,但不要宣告胜利或失败.如果你使用漂浮物或带有柔软fpu的磨刀石,你可能也想做一个磨刀石.
正如上面提到的那样,自我检查测试是一个好主意.真实的世界代码.例如压缩例程,获取一些文本(可能是项目gutenburg的一部分书籍),压缩它,然后解压缩并将输出与输入进行比较,您可以通过在主机等控制平台上压缩它来添加额外的验证如果被测试的压缩版本不匹配但是得到正确的输出它仍然失败,则将压缩大小硬编码到测试中.我还使用jpeg库将图像从/转换为jpeg,如果图像不希望通过有损压缩返回到其原始状态,那么你可以只进行一次传输和校验和或验证大小或携带副本预期产出和比较.Aes和des加密和解密.
有大量的开源项目可以与修改后的编译器一起使用,以将其与库存编译器或其他编译器进行比较.作为真实世界的代码,无论如何,它都是你的编译器所使用的东西.请注意,当您访问toms硬件或其他基准站点时,有许多不同的基准,渲染内容所需的时间,编译gcc或linux或执行数据库搜索所需的时间,以及一堆真实世界的应用程序.并且各种应用程序获得了各种分数,非常罕见,一个平台/解决方案扫描了大量测试.
当您进行更改时性能下降,这是您检查汇编程序并尝试找出原因的时间.记住迈克尔·阿布拉什(和其他人)所说的,无论你认为你的装配工有多好,你仍然需要时间.还要尝试一些你肯定会变慢的疯狂事情,因为有时你会发现它们很快就会出现你从未想过的原因.