Bugpoint 重新設計

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

日期：2019-06-05

狀態：草稿

簡介

隨著 bugpoint 的使用日益普及，多年來的使用經驗中已發現幾個需要改進的方面：使用上令人困惑、速度緩慢、並非總是產生高品質的測試案例等等。本文檔提出一種新的方法，其重點更為狹窄：最小化 IR 測試案例。

提議的新設計

縮小焦點：測試案例縮減

主要重點將會是程式碼縮減策略，以獲得更小的測試案例，但仍保有與原始案例相同的屬性。這將透過經典的 delta 除錯 (delta debugging) 以及添加一些 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 的功能，它將具有一系列嘗試最小化給定測試案例的階段 (passes)。我們應該能夠將工具的行為模組化，並使其更易於維護和擴展。

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

• 捨棄不影響有趣性測試的函數、指令和元數據

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

• 消除未訪問的條件路徑

• 將變數重新命名為更規則的名稱（例如 “a”、“b”、“c” 等）

一旦這些階段實作完成，將會把更有意義的縮減方式（例如類型縮減）添加到工具中，以進一步縮減 IR。

歷史 bugpoint 問題的背景

根本原因分析

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

「奇特的」介面

Bugpoint 目前的介面讓使用者感到不知所措和困惑，僅僅是說明畫面最終就會讓人感到困惑，而不是提供指導。而且，不僅有大量的功能和選項，而且其中一些功能和選項也以意想不到的方式運作，並且大多數時候使用者最終都會使用自訂腳本。為了使該工具在一般情況下更有用且更易於維護，修剪和簡化介面將值得考慮。