LLVMテスト

継続する。 ここから始めてください 。

はじめに

プログラムが特定のサイズに達すると、指定が不十分であり、1人が完全に理解できないことが保証されます。 これは、お互いの仕事にあまり気づいていない人々によって1日に何度も確認されています。 このプログラムには、コンパイラ、オペレーティングシステム、ライブラリなど、多くの依存関係があり、それぞれに独自のバグが含まれており、これらはすべて随時更新されます。 さらに、ソフトウェアは通常、いくつかの異なるプラットフォームで動作する必要があり、各プラットフォームには独自の特性があります。 不正行為の機会が多数あることを考えると、なぜ私たちの大規模なプログラムが期待どおりに機能すると期待できるのでしょうか？ 最も重要なことの1つはテストです。 したがって、私たちにとって重要な構成とプラットフォームでソフトウェアが正常に動作することを確認できます。動作しない場合は、問題を追跡して修正できる優秀な人がいます。



今日は、LLVMテストについて説明します。 多くの点で、コンパイラはテストするのに適したオブジェクトです。

• 入力形式（ソースコード）と出力形式（アセンブラコード）はよく理解されており、独立した仕様があります。
• 多くのコンパイラには中間表現（IR）があり、それ自体が文書化され、推論および解析できるため、内部テストが容易になります（常にではありませんが）。
• 多くの場合、コンパイラーはC ++標準などの仕様の独立した実装の1つであり、これにより差分テストが可能になります。 多くの実装が利用できない場合でも、自分自身と比較し、異なるバックエンドまたは異なる最適化モードの出力を比較することにより、多くの場合コンパイラをテストできます。
• コンパイラは通常、ネットワーク機能、競争力、時間依存性を持たず、非常に限られた方法で常に外部とやり取りします。 さらに、コンパイラは通常決定論的です。
• コンパイラは通常、長期間動作しません。また、リソースリークやエラーからの回復について心配する必要はありません。

しかし一方で、コンパイラーはそれほど簡単にテストできません。

• コンパイラは高速である必要があり、多くの場合、安全でない言語で記述されており、アサーションが不十分です。 可能な場合は常にキャッシュとレイジーコンピューティングを使用するため、複雑さが増します。 さらに、コンパイラー関数を多くの明確で独立した小さなパッセージに分離すると、コンパイラーの速度が低下し、無関係または疎結合の関数を結合する傾向があり、コンパイラーの理解、テスト、および保守がより難しくなります。
• 内部コンパイラのデータ構造の不変式は、完全に地獄であり、完全に文書化されていない場合があります。
• 一部のコンパイルアルゴリズムは複雑で、ほとんど決してコンパイラーが教科書のアルゴリズムを正確に実装していませんが、多少の違いはあります。
• コンパイラの最適化は複雑な方法で相互作用します。
• 安全でない言語のコンパイラーは、未定義の動作をコンパイルする際に義務を負わず、コンパイラーの外部（およびコンパイラーのテストを作成するユーザー）にUBの欠如に対する責任を移します。 これにより、差動テストが複雑になります。
• 正しくコンパイルされていないプログラムはデバッグが困難であり、コンパイラはコンパイルされたコードに静かに脆弱性を追加できるため、コンパイラの正確さの基準は非常に高くなっています。

したがって、これらの基本的なことを知ってから、LLVMのテスト方法を検討してください。

単体テストと回帰テスト

LLVMのバグに対する最初の防衛線は、開発者がチェック対象を収集したときに実行されるテストスイートです。 開発者がLLVMにパッチをコミットする前に、これらのすべてのテストを完了する必要があります（もちろん、多くのパッチには新しいテストが含まれる場合があります）。 かなり高速なデスクトップでは、19,267回のテストが96秒で合格します。 実行されるテストの数は、ダウンロードした追加のLLVMプロジェクト（compiler-rt、libcxxなど）、および程度は低いが、マシンで自動的に検出されるソフトウェア（バンドルなど）によって異なりますOCamlのインストールは、OCamlがインストールされるまでテストされません。 ここで述べたように、これらのテストは迅速である必要があり、開発者は頻繁にテストを実行できます 。 check-allやcheck-clangなどのターゲットをビルドするときに追加のテストが実行されます。



一部の単体テストと回帰テストはAPIレベルで実行され、テストフレームワークを接続するためのC ++マクロを提供する軽量フレームワークであるGoogle Testを使用します 。 テスト例を次に示します。

