Comments 45
Можно для тех, кто не понял про LLVM, прочитав даже википедию. Что такое LLVM?
* Это компилятор разных языков в специальные команды VM?
* Скомпилированный код потом исполняется в VM? Типа JVM или .NET.
* Я могу получить нативный бинарник под платформу, чтобы не использовалась VM?
* Это компилятор разных языков в специальные команды VM?
* Скомпилированный код потом исполняется в VM? Типа JVM или .NET.
* Я могу получить нативный бинарник под платформу, чтобы не использовалась VM?
В вики чётко написано, он процессит код в свою внутреннюю вм, для которой есть jit а есть нативный компилятор. Причём нативный компилятор очень хорош. Причём из внутреннего представления можно преобразовать код в какой нибудь другой язык, что позволят при помощи llvm транслировать программы из одного языка в другой.
>> Причём нативный компилятор очень хорош.
Чем хорош? Быстрее код? Лучше предсказание ошибок? Быстрее компилирует на порядок?
>> что позволят при помощи llvm транслировать программы из одного языка в другой.
Но наверное в очень корявый код на другом языке?
Чем хорош? Быстрее код? Лучше предсказание ошибок? Быстрее компилирует на порядок?
>> что позволят при помощи llvm транслировать программы из одного языка в другой.
Но наверное в очень корявый код на другом языке?
Прочитайте уже эту стать и статью в википедии. Всем хорош.
>> Но наверное в очень корявый код на другом языке?
А вы его что сами собрались интерпретировать? Конечно корявый, но засуньте его в отдельную либу и не смотрите на него.
>> Но наверное в очень корявый код на другом языке?
А вы его что сами собрались интерпретировать? Конечно корявый, но засуньте его в отдельную либу и не смотрите на него.
habrahabr.ru/post/143583/ вот например плюсовую либу на js портанули.
>Чем хорош? Быстрее код? Лучше предсказание ошибок? Быстрее компилирует на порядок?
Компилирует быстрее. Диагностика ошибок хорошая.
На счёт производительности полученого кода — тут по разному. Они не сильно уступают gcc, где-то обгоняют. Единственное, что IMHO у них как-то не очень с производительностью FP кода.
Компилирует быстрее. Диагностика ошибок хорошая.
На счёт производительности полученого кода — тут по разному. Они не сильно уступают gcc, где-то обгоняют. Единственное, что IMHO у них как-то не очень с производительностью FP кода.
С удовольствием объясню :)
LLVM — это целый набор компиляторных и около компиляторных тулов построеных на модульной основе. Все инструменты построены вокруг единого внутреннего представления, называемого биткодом. Это представление едино для разных платформ и стадий компиляции (начиная с выхода фронтэнда и заканчивая кодогенератором для конкретной платформы). На этом внутреннем представлении оперируют множество оптимизаций и трансформаций (тот же AddressSanitizer инструментирует биткод), которые платформенно независимы (ну или как минимум стараются быть платформонезависимыми).
Как это выглядит снаружи? Есть Clang — классический компилятор языков C/C++/Objective C. Берёт исходник и генерирует обычный бинарий. Есть отдельно виртуальная машина (vmkit), которая использует то же внутреннее представление для исполнения .Net и Java. Есть также LLVM JIT, который исполняет внутренне представление без прямой генерации бинариев.
Так что общий ответ простой — есть и обычный компилятор, и JIT.
LLVM — это целый набор компиляторных и около компиляторных тулов построеных на модульной основе. Все инструменты построены вокруг единого внутреннего представления, называемого биткодом. Это представление едино для разных платформ и стадий компиляции (начиная с выхода фронтэнда и заканчивая кодогенератором для конкретной платформы). На этом внутреннем представлении оперируют множество оптимизаций и трансформаций (тот же AddressSanitizer инструментирует биткод), которые платформенно независимы (ну или как минимум стараются быть платформонезависимыми).
Как это выглядит снаружи? Есть Clang — классический компилятор языков C/C++/Objective C. Берёт исходник и генерирует обычный бинарий. Есть отдельно виртуальная машина (vmkit), которая использует то же внутреннее представление для исполнения .Net и Java. Есть также LLVM JIT, который исполняет внутренне представление без прямой генерации бинариев.
Так что общий ответ простой — есть и обычный компилятор, и JIT.
Самое лучшее объяснение! Лаконично и по сути!
Всегда думал, что понимаю устройство LLVM, теперь точно запутался. Какой инструмент из toolchain'а LLVM позволяет IR компилировать в исполняемый файл (под ту или иную архитектуру)?
llc
Ок, тут недавно пробегала статья, про RubyMotion. Проект реализует поддержку Ruby в инфраструктуре LLVM за счет чего позволяет писать приложения на Ruby и компилировать их в mach-o под ARMv7 (насколько я понял). Расскажите как это реализовано, пожалуйста. Какие элементы toolchain'а LLVM автору пришлось написать для реализации подобного (дикого) трюка. Тут же явно не используется LLC (чьи возможности в плане поддерживаемых архитектур оставляют желать лучшего).
>Тут же явно не используется LLC (чьи возможности в плане поддерживаемых архитектур оставляют желать лучшего)
Что значит оставляют желать лучшего? Он как раз поддерживает все архитектуры, которые заявлены в LLVM.
[ушёл читать статью про RubyMotion]
Что значит оставляют желать лучшего? Он как раз поддерживает все архитектуры, которые заявлены в LLVM.
[ушёл читать статью про RubyMotion]
Походу про LLC я поторопился (судя по всему наткнулся на старую документацию). Backend'ов изначально у LLVM заложено как надо (есть поддержка ARM и не только). В любом случае, если бы вы рассказали про то, как устроено у RubyMotion — было бы крайне позитивно.
Простите, что так много вопросов, тема крайне интересная. Верно ли утверждение, что с помощью LLVM/LLC можно делать кросскомпиляцию? Допустим, собирать Mach-O ARMv7 на Windows под x86?
Вопросы — это всегда хорошо :)
Утверждение верно, делать кросскомпиляцию можно. Зуб на отсечение, как говорится, не дам, так как сам лично такого эксперимента не делал. Но вообще такая фича поддерживается. При сборке llvm надо просто configure нужные флажки подать чтобы определить кто хост, а кто таргет.
Но вообще, лично я бы кроскомпилятор использовал бы только для экспериментов и повседневной разработки, но не для продуктовых билдов. Как у компиляторщика, предубеждения у меня есть некоторые против кросскомпиляторов (не относящиейся конкретно к llvm)
Утверждение верно, делать кросскомпиляцию можно. Зуб на отсечение, как говорится, не дам, так как сам лично такого эксперимента не делал. Но вообще такая фича поддерживается. При сборке llvm надо просто configure нужные флажки подать чтобы определить кто хост, а кто таргет.
Но вообще, лично я бы кроскомпилятор использовал бы только для экспериментов и повседневной разработки, но не для продуктовых билдов. Как у компиляторщика, предубеждения у меня есть некоторые против кросскомпиляторов (не относящиейся конкретно к llvm)
LLVM и Clang по своей сути — кросс-компиляторы и им абсолютно всё равно какой хост.
Если есть какие-то глобальные вопросы — можно задавать тут в коментах. Если будет настроение, может более развёрнутую статью напишу, знать бы только что людям интересно.
Дополню:
CLANG — это Front-end, который переводит C/C++/Objective C (теперь ещё и CUDA) в IR представление, далее при помощи backend данное представление трансформируется в конечный вариант.
На самом деле можно и GCC (версии 4.5 и выше) заставить генерить IR представление, используя плагин dragonegg. Это полезно, когда надо задействовать, например Fortran.
Для особо ленивых программистов есть CLOOG — который позволяет оптимизировать циклы в случае многопоточных приложений (средствами OpenMP).
CLANG — это Front-end, который переводит C/C++/Objective C (теперь ещё и CUDA) в IR представление, далее при помощи backend данное представление трансформируется в конечный вариант.
На самом деле можно и GCC (версии 4.5 и выше) заставить генерить IR представление, используя плагин dragonegg. Это полезно, когда надо задействовать, например Fortran.
Для особо ленивых программистов есть CLOOG — который позволяет оптимизировать циклы в случае многопоточных приложений (средствами OpenMP).
Господа, а я где-то около подьезда у бабок слашал, что с помошью сабжа можно свой компилятор забабахать? Точнее, нужно то что, нужно — чтобы из псевдо-си/паскакаль языка выдавала ассемблерные команды для, внимание, выдуманного процессора. Можно такое здесь или мне надо капитально протрезветь?
Да, можно. Вот цитата:
llvm.org/docs/LangRef.html:
>>This allows LLVM to provide a powerful intermediate representation for efficient compiler transformations and analysis, while providing a natural means to debug and visualize the transformations.
По сути вы из свего мега-супер-си-езыг перегоняете в LLVM IR.
llvm.org/docs/LangRef.html:
>>This allows LLVM to provide a powerful intermediate representation for efficient compiler transformations and analysis, while providing a natural means to debug and visualize the transformations.
По сути вы из свего мега-супер-си-езыг перегоняете в LLVM IR.
Так и есть, это хороший инструментарий для оптимизатора — бэкенда компилятора.
Да. Нужно транслировать конструкции своего языка в промежуточное прдеставление LLVM. Как это делается легко понять скачав LLVM — там к нему в комплекте есть несоклько вполне читабельных примеров по написанию компилятора собственного языка программирования.
>>а я где-то около подьезда у бабок слашал
Вы точно из России? Может эти «бабки» жены Дениса Ричи и Кена Томпсона? Я к тому что у нас таких продвинутых бабок очень мало
Вы точно из России? Может эти «бабки» жены Дениса Ричи и Кена Томпсона? Я к тому что у нас таких продвинутых бабок очень мало
Только не говорите про DCPU-16!
А почему он уже как пару недель в новом Xcode?
Или то немного другая, «личная» версия Apple?
Или то немного другая, «личная» версия Apple?
Точно не знаю. Релиз был запланирован на 14 мая и в SVN (http://llvm.org/svn/llvm-project/llvm/tags/RELEASE_31/final) он появился по графику, возможно просто тормозили с Release Notes, может ещё какие формальности.
Это внутренние «маркетинговые» версии Apple. Которые ничего не имеют общего с версиями с llvm.org. Apple LLVM Compiler != clang / llvm с llvm.org. Apple LLVM Compiler 3.1 — это версия где-то «посредине» LLVM 3.0 и 3.1.
А для Visual Studio нет ли случайно плагина, подключающего к студии LLVM?
LLVM/Clang можно собрать на винде и более или менее успешно использовать. Правда, стоит всё-таки сказать, что винда — отнюдь не первоочередная платформа для LLVM разработчиков и там много нет. Но, например, Chromium можно собрать клангом на винде.
Вот тут есть инструкции по сборке clang под Visual Studio.
Как воткнуть в VS плагином — не знаю.
Вот тут есть инструкции по сборке clang под Visual Studio.
Как воткнуть в VS плагином — не знаю.
Как воткнуть в VS плагином — не знаю.
Для десятой студии есть вот такой плагин: github.com/ishani/ClangVSx
LLVM/Clang 3.1 уже доступен в качестве системного компилятора в FreeBSD 9-STABLE и 10-CURRENT. В перспективе заменит собой GCC 4.2.1 в базовой системе. Но уже сейчас можно сделать его таковым, пересобрав систему с опциями в /etc/src.conf:
WITH_CLANG=true
WITH_CLANG_IS_CC=true
После установки пересобранной системы получим:
% cc --version
FreeBSD clang version 3.1 (branches/release_31 156863) 20120523
Target: x86_64-unknown-freebsd9.0
Thread model: posix
GCC 4.2.1 будет доступен по пути:
% /usr/bin/gcc --version
gcc (GCC) 4.2.1 20070831 patched [FreeBSD]
Copyright © 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
WITH_CLANG=true
WITH_CLANG_IS_CC=true
После установки пересобранной системы получим:
% cc --version
FreeBSD clang version 3.1 (branches/release_31 156863) 20120523
Target: x86_64-unknown-freebsd9.0
Thread model: posix
GCC 4.2.1 будет доступен по пути:
% /usr/bin/gcc --version
gcc (GCC) 4.2.1 20070831 patched [FreeBSD]
Copyright © 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Всё верно, но пока ещё он не системый компилятор по умолчанию, а кандидат в системные компиляторы по умолчанию. Хотя в недалёком будущем это должно случиться. И это хорошо.
Опция WITHOUT_GCC=true в /etc/src.conf после выполнения процедуры очистки:
cd /usr/src/ && make BATCH_DELETE_OLD_FILES=true delete-old delete-old-libs
выбросит gcc и g++ из базовой системы и останется одна система сборки — LLVM/Clang.
Кстати, последней версией Clang, интегрированного в базовую систему FreeBSD, собираются много приложений из коллекции портов и даже последние версии GCC 4.5-4.8, если последние нужны для сборки какой-то программы, не подлежащей сборке GCC 4.2.
cd /usr/src/ && make BATCH_DELETE_OLD_FILES=true delete-old delete-old-libs
выбросит gcc и g++ из базовой системы и останется одна система сборки — LLVM/Clang.
Кстати, последней версией Clang, интегрированного в базовую систему FreeBSD, собираются много приложений из коллекции портов и даже последние версии GCC 4.5-4.8, если последние нужны для сборки какой-то программы, не подлежащей сборке GCC 4.2.
Да, но речь о том, что идёт включённым по умолчанию. Пока они считают, что всё-таки не достигли продуктового качества и предлагают clang для экспериментов. Нужно время чтобы выловить все косяки и заточки на gcc.
Возможности FreeBSD -STABLE и не предлагаются в качестве готового решения. Вот выйдет очередной релиз, тогда это будет штатная возможность. Сейчас идёт обкатка и стабилизация кодовой базы LLVM/Clang 3.1 и полностью тестирование будет завершено к середине июля 2012 года, как сказано в пресс-релизе о завершении портирования. После этого начнётся выдавливание GCC 4.2.1 из базовой системы навсегда и переход, где это нужно, на GCC 4.6 из коллекции портов для сборки «проблемных портов».
С другой стороны, уже сейчас использование LLVM/Clang 3.1 для сборки программ даёт основания считать его более строгим компилятором, не прощающим ошибок несовсем организованным программистам. Чем больше багрепортов будет отправлено на замеченные косяки и невозможности сборки Clang'ом программ, тем быстрее авторы таких программ приведут их код в надлежащее состояние.
С другой стороны, уже сейчас использование LLVM/Clang 3.1 для сборки программ даёт основания считать его более строгим компилятором, не прощающим ошибок несовсем организованным программистам. Чем больше багрепортов будет отправлено на замеченные косяки и невозможности сборки Clang'ом программ, тем быстрее авторы таких программ приведут их код в надлежащее состояние.
Sign up to leave a comment.
Состоялся релиз LLVM 3.1