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

Каковы последствия для

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

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

Это звучит

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

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