Inlining — замена вызова функции её телом во время компиляции. Зачем и как:
- Устраняет накладные расходы на вызов (push/ret, аргументы), даёт доступ к телу функции из контекста вызывающего, что позволяет дальнейшие оптимизации (константное распространение, DCE, рекламацию регистров).
- Решение по инлайнингу принимается эвристикой/моделью стоимости: оценивается размер функции, частота вызова, выгода (например, если размер > порога $...$) и риск раздувания кода (code bloat). Компиляторы выполняют inlining на уровне IR (LLVM IR, GCC GIMPLE), иногда в рамках LTO для межмодульного инлайнинга.
- Побочные эффекты: увеличивает размер бинаря, может улучшить или ухудшить локальность инструкций; открывает возможности для DCE и константной свертки.
Dead code elimination (DCE) — удаление кода, не влияющего на наблюдаемые эффекты программы:
- Удаляет недостижимые блоки (unreachable code) и вычисления, чей результат не используется и не имеет побочных эффектов.
- Работает на графе потока управления/зависимостей и на основе понятия "observables" (ввод/вывод, volatile, системные вызовы, и т. п.). Также применяется value-based DCE: если значение никогда читается, удаляется его вычисление.
- Взаимодействие с UB: если код содержит неопределённое поведение, компилятор может предположить, что UB не случается, и поэтому удалить проверки или вычисления, которые единственным образом предотвращали UB.
Auto-vectorization — автоматическое преобразование подходящих циклов в SIMD-инструкции:
- Анализирует циклы на наличие зависимостей (data dependence analysis). Если итерации независимы или зависимости допускают перераспределение, компилятор может разбить цикл на пакеты шириной в вектор $W$ (например, $W=4$ для 4 float в SSE) и сгенерировать векторные инструкции + хвостовой (remainder) цикл.
- Потребные трансформации: выравнивание данных (alignment), пропуск зависимостей по индексам, преобразование памяти в регистры (scalar replacement), распаковка/упаковка при обращениях к структурам.
- Ограничения: точность вычислений (порядок операций меняется — поведение с плавающей точкой может отличаться из‑за неассоциативности); требования к отсутствию побочных эффектов между итерациями; target‑зависимость (разные инструкции для AVX/SVE и т. д.). Флаги компилятора (например, агрессивные оптимизации для FP: -ffast-math) позволяют расширить набор разрешённых преобразований.
Пример C‑кода с неопределённым поведением, которое делает оптимизацию «изменяющей семантику»:
#include #include
int f(int x) {
if (x + 1 > x)
return 1;
else
return 0;
}
int main(void) {
int a = INT_MAX; // INT_MAX == 2^31 - 1 для 32‑бит int
printf("%d\n", f(a));
return 0;
}
Почему оптимизация может изменить семантику:
- В стандарте C знакованное целочисленное переполнение является неопределённым поведением (UB). При выражении $(x+1)$ компилятор вправе предположить, что переполнение никогда не происходит.
- Следовательно условие $(x+1>x)$ компилятор может упростить до постоянно истинного и превратить $\text{f}$ в функцию, возвращающую всегда \(\(1\)\). Это позволяет, например, DCE/константное сворачивание убрать ветвление.
- На реальном железе с двоичным дополняющим представлением без проверки переполнения значение $\text{INT\_MAX}+1$ реально оборачивается в $\text{INT\_MIN}$, и условие будет ложно; без оптимизаций программа может напечатать \(\(0\)\). Но т.к. стандарт считает такое поведение UB, оптимизирующий компилятор имеет право выдать поведение, отличное от оборачивания, — семантика программы меняется при оптимизации.
- Аналогичные эффекты дают и другие UB (нарушение strict aliasing, доступ вне границ массива, использование неинициализированной памяти): компилятор может реорганизовать/удалить код, исходя из предположения, что UB не происходит.
Коротко: оптимизации (inlining, DCE, авто‑векторизация) опираются на предположения о корректности исходного кода; если код содержит UB, компилятор может безопасно (по стандарту) выполнить трансформации, которые изменят наблюдаемое поведение программы на реальном оборудовании.