Какова область оптимизации в компиляторе?

Question

Когда компилятор оптимизирует код, какова область оптимизации? Может оптимизация
а) охватывать больше, чем набор вложенных скобок?
б) охватывают больше, чем функция?
в) охватывать больше, чем файл?

Мы преследуем неясную ошибку, которая, кажется, происходит от оптимизации. Сбой кода в режиме выпуска, но не в режиме отладки. И, конечно, мы знаем, что это может быть повреждение кучи или другие проблемы с памятью, которые преследовали это уже некоторое время. Один из вариантов, который мы рассматриваем, заключается в выборочной компиляции наших файлов в режиме отладки, пока проблема не исчезнет. Другими словами:

a) Начните со всех файлов, скомпилированных в режиме выпуска
б) скомпилировать 1/2 файла в режиме отладки
если сбой все еще замечен, возьмите половину скомпилированных файлов релиза и скомпилируйте в режиме отладки
если сбоя не видно, говорите половину файлов, скомпилированных в режиме отладки, и скомпилируйте в режиме выпуска
повторять, пока мы не сузим подозрительные файлы
это двоичный поиск, чтобы сузить проблемные файлы

Мы понимаем, что если это проблема с памятью, простое выполнение этой смешанной компиляции может убрать ошибку, но мы извиняемся, если сможем сузить проблемные файлы.

Однако остается нерешенным вопрос: какова область оптимизации? Могут ли они охватывать более одного файла?

Answer 1

Оптимизация может делать буквально что угодно , если она не меняет семантику поведения, определенного языком.Это означает, что ответы на ваши первые вопросы (a), (b) и (c) - все да.На практике большинство компиляторов не столь амбициозны, но, безусловно, есть несколько примеров.Clang и LLVM имеют флаги для оптимизации времени соединения , которые позволяют оптимизации охватить почти всю программу.MSVC имеет аналогичный флаг /GL, который допускает оптимизацию всей программы.

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

Удачи!

Answer 2

Вы можете приблизительно идентифицировать проблемные файлы по следам сбоев вызовов в режиме выпуска. Затем попытайтесь восстановить их без оптимизации - это намного проще, чем бинарный поиск.

Answer 3

Я думаю, что вы задаете неправильный вопрос.

Маловероятно (если вы не делаете что-то особенное), что оптимизатор является вашей проблемой.

Скорее всего, проблема в неинициализированной переменнойв вашем коде.
Когда вы компилируете в режиме отладки, большинство компиляторов инициализируют всю память по определенному шаблону, чтобы во время отладки вы могли видеть, что произошло с памятью (было ли это выделено / было ли оно полностью покрыто / было ли оноиз стека / Был ли стек извлечен из и т.д.).

Таким образом, в режиме отладки любая неинициализированная память имеет определенный шаблон, который может быть распознан отладчиком.Точный шаблон будет зависеть от компилятора.Но это может заставить работать неаккуратный код, поскольку неинициализированные указатели имеют значение NULL, целочисленные счетчики начинаются с 0 и т. Д.

Когда вы компилируете для режима выпуска, вся дополнительная инициализация отключается.Если вы явно не инициализировали память, она находится в случайном состоянии .Это то, что отладочные / выпускные версии приложения ведут себя по-разному.

Простой способ проверить это - проверить предупреждения вашего компилятора.
Убедитесь, , что все переменные инициализированы передиспользовать (это будет в предупреждениях).

Answer 4

Чтобы узнать об оптимизации компилятора, одним из простых ресурсов может быть Википедия.Это вкратце объясняет некоторые важные и широко реализованные оптимизации почти всеми современными компиляторами.

Возможно, вы хотели бы сначала прочитать статью в вики, особенно эти разделы:

• Типы оптимизаций
• Конкретныетехника