Использование llvm-link перед компиляцией - PullRequest
1 голос
/ 20 марта 2019

Я провел небольшой эксперимент, чтобы выяснить, будет ли Clang генерировать лучший код, если я скомпилирую кучу фиктивных исходных файлов C в один файл битового кода LLVM (сначала используя -emit-llvm для компиляции в .bc файлы, а затем используя llvm-link, чтобы заключить их в один .bc файл) перед компиляцией в фиктивную библиотеку, в отличие от обычной компиляции для отдельных объектных файлов, которые должны быть связаны, и, кажется, он способен выполнять некоторые WPO (целые оптимизации программы), такие как вставка функционирует в разных единицах перевода, чего не было бы в противном случае. Я знаю о LTO (оптимизация времени соединения) через -flto, так что это мой маленький эксперимент, чтобы увидеть, как Clang будет вести себя по-разному в этом конкретном случае.

Мой вопрос, однако, целесообразно ли вообще создавать двоичные файлы таким образом? Отличается ли конечный результат от простого использования -flto? Если так, что будет отличаться, будь то с точки зрения процесса или конечного результата? Если нет, то это просто более хитрый способ вызова LTO?

1 Ответ

1 голос
/ 20 марта 2019

Если нет, то это просто более искусный способ вызова LTO?

В основном да.

Отличается ли конечный результат от простого использования -flto

Ну, я думаю, что будут некоторые различия, но они не должны иметь никакого значения. Когда компоновщик с поддержкой LTO связывает байт-код и выполняет этапы оптимизации, он использует конвейер PassManagerBuilder::addLTOOptimizationPasses из lib/Transforms/IPO/PassManagerBuilder.cpp. А когда вы оптимизируете код, созданный llvm-link, инструмент opt использует PassManagerBuilder::populateModulePassManager, что явно отличается. Трудно сказать, какие именно различия будут, но, скорее всего, это будет вопрос, что некоторые проходы будут проходить дважды в случае llvm-link+opt.

...