コンパイラーでデッドコード検出を完全に解決できないのはなぜですか？

私がCまたはJavaで使用していたコンパイラーには、デッドコード防止機能（行が実行されない場合に警告）があります。私の教授は、この問題はコンパイラーでは完全には解決できないと言います。なぜなのかと思っていました。これは理論に基づくクラスなので、コンパイラの実際のコーディングについてはあまり詳しくありません。しかし、私は彼らが何をチェックするのか（考えられる入力文字列と許容可能な入力など）、なぜそれが不十分なのかと思っていました。

デッドコードの問題は、停止の問題に関連しています。

アラン・チューリングは、プログラムを与えられ、そのプログラムがすべての入力で停止するかどうかを決定できる一般的なアルゴリズムを書くことは不可能であることを証明しました。特定のタイプのプログラムに対してこのようなアルゴリズムを作成できる場合がありますが、すべてのプログラムについてはそうではありません。

これはデッドコードとどのように関係していますか？

停止の問題は、死んだコードを見つける問題に還元できます。つまり、任意のプログラムでデッドコードを検出できるアルゴリズムを見つけた場合、そのアルゴリズムを使用して、プログラムが停止するかどうかをテストできます。それは不可能であることが証明されているので、デッドコードのアルゴリズムを書くことも不可能であるということになります。

デッドコードのアルゴリズムを停止問題のアルゴリズムにどのように転送しますか？

単純：停止を確認するプログラムの終了後にコード行を追加します。デッドコード検出器がこの行がデッドであることを検出した場合、プログラムは停止しないことがわかります。そうでない場合は、プログラムが停止していることがわかります（最後の行に移動してから、追加したコード行に移動します）。

コンパイラは通常、コンパイル時に死んでいることが証明できるものがないかチェックします。たとえば、コンパイル時にfalseであると判断できる条件に依存するブロック。または、aの後のステートメントreturn（同じスコープ内）。

これらは特定のケースであるため、それらのアルゴリズムを作成することが可能です。もっと複雑なケース（条件が構文的に矛盾しているかどうかをチェックし、そのため常にfalseを返すかどうかをチェックするアルゴリズムなど）のアルゴリズムを作成することは可能かもしれませんが、それでもすべての可能なケースをカバーするわけではありません。

さて、停止問題の決定不可能性の古典的な証明を取り、停止検出器をデッドコード検出器に変更しましょう！

C＃プログラム

using System;
using YourVendor.Compiler;

class Program
{
    static void Main(string[] args)
    {
        string quine_text = @"using System;
using YourVendor.Compiler;

class Program
{{
    static void Main(string[] args)
    {{
        string quine_text = @{0}{1}{0};
        quine_text = string.Format(quine_text, (char)34, quine_text);

        if (YourVendor.Compiler.HasDeadCode(quine_text))
        {{
            System.Console.WriteLine({0}Dead code!{0});
        }}
    }}
}}";
        quine_text = string.Format(quine_text, (char)34, quine_text);

        if (YourVendor.Compiler.HasDeadCode(quine_text))
        {
            System.Console.WriteLine("Dead code!");
        }
    }
}

がYourVendor.Compiler.HasDeadCode(quine_text)返された場合false、その行System.Console.WriteLn("Dead code!");は実行されないため、このプログラムには実際にはデッドコードがあり、検出器が間違っていました。

しかし、それがを返したtrue場合、その行System.Console.WriteLn("Dead code!");が実行され、プログラム内にコードがなくなるため、デッドコードがまったくなくなり、検出器が間違っていました。

つまり、「デッドコードあり」または「デッドコードなし」のみを返すデッドコード検出器は、間違った答えを返すことがあります。

停止の問題があまりにもあいまいな場合は、このように考えてください。

すべての正の整数のために真であると考えられている数学の問題乗りのnが、すべてのために真であることが証明されていないn個を。良い例はゴールドバッハの予想です。2より大きい正の偶数は2つの素数の和で表すことができます。次に、（適切なbigintライブラリを使用して）このプログラムを実行します（擬似コードが続きます）。

 for (BigInt n = 4; ; n+=2) {
     if (!isGoldbachsConjectureTrueFor(n)) {
         print("Conjecture is false for at least one value of n\n");
         exit(0);
     }
 }

