Как оптимизация компилятора может повлиять на логику кода?
Когда тот же кусок кода скомпилирован с оптимизацией полностью отключен (g++ -O0), а затем снова с полностью включенными оптимизациями (g++ -O3Как можно изменить логику самого исходного кода?
Например, компиляторы могут
- размотать петли а также
- делать постоянное складывание.
Эти две оптимизации заставляют код работать быстрее, не затрагивая целостность исходного исходного кода. Любой код, который выполняется без этих оптимизаций, будет работать с их включенным.
Но оптимизация компилятора также может влиять на логику кода. Вот два примера, которые я знаю:
- Удаление конструкторов копирования и операторов присваивания Из временных может удалить возможные побочные эффекты.
- Изменение арифметики, содержащей значения с плавающей запятой, может повлиять на ошибку с плавающей запятой (возможно, требует
-ffast-mathаргумент).
Я был очень удивлен, и мне повезло, что я узнал об этом, потому что они могут стать огромным потенциальным хитом в неправильной ситуации.
Итак, я хочу знать, есть ли другие случаи, когда оптимизация компилятора c ++ повлияет на логику кода? Я специально ищу информацию о c ++ 11 (без какого-либо неопределенного поведения) в компиляторе g ++, но советы для других компиляторов приветствуются.
Решение
Правило «как будто»:
Реализация свободна игнорировать любое требование этого
Международный стандарт до тех пор, пока результат, как если бы требование
был послушен, насколько это можно определить из наблюдаемого
поведение программы. Например, фактическая потребность в реализации
не оценивать часть выражения, если оно может сделать вывод, что его значение
не используется и что никаких побочных эффектов, влияющих на наблюдаемое поведение
программа производится.
Однако в стандарте упоминается одна оптимизация, которая разрешена и которая нарушает правило «как будто»:
Когда определенные критерии выполнены, реализация может быть опущена
конструкция копирования / перемещения объекта класса, даже если копирование / перемещение
Конструктор и / или деструктор для объекта имеют побочные эффекты. В
В таких случаях реализация рассматривает источник и цель
опущена операция копирования / перемещения просто как два разных способа обращения
к тому же объекту, и разрушение этого объекта происходит на
позднее, когда два объекта были бы уничтожены
без оптимизации.123 Это исключение операций копирования / перемещения,
называется копия разрешения, допускается при следующих обстоятельствах
(которые могут быть объединены для устранения нескольких копий):— в ответ
оператор в функции с типом возвращаемого класса, когда выражение
имя энергонезависимого автоматического объекта (кроме функции
или параметр catch-clause) с тем же типом cvunqualified, что и
Тип возврата функции, операция копирования / перемещения может быть опущена
построение автоматического объекта непосредственно в возвращении функции
значение— в выражении броска, когда операндом является имя
энергонезависимый автоматический объект (кроме функции или предложения catch)
параметр), область которого не выходит за пределы самого внутреннего
включающий блок try (если он есть), операция копирования / перемещения из
операнд объекта исключения (15.1) может быть опущен
построение автоматического объекта непосредственно в объекте исключения—
когда временный объект класса, который не был связан со ссылкой
(12.2) будет скопирован / перемещен в объект класса с тем же
cv-unqualified type, операция копирования / перемещения может быть опущена
строительство временного объекта непосредственно в цель
опущено копирование / перемещение— когда объявление об исключении
Обработчик (раздел 15) объявляет объект того же типа (за исключением
cv-qualification) как объект исключения (15.1), копирование / перемещение
Операция может быть опущена, обрабатывая объявление исключения как
псевдоним для объекта исключения, если значение программы будет
без изменений, за исключением выполнения конструкторов и деструкторов для
объект, объявленный объявлением исключения.
Другие решения
«Неопределенное поведение» — это поведение, при котором реализация может свободно выбирать любое из возможных вариантов поведения. В таких случаях оптимизатор может повлиять на сделанный выбор.
Простой пример — порядок, в котором оцениваются аргументы функции. Неоптимизированные сборки могут использовать слева направо или справа налево, тогда как оптимизированные сборки могут оценивать аргументы в «смешанном» порядке. Хорошей причиной было бы максимизировать возможность оптимизации общего выражения выражений среди аргументов.
Если какой-либо из этих аргументов имеет заметные побочные эффекты, логика кода будет изменена, но зависит ли это от ошибки, от случая к случаю.