Чому компілятор не може повністю вирішити виявлення мертвого коду?

У компіляторах, якими я користувався на C або Java, є запобігання мертвому коду (попередження, коли рядок ніколи не буде виконуватися). Мій професор каже, що цю проблему ніколи не можна повністю вирішити компіляторами. Мені було цікаво, чому це так. Я не надто знайомий з фактичним кодуванням компіляторів, оскільки це клас, заснований на теорії. Але мені було цікаво, що вони перевіряють (наприклад, можливі рядки введення проти прийнятних входів тощо), і чому це недостатньо.

Проблема з мертвим кодом пов'язана з проблемою зупинки .

Алан Тьюрінг довів, що неможливо написати загальний алгоритм, який дасть програму, і зможе вирішити, чи припиняється ця програма для всіх входів. Можливо, ви зможете написати такий алгоритм для певних типів програм, але не для всіх програм.

Як це стосується мертвого коду?

Проблема зупинки зводиться до проблеми пошуку мертвого коду. Тобто, якщо ви знайдете алгоритм, який може виявити мертвий код у будь-якій програмі, ви можете використовувати цей алгоритм, щоб перевірити, чи зупиниться якась програма. Оскільки це виявилося неможливим, випливає, що написання алгоритму для мертвого коду також неможливо.

Як ви переносите алгоритм для мертвого коду в алгоритм проблеми зупинки?

Просто: ви додаєте рядок коду після закінчення програми, яку хочете перевірити на зупинку. Якщо ваш детектор мертвого коду виявить, що ця лінія мертва, то ви знаєте, що програма не зупиняється. Якщо це не так, то ви знаєте, що ваша програма зупиняється (потрапляє в останній рядок, а потім у ваш доданий рядок коду).

Зазвичай компілятори перевіряють, чи є речі, які можуть бути доведені під час компіляції, мертвими. Наприклад, блоки, які залежать від умов, які можна визначити помилковими під час компіляції. Або будь-яке твердження після return(у тому ж обсязі).

Це конкретні випадки, і тому для них можливо написати алгоритм. Можливо, можна написати алгоритми для більш складних випадків (наприклад, алгоритм, який перевіряє, чи умова є синтаксично протиріччям і тому завжди повертає помилкове), але все-таки це не охоплює всіх можливих випадків.

Ну, давайте візьмемо класичний доказ нерозбірливості проблеми зупинки та змінимо детектор зупинки на детектор мертвого коду!

Програма 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блок - це мертвий код. Таким чином, компілятор може попередити про мертвий код, лише якщо у нього є достатньо даних для з'ясування мертвого коду, а також він повинен знати, як застосувати ці дані, щоб зрозуміти, чи є даний блок мертвим кодом.

EDIT

Іноді дані просто недоступні під час компіляції:

// 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() може містити довільний код і для того, щоб компілятор визначив, повертається він істинним чи хибним, йому доведеться або запустити код, або зробити щось, що функціонально еквівалентно виконанню коду.

Ідея компілятора полягає в тому, що він виконує лише частковий аналіз коду, тим самим спрощуючи завдання окремого робочого середовища. Якщо ви виконаєте повний аналіз, це вже не компілятор.

Якщо ви розглядаєте компілятор як функцію 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 може бути парним або непарним. Тому компілятор повинен вміти розуміти семантику вашого коду. Як це слід реалізувати? Компілятор не може забезпечити, щоб найнижчий показник ніколи не був виконаний. Тому компілятор не може виявити мертвий код.