Я посмотрел исходный код clang, llc и немного позже, чтобы посмотреть, как каждый из них добавляет оптимизацию в конвейер. Мое понимание заключалось в том, что clang добавляет те же самые оптимизации, которые opt и llc имеют в своих конвейерах, вызывая те же методы, что и opt и llc call. Также clang отдельно не вызывает opt и/или llc.Отношения между clang, opt, llc и llvm-linker
Это почти нормально, за исключением того, что существует риск, что в какой-то момент opt может закончиться различными оптимизациями в своем конвейере (по сравнению с clang) из-за изменений источника, которые выполняются в одном, но не в другом. То же самое верно для сравнения llc и clang. Правильно ли это восприятие?
Также я видел диаграммы, которые показывают следующий рабочий процесс: clang, opt, llvm-linker, opt again (для IPA?), Затем llc. Я не могу подключить этот рабочий процесс к тому, что я видел в clang. Даже мое понимание LTO заключается в том, что компоновщик (Say gold) вызовет оптимизацию. Здесь я не могу понять роль llvm-linker.
Любые идеи очень ценятся.
Спасибо. Не могли бы вы дать больше комментариев о том, что является точкой llvm-linker? Мой самый большой вопрос в том, что это эквивалент системного линкера? – esam
Другой вопрос: Считаете ли вы, что существует риск того, что оптимизация в opt и clang перестает синхронизироваться, потому что изменение кода на одном из них не отражается в другом? – esam
Всё зависит от меня. Существует llvm-link, которая должна связывать файлы биткода вместе и lld, что является попыткой заменить системные компоновщики, похожие на то, как clang заменяет системные компиляторы. – echristo