の実装はisGoldbachsConjectureTrueFor()読者の練習問題として残されていますが、この目的のために、すべての素数よりも単純な反復である可能性がありますn

さて、論理的には上記は以下と同等でなければなりません：

 for (; ;) {
 }

（つまり、無限ループ）または

print("Conjecture is false for at least one value of n\n");

ゴールドバッハの予想が真実かそうでないかのどちらかであるように。コンパイラーが常にデッドコードを排除できるのであれば、どちらの場合も確実にここで排除するデッドコードがあります。ただし、そうする場合、少なくともコンパイラは任意の難しい問題を解決する必要があります。どのビットのコードを除去するかを決定するために解決しなければならないであろう証明困難な問題（たとえば、NP完全な問題）を提供することができます。たとえば、次のプログラムを実行するとします。

 String target = "f3c5ac5a63d50099f3b5147cabbbd81e89211513a92e3dcd2565d8c7d302ba9c";
 for (BigInt n = 0; n < 2**2048; n++) {
     String s = n.toString();
     if (sha256(s).equals(target)) {
         print("Found SHA value\n");
         exit(0);
     }
 }
 print("Not found SHA value\n");

プログラムは「Found SHA value」または「Not found SHA value」のいずれかを出力することを知っています（どちらが真であるかを教えてくれればボーナスポイント）。ただし、コンパイラーが合理的に最適化できるようにするには、2 ^ 2048回の繰り返しが必要になります。上記のプログラムは最適化せずに何かを印刷するのではなく、宇宙の熱死まで実行される（または実行される可能性がある）と私は予測しているので、それは実際には素晴らしい最適化です。

C ++またはJavaにEval型関数があるかどうかはわかりませんが、多くの言語ではメソッドを名前で呼び出すことができます。次の（考案された）VBAの例を考えます。

Dim methodName As String

If foo Then
    methodName = "Bar"
Else
    methodName = "Qux"
End If

Application.Run(methodName)

呼び出されるメソッドの名前は、実行時まで知ることができません。したがって、コンパイラーは定義上、特定のメソッドが呼び出されないことを確実に知ることはできません。

実際、名前でメソッドを呼び出す例を考えると、分岐ロジックは必要ありません。単に言って

Application.Run("Bar")

コンパイラが判断できる以上のものです。コードがコンパイルされるとき、コンパイラはすべて、特定の文字列値がそのメソッドに渡されていることを知っています。このメソッドが存在するかどうかは、実行時まで確認されません。メソッドが他の場所で呼び出されない場合、より通常のメソッドを介して、デッドメソッドを見つけようとすると、誤検知が返される可能性があります。同じ問題が、リフレクションを介してコードを呼び出すことができるすべての言語に存在します。

無条件のデッドコードは、高度なコンパイラによって検出および削除できます。

しかし、条件付きデッドコードもあります。これは、コンパイル時に認識できず、実行時にのみ検出できるコードです。たとえば、ソフトウェアは、ユーザーの好みに応じて特定の機能を含めたり除外したりするように構成でき、特定のシナリオではコードの特定のセクションが死んでいるように見えます。それは本当のデッドコードではありません。

テストを実行し、依存関係を解決し、条件付きデッドコードを削除し、実行時に効率的なコードを再結合できる特定のツールがあります。これは動的デッドコード除去と呼ばれます。しかし、ご覧のとおり、コンパイラの範囲を超えています。

簡単な例：

int readValueFromPort(const unsigned int portNum);

int x = readValueFromPort(0x100); // just an example, nothing meaningful
if (x < 2)
{
    std::cout << "Hey! X < 2" << std::endl;
}
else
{
    std::cout << "X is too big!" << std::endl;
}

ここで、ポート0x100が0または1のみを返すように設計されていると想定します。その場合、コンパイラーはelseブロックが実行されないことを理解できません。

ただし、この基本的な例では：

bool boolVal = /*anything boolean*/;

if (boolVal)
{
  // Do A
}
else if (!boolVal)
{
  // Do B
}
else
{
  // Do C
}

ここで、コンパイラはelseブロックがデッドコードであることを計算できます。そのため、コンパイラーは、デッドコードを理解するのに十分なデータがある場合にのみデッドコードについて警告することができ、指定されたブロックがデッドコードであるかどうかを把握するためにそのデータを適用する方法を知っている必要があります。

編集

