Yi-Ping Pan описывает, как удалил примерно 19 тысяч строк устаревшего C++/MLIR-кода примерно за неделю, используя LLM для разметки и классификации узлов, а не как единственный источник решения об удалении. По словам автора, в течение следующего месяца не было откатов и исправительных коммитов. Это рассказ об одном проекте, а не независимый тест модели. В статье Pan описаны метод и результат.
Удалить старый поток, не меняя остальные
В проекте поток X выбирался параметром --XYZ и уже не входил в путь выполнения по умолчанию, но его код был переплетён с действующими ветками. Целью было убрать связанный с ним код, тесты, документацию и скрипты, сохранив поведение оставшихся потоков.
Автор начал с места, где разбирался параметр и выбирался поток X. Статические инструменты, использующие compile_commands.json, прослеживали вызывающие и вызываемые функции. LLM размечала достигнутые функции: красным — если поведение зависело от значения флага, синим — если функция готовила или передавала его данные.
Сверка графа имеет границы
В описанном подходе разметку предлагалось сверять с графом вызовов, построенным отдельным инструментом от той же начальной точки. Совпадение наборов функций проверяло полноту разметки лишь среди связей, которые инструмент способен обнаружить, а не всей возможной логики программы.
Это существенно для MLIR: по словам Pan, проходы могут регистрироваться динамически, а конвейеры — собираться из строк. Такие связи применённый граф вызовов clangd может не показать. Поэтому отсутствие новых отмеченных функций при сверке не доказывает, что косвенных точек вызова нет.
Классификация направляла ручную проверку
Автор разделил узлы на четыре категории: механическое удаление, код другой команды или совместного владения, узлы с побочными эффектами и переплетённая логика, требующая точечного изменения. Идея — сосредоточить ручное внимание на местах, где удаление может затронуть интерфейсы, чужую ответственность или поведение программы.
Pan сообщает, что обнаруженные им ошибки классификации касались, в частности, целых файлов с регистрацией проходов. В C++-графе вызовов такие файлы могли выглядеть неиспользуемыми, хотя проход вызывался по строковому имени через описание конвейера или командную строку. Автор относил такие узлы к более рискованной категории, а не считал механически удаляемыми.
Какие проверки описал автор
В статье названы две цели: полное удаление всех следов потока X и отсутствие изменений поведения оставшихся потоков. Для первой автор описывает тест, который должен выявлять оставшиеся упоминания; для второй — проверку поведения сохраняемых потоков. К этому добавлялись статический анализ, классификация узлов и ручной разбор спорных случаев. Это описание процесса самим автором, а не независимая проверка его выполнения.
Итоговые примерно 19 тысяч строк за неделю и отсутствие откатов с исправительными коммитами в течение следующего месяца также сообщены Pan. Рассказ не содержит независимой проверки результата или измерений качества модели, поэтому его нельзя считать доказательством, что тот же метод даст такой результат в другой кодовой базе. Практический вывод из описания узкий: LLM может помогать сортировать узлы для проверки, но статические графы не охватывают все динамические связи, а решение об удалении требует тестов и отдельного разбора косвенно вызываемых интерфейсов.
