Bugpoint 重新設計

作者：Diego Treviño (diegotf@google.com)

日期：2019-06-05

狀態：草稿

簡介

隨著 bugpoint 的使用日益增長，多年來，我們透過使用經驗識別出了一些需要改進的地方：使用方式令人困惑、速度緩慢、並非總能產生高品質的測試案例等等。本文件提出了一種新的方法，其重點更為狹窄：縮減 IR 測試案例。

建議的新設計

重點明確：測試案例縮減

主要重點將是程式碼縮減策略，以取得更小的測試案例，但仍保留與原始測試案例相同的屬性。這將透過經典的 delta 除錯以及新增一些特定於 IR 的縮減（例如，替換全域變數、移除未使用的指令等）來完成，類似於現有的功能，但會進行更深入的縮減。

當然，如果社群對此提案有不同意見，舊版程式碼仍然可以保留在工具中，但需要注意的是，這些程式碼仍然會被記錄下來，並且設計方向仍以 delta 縮減為主。

命令列選項

我們建議將眾多的 bugpoint 選項減少到僅剩兩個：一個用於判斷測試案例是否「有趣」的測試，以及該測試的參數，類似於其他 delta 縮減工具，例如 CReduce、Delta 和 Lithium；這個工具應該會變得更簡潔，而且使用方式也應該更明確。

將執行的「有趣」測試會透過名稱指定：--test=<test_name> 如果未指定 --test 選項，程式就會結束；這個選項類似於 bugpoint 目前的 -compile-custom 選項，該選項允許使用者執行自訂腳本。

「有趣」測試的定義是：當 IR 達到使用者定義的行為時（例如，clang 編譯失敗），腳本會傳回 0；否則，則會傳回非零值。讓使用者可以自由決定什麼對工具來說是「有趣」的，從而簡化縮減測試案例的流程。

如果測試接受任何參數（不包括輸入的 ll/bc 檔案），則會透過以下旗標指定：--test_args=<test_arguments> 如果未指定，則會按原樣執行測試。值得注意的是，輸入檔案會作為參數傳遞給測試，類似於 -compile-custom 目前的運作方式。

實作

這個工具的行為會類似於 CReduce 的功能，它會有一個通行證清單，嘗試將給定的測試案例縮減到最小。我們應該要能夠將工具的行為模組化，並使其更容易維護和擴充。

此重新設計的第一個版本將嘗試

• 捨棄不影響「有趣性」測試的函數、指令和中繼資料

• 移除函數中未使用的參數

• 消除未訪問的條件路徑

• 將變數重新命名為更規律的名稱（例如「a」、「b」、「c」等）

一旦實作了這些過程，將會在工具中加入更有意義的簡化步驟（例如類型簡化），以進一步簡化 IR。

Bugpoint 歷史問題的背景說明

根本原因分析

目前，bugpoint 需要很長時間才能在給定的 IR 檔案中找到問題根源，這主要是因為它嘗試透過執行各種策略來對錯誤進行分類來除錯輸入，而這些策略又會在輸入上執行多個優化器和編譯過程，佔用了大量的時間。此外，當 IR 崩潰時，它會嘗試透過執行一些次優的過程（例如許多無法到達的區塊）來減少 IR，有時甚至根本無法最小化。

「奇怪的」介面

Bugpoint 目前的介面讓使用者感到困惑和不知所措，光是說明畫面就讓人困惑，而不是提供指引。而且，不僅有眾多的功能和選項，而且其中一些功能和選項的使用方式出乎意料，而且使用者大多數時候最終會使用自訂腳本。為了使該工具在一般情況下更有用且更容易維護，值得考慮精簡和簡化介面。