Использование байт-кода LLVM для библиотек (вместо собственных объектных файлов) - PullRequest
Новая
       25

Использование байт-кода LLVM для библиотек (вместо собственных объектных файлов)

5 голосов
/ 18 февраля 2012

Какое значение имеет

  • переносимость (соглашение о вызовах: действительно ли это имеет значение на уровне LLVM при вызове только функций библиотеки C или OS)
  • время ссылки
  • оптимизации

Я хотел бы скомпилировать игрушечный язык с LLVM, поскольку все уже присутствующие сложные компоненты (оптимизация, генерация объектного кода), но я борюсь с концепцией, которую я хотел бы сохранить, если она того стоит: библиотека файлы должны распространяться, использоваться как статическая и совместно используемая библиотека (для компоновки, в общем случае будет сгенерировано действительное so или dll при связывании конечного приложения), portable . Я считаю, что это сократит часть времени компиляции (поскольку генерация собственного кода и, возможно, оптимизация выполняются только один раз, во время окончательного двоичного соединения). Я предполагаю, что компоновщик позаботится о соглашении о вызовах (если возможно) и преобразовании в разделяемую библиотеку по запросу. В далеко растянутом добавлении, возможно, LLVM можно использовать для связи , а не , и использовать JL LLVM для непосредственного запуска сгенерированного байт-кода, полностью устраняя время ссылки при написании кода.

Это звучит

  1. выполнимо?
  2. Стоит ли это? Я знаю, что время ссылки C / C ++ сравнительно велико, что проблематично при частой перестройке. Как насчет оптимизации времени свободной ссылки (cfr /GL и -flto, поскольку это будет по существу байт-код LLVM, который будет связан вместе, который затем будет преобразован в собственный двоичный файл).

Это может быть неопределенный вопрос, если мне нужно что-то уточнить, пожалуйста, спросите.

1 Ответ

8 голосов
/ 18 февраля 2012

Я делал нечто подобное в прошлом.Вы должны понимать, что битовый код LLVM не является «переносимым» в том смысле, что он не является полностью независимым от машины.Файлы битовых кодов знают такие вещи, как размер указателей и т. Д., Которые зависят от целевого процессора.

Сказав, что в прошлом я компилировал программы и их библиотеки поддержки для битового кода и связывал битовый кодфайлы вместе, прежде чем создавать файл сборки для всей программы.Вы правы в том, что соглашения о вызовах не важны для внутренних вызовов, но для вызовов, совершаемых снаружи (или снаружи), все еще требуется соблюдение ABI.

Возможно, вы сможете разработать свой игрушечный язык таким образомтаким образом, вы можете избежать зависящего от процессора битового кода, но вам нужно быть очень осторожным.

Я заметил, что объединение файлов битового кода заняло довольно много времени, особенно на высоких уровнях оптимизации.Возможно, это ускорилось, я сделал это с LLVM 2 или 3 года назад.

И последнее замечание: в зависимости от целевого процессора вам, вероятно, понадобится эквивалент libgcc.a или compiler-rt.обрабатывать вещи, которые процессору не нравятся с плавающей запятой или 64-битным целым, если у процессора нет инструкций, выполняющих эти операции.

...