在編寫編譯器時，如何測試編譯器優化效果？

比方說實現了某個編譯器優化，怎麼去檢驗這個優化的正確性以及優化效果呢？

正確性的話，我猜測可以用回歸測試來覆蓋，不做額外的考慮也是可以的。然而優化效果這方面我就實在沒有弄懂應該怎麼檢驗了。難道是編寫小的測試樣例然後檢驗生成的代碼的形狀嗎？感覺這樣子非常繁瑣，而且會變成平台相關的。

我看到 GCC 有個 dg （GNU Compiler Collection (GCC) Internals: C Tests），LLVM 有個 FileCheck （FileCheck - Flexible pattern matching file verifier），但是也不是很明白是怎麼工作的。

不知業內是怎麼處理的？求各位大大解答。

在微軟，我們主要靠巨量的、簡單的測試用例來看看優化是否正確的完成。總的來說，你設計一個優化的需求（而不是演算法）的時候，總要想清楚，什麼時候觸發優化，什麼時候能優化，什麼時候不能優化吧。用測試用例把他完美地表達出來，就能測試了。對比的結果就是人手寫的彙編的片段，每一個指令都一樣，那就對了。

我們做基於LLVM的DSP編譯器，基本的正確性是靠簡單的測試用例來做的。有FileCheck也有直接跑簡單的程序測，還有就是很多自動生成的測試用例，譬如根據模板生成各種不同形式的控制流。

FileCheck的好處是速度快，不過如題主所說很容易出現不穩定的測試，譬如操作數順序變了之類的。FileCheck支持regex和另外一些directive（如-DAG）來提高測試pattern的適用性，但實際中經常得去修改複雜的檢查去適應新生成的代碼，非常煩人。我們一般只會用在可以單獨隔離的模塊（譬如單獨一個IR Pass）並且盡量精簡檢查pattern。當然有crash的測試用例也是比較適合的。

至於優化的效果，最終只能靠benchmark說話。很多不同優化互相抵消掉的情況在簡單測試裡面是看不出來的，只有實測過後才知道。

主要通過跑BenchMark，各種BenchMark。BenchMark的好壞是反應編譯器優化好壞的唯一標準。