Состоялся релиз LLVM 3.1

    22 мая состоялся релиз LLVM 3.1, семейства компиляторных инструментов, построенных на модульной основе. Проект активно развивается как альтернатива GCC такими компаниями, как Apple и Google.

    Наиболее заметные изменения включают в себя улучшенную поддержку нового стандарта C++'11 Clang'ом (включая лямбды, списки инициализации, константные выражения, пользовательские литералы и атомики); появление AddressSanitizer — инструмента для динамического отлова ошибок работы с памятью; серьёзные улучшения времени компиляции и появление новых фич для ARM архитектуры; заметно улучшенная поддержка архитектуры MIPS (включая MIPS64).
    image

    Для тех, кому интересны подробности — добро пожаловать под кат.

    Напомню, что главный инструмент LLVM — это Clang, «родной» для платформы Mac компилятор языков C / C++ / Objective C. Компилятор также доступен на других основных платформах — Linux и Windows. Правда, поддержка Windows до сих пор носит экспериментальный характер. Этот компилятор выгодно отличается от конкурентов скоростью работы и мощной и точной диагностикой ошибок. Для тех, кто ищет альтернативу GCC, но не хочет отказываться от open-source продуктов, новый релиз — это отличный повод попробовать этот компилятор.

    Наверно, главной интересной фичей в LLVM 3.1 является появление AddressSanitizer среди стандартных тулов — инструмента для динамического поиска ошибок работы с памятью. Этот инструмент, рождённый в недрах Гугла, позволяет поймать переполнения буфера (в куче, на стеке, в глобалах) и use-after-free ошибки, при относительно небольшом замедлении исполнения (порядка двух раз). Это очень хороший довесок к уже существующему инструменту статической верификации кода Clang Static Analyzer.

    LLVM 3.1 также включает в себя DragonEgg — GCC plug-in, подменяющий gcc оптимизатор кодогенератором LLVM. Новый релиз полностью поддерживает GCC 4.5 и 4.6 и частично только что вышедший 4.7. Полностью поддерживаются языки Ada, C, C++ и Fortran, частично Go, Java, Obj-C и Obj-C++. Как мы видим, хоть GCC фронтэнд и перестал быть основным для LLVM, этот подпроект продолжает активно развиваться.

    Полный список изменений можно найти в release notes. А попробовать компилятор — скачав его в бинариях или сорсах с сайта проекта.
    Поделиться публикацией

    Похожие публикации

    Комментарии 45
      +5
      Можно для тех, кто не понял про LLVM, прочитав даже википедию. Что такое LLVM?
      * Это компилятор разных языков в специальные команды VM?
      * Скомпилированный код потом исполняется в VM? Типа JVM или .NET.
      * Я могу получить нативный бинарник под платформу, чтобы не использовалась VM?
        +3
        В вики чётко написано, он процессит код в свою внутреннюю вм, для которой есть jit а есть нативный компилятор. Причём нативный компилятор очень хорош. Причём из внутреннего представления можно преобразовать код в какой нибудь другой язык, что позволят при помощи llvm транслировать программы из одного языка в другой.
          0
          >> Причём нативный компилятор очень хорош.
          Чем хорош? Быстрее код? Лучше предсказание ошибок? Быстрее компилирует на порядок?

          >> что позволят при помощи llvm транслировать программы из одного языка в другой.
          Но наверное в очень корявый код на другом языке?
            0
            Прочитайте уже эту стать и статью в википедии. Всем хорош.
            >> Но наверное в очень корявый код на другом языке?
            А вы его что сами собрались интерпретировать? Конечно корявый, но засуньте его в отдельную либу и не смотрите на него.
              +1
              habrahabr.ru/post/143583/ вот например плюсовую либу на js портанули.
                +4
                >Чем хорош? Быстрее код? Лучше предсказание ошибок? Быстрее компилирует на порядок?
                Компилирует быстрее. Диагностика ошибок хорошая.

                На счёт производительности полученого кода — тут по разному. Они не сильно уступают gcc, где-то обгоняют. Единственное, что IMHO у них как-то не очень с производительностью FP кода.
              +20
              С удовольствием объясню :)
              LLVM — это целый набор компиляторных и около компиляторных тулов построеных на модульной основе. Все инструменты построены вокруг единого внутреннего представления, называемого биткодом. Это представление едино для разных платформ и стадий компиляции (начиная с выхода фронтэнда и заканчивая кодогенератором для конкретной платформы). На этом внутреннем представлении оперируют множество оптимизаций и трансформаций (тот же AddressSanitizer инструментирует биткод), которые платформенно независимы (ну или как минимум стараются быть платформонезависимыми).

              Как это выглядит снаружи? Есть Clang — классический компилятор языков C/C++/Objective C. Берёт исходник и генерирует обычный бинарий. Есть отдельно виртуальная машина (vmkit), которая использует то же внутреннее представление для исполнения .Net и Java. Есть также LLVM JIT, который исполняет внутренне представление без прямой генерации бинариев.

              Так что общий ответ простой — есть и обычный компилятор, и JIT.
                0
                Самое лучшее объяснение! Лаконично и по сути!
                0
                Всегда думал, что понимаю устройство LLVM, теперь точно запутался. Какой инструмент из toolchain'а LLVM позволяет IR компилировать в исполняемый файл (под ту или иную архитектуру)?
                  +4
                  llc
                    0
                    Ок, тут недавно пробегала статья, про RubyMotion. Проект реализует поддержку Ruby в инфраструктуре LLVM за счет чего позволяет писать приложения на Ruby и компилировать их в mach-o под ARMv7 (насколько я понял). Расскажите как это реализовано, пожалуйста. Какие элементы toolchain'а LLVM автору пришлось написать для реализации подобного (дикого) трюка. Тут же явно не используется LLC (чьи возможности в плане поддерживаемых архитектур оставляют желать лучшего).
                      0
                      >Тут же явно не используется LLC (чьи возможности в плане поддерживаемых архитектур оставляют желать лучшего)

                      Что значит оставляют желать лучшего? Он как раз поддерживает все архитектуры, которые заявлены в LLVM.

                      [ушёл читать статью про RubyMotion]
                        0
                        Походу про LLC я поторопился (судя по всему наткнулся на старую документацию). Backend'ов изначально у LLVM заложено как надо (есть поддержка ARM и не только). В любом случае, если бы вы рассказали про то, как устроено у RubyMotion — было бы крайне позитивно.
                          0
                          Насколько я понял, он просто фронтэнд для Ruby написал, который генерирует LLVM bitcode. Ну и плюс библиотеки специфичные для Ruby сделал для iOS.
                          0
                          Простите, что так много вопросов, тема крайне интересная. Верно ли утверждение, что с помощью LLVM/LLC можно делать кросскомпиляцию? Допустим, собирать Mach-O ARMv7 на Windows под x86?
                            +2
                            Вопросы — это всегда хорошо :)

                            Утверждение верно, делать кросскомпиляцию можно. Зуб на отсечение, как говорится, не дам, так как сам лично такого эксперимента не делал. Но вообще такая фича поддерживается. При сборке llvm надо просто configure нужные флажки подать чтобы определить кто хост, а кто таргет.

                            Но вообще, лично я бы кроскомпилятор использовал бы только для экспериментов и повседневной разработки, но не для продуктовых билдов. Как у компиляторщика, предубеждения у меня есть некоторые против кросскомпиляторов (не относящиейся конкретно к llvm)
                              +2
                              LLVM и Clang по своей сути — кросс-компиляторы и им абсолютно всё равно какой хост.
                                +1
                                Если есть какие-то глобальные вопросы — можно задавать тут в коментах. Если будет настроение, может более развёрнутую статью напишу, знать бы только что людям интересно.
                        0
                        Дополню:
                        CLANG — это Front-end, который переводит C/C++/Objective C (теперь ещё и CUDA) в IR представление, далее при помощи backend данное представление трансформируется в конечный вариант.

                        На самом деле можно и GCC (версии 4.5 и выше) заставить генерить IR представление, используя плагин dragonegg. Это полезно, когда надо задействовать, например Fortran.

                        Для особо ленивых программистов есть CLOOG — который позволяет оптимизировать циклы в случае многопоточных приложений (средствами OpenMP).
                          +2
                          Тут, кстати, есть некоторая путаница на счёт clang'а. Как проект — это просто фронтэнд. Но как инструмент коммандной строки — это весь компилятор (т.е. там clang-фронтэнд, оптимизатор llc ну и плюс внешний линкер).
                            +1
                            Как инструмент — это CLANG+LLVM. Хотя сегодня, зачастую, говорят CLANG — подразумевают CLANG+LLMV
                              0
                              При этом физически это один бинарий, так что можно сказать что clang — это полноценный компилятор (с точки зрения пользователя). Но это всё терминология, сути, не меняет :)
                      +1
                      Господа, а я где-то около подьезда у бабок слашал, что с помошью сабжа можно свой компилятор забабахать? Точнее, нужно то что, нужно — чтобы из псевдо-си/паскакаль языка выдавала ассемблерные команды для, внимание, выдуманного процессора. Можно такое здесь или мне надо капитально протрезветь?
                        0
                        Да, можно. Вот цитата:
                        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.
                          0
                          Так и есть, это хороший инструментарий для оптимизатора — бэкенда компилятора.
                            +1
                            Да. Нужно транслировать конструкции своего языка в промежуточное прдеставление LLVM. Как это делается легко понять скачав LLVM — там к нему в комплекте есть несоклько вполне читабельных примеров по написанию компилятора собственного языка программирования.
                              0
                              >>а я где-то около подьезда у бабок слашал
                              Вы точно из России? Может эти «бабки» жены Дениса Ричи и Кена Томпсона? Я к тому что у нас таких продвинутых бабок очень мало
                                +3
                                Штук пять. Да и те на Евровидение уехали :)
                                0
                                Только не говорите про DCPU-16!
                                  0
                                  так поддержку DCPU-16 в llvm (а точнее в форке) уже сделали ;)
                                    +3
                                    Он молчит. Мы молчим. Никто ничего не говорил про DCPU-16.
                                  0
                                  А почему он уже как пару недель в новом Xcode?
                                  Или то немного другая, «личная» версия Apple?
                                    +2
                                    Точно не знаю. Релиз был запланирован на 14 мая и в SVN (http://llvm.org/svn/llvm-project/llvm/tags/RELEASE_31/final) он появился по графику, возможно просто тормозили с Release Notes, может ещё какие формальности.
                                      +3
                                      Это внутренние «маркетинговые» версии Apple. Которые ничего не имеют общего с версиями с llvm.org. Apple LLVM Compiler != clang / llvm с llvm.org. Apple LLVM Compiler 3.1 — это версия где-то «посредине» LLVM 3.0 и 3.1.
                                        0
                                        Буду знать. Спасибо.
                                      0
                                      А для Visual Studio нет ли случайно плагина, подключающего к студии LLVM?
                                        0
                                        Промахнулся, мой ответ ниже.
                                        +5
                                        LLVM/Clang можно собрать на винде и более или менее успешно использовать. Правда, стоит всё-таки сказать, что винда — отнюдь не первоочередная платформа для LLVM разработчиков и там много нет. Но, например, Chromium можно собрать клангом на винде.

                                        Вот тут есть инструкции по сборке clang под Visual Studio.

                                        Как воткнуть в VS плагином — не знаю.
                                        +1
                                        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.
                                          0
                                          Всё верно, но пока ещё он не системый компилятор по умолчанию, а кандидат в системные компиляторы по умолчанию. Хотя в недалёком будущем это должно случиться. И это хорошо.
                                            0
                                            Опция 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.
                                              0
                                              Да, но речь о том, что идёт включённым по умолчанию. Пока они считают, что всё-таки не достигли продуктового качества и предлагают clang для экспериментов. Нужно время чтобы выловить все косяки и заточки на gcc.
                                                +1
                                                Возможности FreeBSD -STABLE и не предлагаются в качестве готового решения. Вот выйдет очередной релиз, тогда это будет штатная возможность. Сейчас идёт обкатка и стабилизация кодовой базы LLVM/Clang 3.1 и полностью тестирование будет завершено к середине июля 2012 года, как сказано в пресс-релизе о завершении портирования. После этого начнётся выдавливание GCC 4.2.1 из базовой системы навсегда и переход, где это нужно, на GCC 4.6 из коллекции портов для сборки «проблемных портов».

                                                С другой стороны, уже сейчас использование LLVM/Clang 3.1 для сборки программ даёт основания считать его более строгим компилятором, не прощающим ошибок несовсем организованным программистам. Чем больше багрепортов будет отправлено на замеченные косяки и невозможности сборки Clang'ом программ, тем быстрее авторы таких программ приведут их код в надлежащее состояние.

                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                        Самое читаемое