Почему обнаружение мертвого кода не может быть полностью решено компилятором?

Компиляторы, которые я использовал в C или Java, имеют предотвращение мертвого кода (предупреждение, когда строка никогда не будет выполнена). Мой профессор говорит, что эта проблема никогда не может быть полностью решена компиляторами. Мне было интересно, почему это так. Я не слишком знаком с фактическим кодированием компиляторов, так как это теоретический класс. Но мне было интересно, что они проверяют (например, возможные строки ввода против допустимых входных данных и т. Д.), И почему этого недостаточно.

Проблема мертвого кода связана с проблемой остановки .

Алан Тьюринг доказал, что невозможно написать общий алгоритм, который будет задан программе и сможет решить, останавливается ли эта программа для всех входов. Вы можете написать такой алгоритм для определенных типов программ, но не для всех программ.

Как это связано с мертвым кодом?

Проблема остановки может быть сведена к проблеме поиска мертвого кода. То есть, если вы найдете алгоритм, который может обнаружить мертвый код в любой программе, вы можете использовать этот алгоритм, чтобы проверить, остановится ли какая-либо программа. Поскольку это оказалось невозможным, из этого следует, что написание алгоритма для мертвого кода также невозможно.

Как вы переводите алгоритм для мертвого кода в алгоритм для проблемы остановки?

Все просто: вы добавляете строку кода после завершения программы, которую хотите проверить на остановку. Если ваш детектор мертвого кода обнаружит, что эта строка не работает, то вы знаете, что программа не останавливается. Если это не так, то вы знаете, что ваша программа останавливается (переходит к последней строке, а затем к добавленной строке кода).

Компиляторы обычно проверяют наличие вещей, которые могут быть проверены во время компиляции как мертвые. Например, блоки, которые зависят от условий, которые могут быть определены как ложные во время компиляции. Или любое утверждение после 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 . Хорошим примером может служить гипотеза Гольдбаха о том , что любое положительное целое число, большее двух, может быть представлено суммой двух простых чисел. Затем (с соответствующей библиотекой 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");

мы знаем, что программа распечатает «Найденное значение SHA» или «Не найденное значение SHA» (бонусные баллы, если вы можете сказать мне, какое из них истинно). Однако, чтобы компилятор мог разумно оптимизировать процесс, он бы занимал порядка 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.

Компилятору всегда будет не хватать некоторой контекстной информации. Например, вы можете знать, что двойное значение никогда не превышает 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()и 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никогда не будет 2так, что Action2()никогда не называется ...?

Я не согласен с проблемой остановки. Я бы не назвал такой код мертвым, хотя в действительности он никогда не будет достигнут.

Вместо этого давайте рассмотрим:

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 может быть только четным или нечетным. Поэтому компилятор должен уметь понимать семантику вашего кода. Как это должно быть реализовано? Компилятор не может гарантировать, что самый низкий возврат никогда не будет выполнен. Поэтому компилятор не может обнаружить мертвый код.