TEST_F(MatchSelectPatternTest, FMinConstantZero) { parseAssembly( "define float @test(float %a) {\n" " %1 = fcmp ole float %a, 0.0\n" " %A = select i1 %1, float %a, float 0.0\n" " ret float %A\n" "}\n"); // This shouldn't be matched, as %a could be -0.0. expectPattern({SPF_UNKNOWN, SPNB_NA, false}); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

TEST_Fマクロの最初の引数はテストコレクションの名前を示し、2番目は特定のテストの名前です。 parseAssembly（）およびexpectPattern（）メソッドはLLVM APIを呼び出し、結果を確認します。 この例はValueTrackingTest.cppから取られています。 1つのファイルに複数のテストを含めることができ、fork / execがないためにテストの通過を加速します。



LLVMクイックテストスイートで使用される別のインフラストラクチャは、 lit LLVM Integrated Testerです。 litはシェルベースであり、テストコマンドを実行し、すべてのコマンドが正常に完了した場合にテストが成功したと結論付けます。



点灯テストの例を次に示します（ このファイルの最初から取得しましたが、これには今は関係ない追加のテストが含まれています）。

 ; RUN: opt < %s -instcombine -S | FileCheck %s define i64 @test1(i64 %A, i32 %B) { %tmp12 = zext i32 %B to i64 %tmp3 = shl i64 %tmp12, 32 %tmp5 = add i64 %tmp3, %A %tmp6 = and i64 %tmp5, 123 ret i64 %tmp6 ; CHECK-LABEL: @test1( ; CHECK-NEXT: and i64 %A, 123 ; CHECK-NEXT: ret i64 }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このテストは、中間コードの覗き穴レベルの最適化パススルーであるInstCombineが、ここではzext、shl、およびaddが不要な命令に気付くことができることを検証します。 CHECK-LABEL行は、最適化されたコード関数が開始する行を検索し、最初のCHECK-NEXTはandステートメントが次に移動することを確認し、2番目のCHECK-NEXTはretステートメントが次に移動することを確認します（正確でタイムリーな説明をしてくれたMichael Kupersteinに感謝します）このテスト）。



テストを実行するために、ファイルは3回解釈されます。 まず、スキャンされ、「RUN：」を含む行が検索され、対応するすべてのコマンドが実行されます。 次に、ファイルはoptユーティリティ、LLVM IRオプティマイザーによって解釈されます。これは、 litは、％s変数を処理中のファイルの名前に置き換えました。 テキスト形式のLLVM IRのコメントはセミコロンで始まるため、ライトディレクティブはオプティマイザーによって無視されます。 オプティマイザーの出力はFileCheckユーティリティに送られ、ファイルを再度解析し、CHECKやCHECK-NEXTなどのコマンドを探し、それらのユーティリティがstdinの行を探すように強制し、特定の行が見つからない場合はゼロ以外の終了コードを返します（CHECK-LABELが使用されますファイルを論理的に別個のテストのセットに分割します）。



テストの重要な戦略目標は、カバレッジ分析ツールを使用して、テストでカバーされていないコードベースの部分を見つけることです。 以下は、ユニット/リグレッションテストの開始に基づいた最新のLLVMカバレッジレポートです。 これらのデータは、それらをより詳細に研究するのに十分興味深いものです。 InstCombineのカバレッジを見てみましょう。これは一般的に非常に優れています（ 残念ながらリンクは利用できません。コメントperev ）。 LLVMを使い始めたい人にとって興味深いプロジェクトは、InstCombineのテストされていない部分をカバーするテストを書くことです。 たとえば、InstCombineAndOrXor.cppのテスト（赤で強調表示）で発見された最初のコードは次のとおりです。







このコメントは、変換パスを探していることを示しており、このコードのテストを書くのはかなり簡単なはずです。 テストできないコードはデッドです。時には、デッドコードを削除することをお勧めします。他のケースでは、この例のように（同じファイルから）、バグが現れた場合にのみコードはデッドになります。







これらの行をカバーしようとすることは良い考えですが、この場合は、テストスイートを改善するだけでなく、LLVMのバグを見つけようとしています。 到達不能としてマークされた行について教えてくれないように、カバレッジ分析ツールを教えることは良い考えかもしれません。

LLVMテストスイート

LLVMリポジトリの一部であり、迅速に実行できる回帰/単体テストとは対照的に、 テストスイートは外部であり、時間がかかります。 開発者は、コミットする前にこれらのテストを実行することは期待されていませんが、これらのテストは自動的に実行され、多くの場合LNTを使用します（次のセクションを参照）。 LLVMテストスイートには、コンパイルおよび実行されるプログラム全体が含まれています。これは、特定の最適化を目的としたものではなく、生成されたコード全体の品質と正確性を確認するためのものです。



各ベンチマークについて、テストスイートにはテスト入力と対応する予想出力が含まれています。 テストスイートの一部は外部です。つまり、これらのテストの呼び出しがサポートされていますが、テスト自体はテストスイートの一部ではなく、通常はフリーでないソフトウェアを使用するため、個別にダウンロードする必要があります。

Lnt

LNT（LLVM Nightly Test）にはテストが含まれていません;コンパイラによって生成されたコードの品質を監視することに焦点を合わせたテスト結果の集約および分析ツールです。 テストを実行して結果を確認するためのローカルユーティリティと、結果を簡単に表示できるサーバーデータベースおよびWebフロントエンドが含まれています。 NTS（Nightly Test Suite）の結果はこちらです。

Buildbot

Linux / Windows BuiltBotおよびDarwin BuiltBot（これらが2つある理由はわかりません）を使用して、LLVMが構成され、ビルドされ、多数の異なるプラットフォームおよびさまざまな構成でユニット/回帰テストに合格するようにします。 BuildBotは、問題のコミットを見つけて作成者に手紙を送信するために、blameコマンドをサポートしています。

折Testing的なテストの取り組み

LLVMコミュニティのコアの外側でいくつかのテスト作業が行われ、どのバージョンのLLVMがテストされているかという意味で体系的ではありません。 これらのテストは、特定のツールまたはテクニックを試してみたい個々の開発者の努力により現れました。 たとえば、長い間、私のグループはCsmithを使用してClang + LLVMをテストし 、見つかったエラーを報告しました（ 高レベルの説明を参照）。 Sam Liedes はafl-fuzzを使用して Clangをテストしました。 Zhendong Suと彼のグループは、非常に印象的なバグを発見しました。 Nuno Lopesは 、最適化パスの驚くべき形式的手法のテストを行いました。これについては、すぐに書きたいと思います。

野生生物試験

もちろん、最後のレベルのテストはLLVMユーザーによって実行されます。LLVMユーザーは、クラッシュや不適切なコンパイルを引き起こすことがありますが、他のテスト方法では見逃していました。 コンパイラのバグの発生をよりよく理解したかったことがよくありました。 バグの原因を特定するためにコードを削減することは困難であるため、ユーザーコードの不正なコンパイルの理由を特定することは困難です。 しかし、人々はデバッグプロセス中にコードの擬似ランダム変更を使用し、偶然による問題に対処し、すぐにそれを忘れます。



大きな革新は、LLVMに翻訳検証スキームを導入し、SMTソルバーを使用してコンパイラー出力が入力と一致することを証明することです。 ここには、未定義の動作や、実際にはコンパイルエラーを引き起こす大きな関数に検証を拡大することが難しいという事実など、多くの問題があります。

代替テストオラクル

テストOracleは、テストに合格したかどうかを判断する方法です。 単純なオラクルには、「コンパイラがコード0で終了した」または「コンパイルされたベンチマークが期待される出力を返した」などのチェックが含まれます。 ただし、「リリース後の使用」など、プログラムのクラッシュやオーバーフロー全体を引き起こさなかった興味深いバグの多くは見逃されます（GCCの例については、 この記事の 7ページを参照してください）。 ASan、UBSan、Valgrindなどのバグ検出器は、プログラムにCおよびC ++標準から派生したオラクルを装備することができ、バグを見つけるための多くの有用な機会を提供します。 ValgrindでLLVMを実行し、テストスイートを実行するには、-DLLVM_LIT_ARGS = "-v --vg"をCMakeに渡しますが、Valgrindが除去が困難な誤検知を生成できるように準備してください。 UBSanでLLVMをテストするには、DLLVM_USE_SANITIZER = UndefinedをCMakeに渡します。 これはすばらしいことですが、UBSan / ASan / MSanは未定義の動作のすべてのケースをキャッチするわけではなく、上記の例のGCCで符号なし整数をオーバーフローさせるなどの特定の誤った動作もキャッチしないため、多くの作業が必要です。

テストが失敗するとどうなりますか？

コミットが壊れると、どのレベルでもテストがクラッシュする可能性があります。 このようなコミットは、（これが困難でない場合）修復されるか、深い欠陥がある場合、または落下テストによって提供される新しい情報に照らして望ましくない場合は拒否されます。 これは、多くの実際のユーザーが存在する大規模で複雑なコードベースを大きな変更から保護するために頻繁に発生します。



テストがクラッシュし、問題をすぐに修正するのが難しい場合、たとえば新しい機能が完了したときに修正できる場合、テストはXFAILまたは「予想される失敗」としてマークできます。 このようなテストはテストツールによって個別に考慮され、パッチが承認される前に修正する必要がある一般的なフォールドテストのスコアには含まれません。

おわりに

LLVMユーザーをバグから保護したい場合、大規模で移植性が高く、広く使用されているソフトウェアシステムのテストは、多くの作業を伴う困難な作業です。 もちろん、高品質のコードを維持するために必要な他の非常に重要なこともあります：良いデザイン、コードのレビュー、中間プレゼンテーションのセマンティクス、静的分析、問題領域の定期的な処理。