コンパイル時にデータが利用できない場合があります。

// File a.cpp
bool boolMethod();

bool boolVal = boolMethod();

if (boolVal)
{
  // Do A
}
else
{
  // Do B
}

//............
// File b.cpp
bool boolMethod()
{
    return true;
}

a.cppのコンパイル中、コンパイラはboolMethod常にが返されることを認識できませんtrue。

コンパイラーは常にいくつかのコンテキスト情報を欠いています。たとえば、double値が2を超えることは決してないことを知っているかもしれません。これは数学関数の機能であるため、ライブラリから使用します。コンパイラーはライブラリー内のコードさえも認識せず、すべての数学関数のすべての機能を知ることはできず、それらを実装するための奇妙で複雑な方法をすべて検出することはできません。

コンパイラは必ずしもプログラム全体を見るとは限りません。直接呼び出されない私のプログラムの関数にコールバックする共有ライブラリを呼び出すプログラムがあるかもしれません。

そのため、コンパイル時にライブラリに対して無効になっている関数は、そのライブラリが実行時に変更された場合に有効になる可能性があります。

コンパイラーがすべてのデッドコードを正確に排除できる場合、それはインタープリターと呼ばれます。

この単純なシナリオを考えてみましょう：

if (my_func()) {
  am_i_dead();
}

my_func() 任意のコードを含めることができ、コンパイラがtrueまたはfalseを返すかどうかを判断するには、コードを実行するか、コードの実行と機能的に同等の処理を行う必要があります。

コンパイラーの考え方は、コードの部分的な分析のみを実行することであり、これにより、別の実行環境のジョブを簡素化します。完全な分析を実行すると、それはもはやコンパイラではありません。

あなたは関数としてコンパイラを考慮すればc()、c(source)=compiled code、およびなど実行している環境r()、r(compiled code)=program outputそしてあなたがの値を計算する必要がある任意のソースコードの出力を決定するために、r(c(source code))。計算で任意の入力のc()値の知識がr(c())必要な場合、個別のr()andの必要はありません。そのようなc()関数i()から関数を導出できます。c()i(source)=program output

他の人たちは停止問題などについてコメントしています。これらは一般的に機能の一部に適用されます。ただし、タイプ全体（クラスなど）が使用されているかどうかを知るのは困難/不可能である場合があります。

.NET / Java / JavaScriptおよびその他のランタイム駆動環境では、リフレクションを介してロードされる型を停止するものは何もありません。これは、依存性注入フレームワークで人気があり、逆シリアル化または動的モジュールの読み込みに直面して考えるのはさらに困難です。

コンパイラーは、そのようなタイプがロードされるかどうかを知ることができません。それらの名前は、実行時に外部構成ファイルから取得される可能性があります。

未使用のコードのサブグラフを安全に削除しようとするツールの一般的な用語であるツリーシェーキングを探してみてください。

機能を取る

void DoSomeAction(int actnumber) 
{
    switch(actnumber) 
    {
        case 1: Action1(); break;
        case 2: Action2(); break;
        case 3: Action3(); break;
    }
}

あなたはそれが決して呼ばれactnumberないことを証明することができます...？2Action2()

停止の問題について私は同意しません。実際に到達することは決してないだろうが、私はそのようなコードを死んだとは呼びません。

代わりに、検討してみましょう：

for (int N = 3;;N++)
  for (int A = 2; A < int.MaxValue; A++)
    for (int B = 2; B < int.MaxValue; B++)
    {
      int Square = Math.Pow(A, N) + Math.Pow(B, N);
      float Test = Math.Sqrt(Square);
      if (Test == Math.Trunc(Test))
        FermatWasWrong();
    }

private void FermatWasWrong()
{
  Press.Announce("Fermat was wrong!");
  Nobel.Claim();
}

（タイプとオーバーフローエラーは無視してください）デッドコード？

この例を見てください：

public boolean isEven(int i){

    if(i % 2 == 0)
        return true;
    if(i % 2 == 1)
        return false;
    return false;
}

コンパイラーは、intが偶数または奇数にしかなり得ないことを知ることができません。したがって、コンパイラーはコードのセマンティクスを理解できなければなりません。これはどのように実装する必要がありますか？コンパイラーは、最低のリターンが実行されないことを保証できません。したがって、コンパイラはデッドコードを検出できません。