LLVM jit и native
Я не понимаю, как LLVM JIT относится к обычной компиляции без JIT, и документация не очень хорошая.
Например, предположим, что я использую интерфейс clang :
- Случай 1: Я компилирую файл C в нативный с помощью clang / llvm. Этот поток, который я понимаю, похож на поток gcc - я получаю свой исполняемый файл x86, который запускается.
- Случай 2: я компилирую в некий LLVM IR, который работает на LLVM JIT. В этом случае исполняемый файл содержит среду выполнения LLVM для выполнения IR на JIT или как он работает?
В чем разница между этими двумя и правильны ли они? Включает ли поток LLVM поддержку как JIT, так и не JIT? Когда я хочу использовать JIT - имеет ли смысл для такого языка, как C?
2 ответа
Вы должны понимать, что LLVM - это библиотека, которая помогает вам создавать компиляторы. Clang - это просто интерфейс для этой библиотеки.
Clang переводит код C / C ++ в LLVM IR и передает его LLVM, которая компилирует его в собственный код.
LLVM также может генерировать собственный код непосредственно в памяти, который затем может быть вызван как обычная функция. Итак, случаи 1 и 2 разделяют оптимизацию и генерацию кода LLVM.
Так как же использовать LLVM в качестве JIT-компилятора? Вы создаете приложение, которое генерирует некоторый LLVM IR (в памяти), а затем используете библиотеку LLVM для генерации собственного кода (все еще в памяти). LLVM возвращает вам указатель, который вы можете вызвать впоследствии. Никакого лязга.
Однако вы можете использовать clang для трансляции некоторого кода C в LLVM IR и загрузки его в свой JIT-контекст для использования функций.
Примеры из реального мира:
- Unladen Swallow Python VM
- Rubinius Ruby VM
Существует также руководство Kaleidoscope , в котором показано, как реализовать простой язык с JIT-компилятор.
Большинство компиляторов имеют внешний интерфейс, некоторый средний код / структуру некоторого вида и внутреннюю часть. Когда вы берете свою программу C и используете clang и компилируете так, что в итоге вы получаете программу x86 без JIT, которую вы можете просто запустить, вы все равно перешли от внешнего интерфейса к среднему к бэкэнду.То же самое и с gcc, gcc переходит от внешнего интерфейса к среднему и бэкэнду. Середина Gccs не является широко открытой и удобной, как LLVM.
Одна вещь, которая забавна / интересна в llvm, которую вы не можете делать с другими или, по крайней мере, с gcc, - это то, что вы можете взять все свои модули исходного кода, скомпилировать их в байт-код llvms, объединить их в один большой байт-код. файл, а затем оптимизируйте все это, вместо оптимизации для каждого файла или функции, которую вы получаете с другими компиляторами, с llvm вы можете получить любой уровень частичной оптимизации программы для компиляции, какой вам нравится. затем вы можете взять этот байт-код и использовать llc для его экспорта в целевой ассемблер. Обычно я использую встроенный, поэтому у меня есть собственный код запуска, который я оборачиваю вокруг него, но теоретически вы должны иметь возможность взять этот файл ассемблера и с помощью компиляции gcc, связать его и запустить. gcc myfile.s -o myfile. Я полагаю, что есть способ получить для этого инструменты llvm и не использовать binutils или gcc, но я не нашел времени.
Мне нравится llvm, потому что это всегда кросс-компилятор, в отличие от gcc, вам не нужно компилировать новый для каждой цели и разбираться с нюансами для каждой цели. Я не знаю, что я могу использовать JIT, я говорю, что использую его как кросс-компилятор и как собственный компилятор.
Итак, ваш первый случай - это начало, середина, конец, и процесс скрыт от вас, вы начинаете с исходного кода и получаете двоичный файл, готово. Второй случай, если я правильно понимаю перед и середину и остановлюсь на каком-нибудь файле, который представляет середину. Тогда промежуточный этап (конкретный целевой процессор) может произойти точно во время выполнения.Разница в том, что бэкэнд, выполнение среднего языка в случае два в реальном времени, вероятно, отличается от бэкэнда в первом случае.