Использование инлайнера уровня модуля LLVM ModuleInlinerWrapperPass

Question

Из чтения исходного кода LLVM в lib/Transforms/IPO/Inliner.cpp я обнаружил, что LLVM разработал фактический проход инлайнера как проход CGS CC, а затем есть ModuleInlinerWrapperPass, который оборачивается вокруг прохода CGS CC для выполнения -module inlining.

Заглянув внутрь PassBuilder.cpp, я обнаружил, что этап оболочки встроенного модуля на уровне модуля обычно также выполняется на этапе P GO -instrumentation (как часть конвейера addPGOInstrPipeline). как этап LTO.

Меня интересовали различия между проходом CGS CC и проходом на уровне модуля и тем, который запланирован ранее, поэтому я добавил несколько операторов LLVM_DEBUG для печати из инициализатора проход на уровне модуля. похоже, что по умолчанию opt -O2 не запускает инлайнер на уровне модуля; вместо этого он запускает проход CGS CC довольно рано в конвейере оптимизации.

Мой вопрос: когда проход встроенного модуля уровня модуля выполняется в конвейере оптимизации (если вообще), и каковы его отношения с пропуском-вкладышем CGS CC?

Answer 1

Этот вопрос сводится к разнице между новым PassManager и старым PassManager в LLVM.

По сути, есть два способа написать проход: либо мы можем использовать новый PassManager (с расширением классов проходов PassInfoMixin<...>) или используйте устаревший PassManager (с классами проходов, расширяющими ModulePass / CGSCCPass / FunctionPass ...).

Новый PassManager использует класс PassBuilder для планирования проходов в конвейеры и затем запустите конвейер в запланированной последовательности. ModuleInlinerWrapperPass - это, по сути, проход-оболочка на уровне модуля, чтобы новый PassManager мог запланировать инлайнер в существующий конвейер оптимизации на уровне модуля.