blocks|key|3178647|text|基准测试是其中的一种，您可以提出一个基准测试，根据您试图证明的内容，让任何语言或工具看起来是好是坏。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3178648|首先，我通常在没有操作系统的arm平台上工作，所以对执行进行计时非常简单，有时会精确到时钟，再加或减一个来比较编译器或选项。|3178649|特别是当你进入带有缓存的平台时，情况只会变得更糟。如果您在启动代码中添加或删除nops，导致整个程序更改其在内存中的位置，这意味着所有内容都会更改其缓存对齐方式，而没有任何编译器优化更改，您有时会发现由于缓存而导致的性能差异比编译器或后端优化中的差异更多。|3178650|我通常运行dhrystone，但不要用它来宣告成功或失败。如果你使用浮点或带有软fpu的油石，你可能也想做一个油石。|3178651|正如上面已经有人提到的，自我检查测试是一个好主意。现实世界的代码也是如此。例如，压缩例程，获取一些文本(可能是古腾堡项目中的一本书的一部分)，压缩它，然后解压缩它并将输出与输入进行比较，您可以通过在主机等控制平台上压缩它来添加额外的验证，并将压缩大小硬编码到测试中，如果测试中的压缩版本不匹配，但它仍然无法获得正确的输出。我还使用了jpeg库将图像从jpeg转换为jpeg，如果图像不希望在有损压缩后恢复到其原始状态，那么您可以只做一次传输和校验，或者验证大小，或者携带预期输出的副本并进行比较。Aes和des加密和解密。|3178652|有许多开源项目可以与修改后的编译器一起使用，以将其与常用编译器或其他编译器进行比较。作为现实世界的代码，这是你的编译器无论如何都会用到的东西。请注意，当你访问toms硬件或其他基准测试站点时，有许多不同的基准测试，渲染某些内容所需的时间，编译gcc或linux或执行数据库搜索所需的时间，以及一堆现实世界中的应用程序。并且不同的应用程序得到不同的分数，非常罕见的是一个平台/解决方案横扫测试电池。|3178653|当您进行更改时性能下降时，这是您检查汇编程序并试图找出原因的时候。记住Michael+Abrash+(和其他人)所说的，无论你认为你的汇编程序有多好，你仍然需要对它进行计时。也要尝试一些疯狂的事情，你肯定会很慢，因为有时你会发现它们很快，原因是你从来没有想过。|3178654|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

Benchmarking is one of those slippery slopes, you can come up with a benchmark to make any language or tool look good or bad depending on what you are trying to prove.

first off I normally work on arm platforms with no operating system so it is quite simple to time the execution, sometimes down to the clock, plus or minus one to compare compilers or options. 

Particularly when you get into platforms with a cache things just get worse. If you add or remove nops from your startup code, causing the whole program to change its location in memory meaning everything changes its cache alignment, without any compiler optimization changes you can sometimes find more performance differences due to the cache than differences in compiler or backend optimizations.

I normally run a dhrystone, but dont declare victory or failure with that. You might want to do a whetstone as well if you use float or a whetstone with a soft fpu.

As already mentioned by someone above, self checking tests are a good idea. Real world code too. For example compression routines, take some text (perhaps a portion of a book from project gutenburg), compress it, then decompress it and compare the output to the intput, you could add an extra validation by compressing it on a control platform like your host and hardcode the compressed size into the test if the compressed version under test does not match but it gets the right output it still fails. I have also used the jpeg library to convert images from/to jpeg, if the image is not expected to return to its original state with the lossy compression then you can just do one transfer and checksum or verify the size or carry a copy of the expected output and compare. Aes and des encryption and decryption. 

There are volumes of open source projects that you can use with your modified compiler to compare it to the stock compiler or other compilers. Being real world code, it is the kind of thing your compiler will be used with anyway. Note how when you go to toms hardware or other benchmark sites there are many different benchmarks, the time it takes to render something, the time it takes to compile gcc or linux or perform a database search, a bunch of real world applications. And the various applications get various scores, very rare that one platform/solution sweeps the battery of tests.

When your performance drops as you make changes that is the time you examine the assembler and try to figure out why. Remember what Michael Abrash (and others) said, no matter how good you think your assembler is you still have to time it. Also try crazy things that you are sure are going to be slow, because sometimes you find out they are fast for reasons you never thought about.

blocks|key|265714|text|你要找的是LLVM's+opt+command吗？|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|265715|entityMap|0|LINK|mutability|MUTABLE|url|http://llvm.org/cmds/opt.html^0|5|I|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Is <a href="http://llvm.org/cmds/opt.html" rel="nofollow">LLVM's opt command</a> what you are looking for?

I have written a low-level optimization for the LLVM code-generator backend. Basically, the optimization will reorder assembly instructions at the basic block level to allow a later (existing) optimization to more efficiently optimize the resultant code. There are a number of test cases I'd like to verify, and I'd like some suggestions for the testing process, as this is the first time I've attempted something like this.

Things I've considered so far:

<ol>
<li>Compile benchmarks written in C and examine the resulting ASM generated using the <code>-S</code> option. I have done this, and compared the results with my optimization to the original results. This method allows me to see that my optimization works, but even if I write custom non-executable C files I will not be able to examine all of my desired instruction ordering test cases.</li>
<li>Compile benchmarks to LLVM assembly, edit that, then lower the ASM down to the target machine assembly. This may work, but because of the different level of abstraction between LLVM and target ASM, I doubt that I'd be able to examine all the test cases by hacking at the LLVM ASM until it generates what I want it to.</li>
<li>Use the target ASM test cases as input to LLVM and recompile using the new optimization. I was unable to find an option for either LLVM or gcc (most of whose options LLVM accepts) to accept ASM as an input.</li>
</ol>

What is a good strategy for testing specific ASM test cases when validating a low-level ASM compiler optimization? Does LLVM (or gcc) have some command line options that would make this process easier?

<hr>

Edit: To clarify, I'm not asking about automatically generating ASM test cases; my problem is that I have those test cases (e.g., <code>ASM_before.s</code> and <code>reference_ASM_after.s</code>) but I need to be able to pass <code>ASM_before.s</code> into LLVM and ensure that the optimized output <code>ASM_after.s</code> matches known good <code>reference_ASM_after.s</code>. I'm looking for a way to do this without having to "decompile" <code>ASM_before.s</code> into a high-level language and then compile it (with the optimization) down to <code>ASM_after.s</code>.

Testing a Code-Generator Optimization

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我已经为LLVM代码生成器后端编写了一个低级优化。基本上，优化将在基本块级别对汇编指令进行重新排序，以允许稍后(现有的)优化更有效地优化结果代码。有许多测试用例我想要验证，我想为测试过程提供一些建议，因为这是我第一次尝试这样的事情。到目前为止我考虑过的事情：编译用C编写的基准测试程序，并检查使用-S选项生成的结果。我已...

问测试代码生成器优化
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问测试代码生成器优化EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问测试代码生成器优化
EN