LINUX.ORG.RU

Релиз LLVM 2.9

 ,


0

2

Состоялся новый релиз системы программирования Low Level Virtual Machine (LLVM). Среди заявленных изменений можно отметить улучшенную генерацию и оптимизацию кода, поддержку C++'0x в Clang, а также более продвинутый отладчик LLDB для C, Objective-C и C++, официально поддерживающий, правда, только Mac OS X i386 и x86-64.

Наиболее важные функциональные новинки включают встроенную поддержку ассемблера для ELF-файлов (прямую запись в объектный файл), некоторые улучшения в области оптимизации во время линковки файлов (Link Time Optimization, LTO), позволяющей компилировать приложения из большого дерева исходных кодов, автоматическую замену циклов на вызов memset и memcpy, улучшения в отладке оптимизированного кода, готовую инфраструктуру для оптимизации, базирующуюся на регионах (region based optimization), улучшенную поддержка кода, обращающегося к состоянию регистров, новый алгоритм распределения регистров.

Версия 2.9 — последняя в ветке 2.х. В 3-ей ветке планируется отказаться от компилятора llvm-gcc 4.2. Указывается, что проект Clang является лучшим решением для компиляции основанных на C языков, а проект DragonEgg является подходящим решением для тех, кто интересуется интеграцией LLVM с GCC.

Комментарии к релизу

>>> Подробности

★★★★★

Проверено: post-factum ()

Ответ на: комментарий от segfault

> (Почитай про функции виртуальной машины, прежде чем писать подобную ересь).

Батенька, да вы, похоже, дурак. GIMPLE в GCC - это тоже, представь себе, виртуальная машина. Тоже отправишь меня читать?

anonymous ()
Ответ на: комментарий от segfault

> Да нету там виртуальных машин, хоть ты тресни! Исполнения приложения во время компиляции не происходит.

Хоть обтрескайся, но там полно виртуальных машин. На каждый уровень компиляции по виртуальной машине. В LLVM она хотя бы одна (ну ладно, две - SSA и то, что после reg2mem остается), а в GCC виртуальных машин полно.

anonymous ()
Ответ на: комментарий от segfault

LLVM же является виртуальной машиной с байт-кодом и JIT-ом

Ты болеешь, да? Головой сильно стукнулся? Где тут байт-код и JIT?

$ clang -S hw.c
$ cat hw.s
        .def     _main;
        .scl    2;
        .type   32;
        .endef
        .text
        .globl  _main
        .align  16, 0x90
_main:                                  # @main
# BB#0:                                 # %entry
        pushl   %ebp
        movl    %esp, %ebp
        subl    $16, %esp
        movl    $0, -4(%ebp)
        movl    %esp, %eax
        movl    $L_.str, (%eax)
        calll   _printf
        movl    %eax, -8(%ebp)          # 4-byte Spill
        movl    -4(%ebp), %eax
        addl    $16, %esp
        popl    %ebp
        ret

        .data
L_.str:                                 # @.str
        .asciz   "Hello, world!\n"
anonymous ()
Ответ на: комментарий от anonymous

> Ладно для интерпретируемых языков, а какая выгода от промежуточного представления для какого-нибудь С? Хоть ссылкой ткните, если это где-то хорошо разжевано.

http://www.ozon.ru/context/detail/id/3829076/

anonymous ()
Ответ на: комментарий от segfault

> К.О: LLVM же. Сначала загрузчик ее грузит, а потом она уже загружает приложение. Причем, второй процесс куда тяжелее первого.

Ну вперед, с песнями, ищи LLVM в бинарниках, созданных llc.

anonymous ()
Ответ на: комментарий от anonymous

>> Чего он может. менять порядок следования инструкций? которые в памяти.

Да. Поправьте если ошибаюсь. As a kind of proof — Роберт Лав, Linux Kernel Development, глава 10, «Ordering and Barriers» и глава 19, «Processor Ordering».

Между барьерами может

namezys ★★★★ ()
Ответ на: комментарий от anonymous

> Ну и в чем, по твоему, разница между LLVM и GIMPLE? Одинакового уровня прослойки.

Gimple не участвует в исполнении приложения. Если использовать LLVM как виртуальную машину, а не как компилятор, то прослойка при исполнении все-таки есть.

Ваш К.О.

segfault ★★★★★ ()
Ответ на: комментарий от anonymous

> Ну вперед, с песнями, ищи LLVM в бинарниках, созданных llc.

То же касается авторов постов http://www.linux.org.ru/jump-message.jsp?msgid=6125711&cid=6144794 http://www.linux.org.ru/jump-message.jsp?msgid=6125711&cid=6144772 http://www.linux.org.ru/jump-message.jsp?msgid=6125711&cid=6144772 (последние два еще и интерпретатор в GCC узрели...): Перед тем, как встревать в спор, сначала посмотрите, с чего он начался - http://www.linux.org.ru/jump-message.jsp?msgid=6125711&cid=6128623

segfault ★★★★★ ()
Ответ на: комментарий от segfault

> Gimple не участвует в исполнении приложения.

Точно так же как и LLVM.

Если использовать LLVM как виртуальную машину, а не как компилятор, то прослойка при исполнении все-таки есть.

Повторяю для особенно тупых: ты не понимаешь вообще, что такое виртуальная машина. У тебя в голове каша. Ты путаешь виртуальную машину с интерпретатором или JIT-ом виртуальной машины. На самом деле виртуальная машина - это абстрактная семантика. И между LLVM и GIMPLE никакой разницы нет в принципе. И то и другое это виртуальные машины, описывающие некий, достаточно низкий (и машинозависимый) уровень. И для того, и для другого существуют компиляторы в разнообразные native ассемблеры. И тот и другой компилятор можно прикрутить для кодогенерации в памяти - тогда получится что-то типа JIT-а. Просто с LLVM это делают чаще, чем с GCC, он для этого немного удобнее. Вот и вся разница.

anonymous ()
Ответ на: комментарий от segfault

> последние два еще и интерпретатор в GCC узрели...

Больной и тупой, да?

Он там есть, не хуже чем в LLVM. И используется там интерпретатор ровно с той же целью - агрессивный constant propagation.

anonymous ()
Ответ на: комментарий от segfault

> с чего он начался - http://www.linux.org.ru/jump-message.jsp?msgid=6125711&cid=6128623

Именно, началось все с того, что агрессивный и тупой тролль делает вид что не понимает, что такое виртуальная машина. Ну хоть бы книги какие почитал прежде чем так глупо позориться, что ли? Ту же драконью книгу, например. Практически не существует компиляторов, внутри которых не было бы виртуальной машины.

anonymous ()
Ответ на: комментарий от anonymous

> Ты путаешь виртуальную машину с интерпретатором или JIT-ом виртуальной машины.

http://ru.wikipedia.org/wiki/%D0%92%D0%B8%D1%80%D1%82%D1%83%D0%B0%D0%BB%D1%8C...

Для нелюбителей ходить по ссылкам цитирую: «Виртуальная машина исполняет некоторый машинно-независимый код». ИСПОЛНЯЕТ. Понятно?

а самом деле виртуальная машина - это абстрактная семантика.

Да и не логично это вовсе - называть «машиной» семантику кода.

между LLVM и GIMPLE никакой разницы нет в принципе. И то и другое это виртуальные машины

Расскажите это авторам GIMPLE - вот они удивятся!

segfault ★★★★★ ()
Ответ на: комментарий от anonymous

> Он там есть, не хуже чем в LLVM. И используется там интерпретатор ровно с той же целью...

Интерпретатор в компиляторе... \0

segfault ★★★★★ ()
Ответ на: комментарий от segfault

> Для нелюбителей ходить по ссылкам цитирую: «Виртуальная машина исполняет некоторый машинно-независимый код». ИСПОЛНЯЕТ. Понятно?

Не пойти ли тебе на хер со ссылками на педиковикию? То, что статью писали сосунки, про эту их новомодную «виртуализацию», которая еще десять лет назад вообще никому никуда не впилась, это как бы не важно, да?

В контексте компиляторостроения термин «виртуальная машина» это синоним термина «абстрактная машина», и словами «виртуальная машина» назывались абстрактные семантики очень задолго до появления всяких там JVM и прочей чуши.

Да и не логично это вовсе - называть «машиной» семантику кода.

Ну давай, иди, поучи Ахо с Ульманом, что им и как называть. Ты ж типа самое умное тут, а они все погулять вышли.

Расскажите это авторам GIMPLE - вот они удивятся!

Я поражаюсь, как такое необразованное чмо может обладать таким упертым апломбом.

anonymous ()
Ответ на: комментарий от segfault

> Интерпретатор в компиляторе...

Именно так, наивный человек, именно так. Почитай уж, как работают такие оптимизации, как Agressive DCE, global DCE, agressive constant propagation и partial specialisation. Все они основаны на частичной интерпретации выражений или последовательностей инструкций VM.

Кстати, вот тебе еще для разрыва шаблона - в GCC еще и байткод есть, все как у взлослых. Читай про LTO.

anonymous ()
Ответ на: комментарий от anonymous

> Практически не существует компиляторов, внутри которых не было бы виртуальной машины.

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

Тем, кто хочет продолжить пороть такую ересь, предлагаю сначала почитать ту же педивикию:

http://ru.wikipedia.org/wiki/%D0%A2%D1%80%D0%B0%D0%BD%D1%81%D0%BB%D1%8F%D1%82...

http://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%82%D0%B5%D1%80%D0%BF%D1%80%D0%B5...

Ресурс хоть и не самый достоверный, но все-же более корректный чем чье-то ИМХО...

По второй ссылке русским по белому написано: «Интерпрета́тор — ... Вид транслятора, осуществляющего пооператорную (покомандную) обработку ... (в отличие от компилятора, транслирующего всю программу без её выполнения)». Обратите внимание на «В ОТЛИЧИЕ ОТ КОМПИЛЯТОРА» и «БЕЗ ЕЕ ВЫПОЛНЕНИЯ».

segfault ★★★★★ ()
Ответ на: комментарий от segfault

> Тем, кто хочет продолжить пороть такую ересь, предлагаю сначала почитать ту же педивикию:

Педивикия уже стала авторитетом? Ссылался бы хотя бы на Голдберга.

По второй ссылке русским по белому написано: «Интерпрета́тор — ... Вид транслятора, осуществляющего пооператорную (покомандную) обработку ... (в отличие от компилятора, транслирующего всю программу без её выполнения)». Обратите внимание на «В ОТЛИЧИЕ ОТ КОМПИЛЯТОРА» и «БЕЗ ЕЕ ВЫПОЛНЕНИЯ».

Да, идиот ты клинический. Боюсь, лечиться тебе давно уже поздно.

Повторяю для терминально больных на голову: читай о том, для чего компиляторам нужно частично интерпретировать код. Ключевые слова я тебе дал. Про это в любой относительно современной книге по компиляторам написано.

anonymous ()
Ответ на: комментарий от anonymous

> для чего компиляторам нужно частично интерпретировать код

Да до лампочки, какую магию компилятор применяет для своей работы. Главное - на выходе полноценный пакет с нативными процессорными инструкциями, для запуска которого не требуется стороннего приложения/демона.

segfault ★★★★★ ()
Ответ на: комментарий от segfault

> Да до лампочки, какую магию компилятор применяет для своей работы. Главное - на выходе полноценный пакет с нативными процессорными инструкциями, для запуска которого не требуется стороннего приложения/демона.

Ну то есть слил, да? Молодец. А теперь усвой: LLVM это компилятор. GCC это компилятор. Между ними нет никакой архитектурной разницы. И у того, и у другого куча frontend-ов и куча backend-ов. И тот, и другой, генерят ассемблерный код, который потом отдается отдельно ассемблеру и линкеру. И тот, и другой способны интерпретировать свой промежуточный код. И LLVM и GCC можно использовать в качестве JIT, для чего просто отключается большая часть дорогостоящих оптимизаций, но это не является основным применением для них.

anonymous ()
Ответ на: комментарий от segfault

> Исполнения приложения во время компиляции не происходит.

в С++ частично происходит. Потому что нельзя сгенерировать код, не разворачивая шаблон, а чтобы шаблон развернуть нужно исполнение какого-то подмножества языка.

anonymous ()
Ответ на: комментарий от segfault

> Давай лучше допустим, что я реализую криптоалгоритм или фильтр для изображения.

давай, давай. Вот для Lua есть реализация парсера виртуальной машиной: http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html
про цифровые фильтры: DSP VM http://lantana.tenet.res.in/website_files/publications/DSPVM/standDSPVIRTUAL2...

anonymous ()
Ответ на: комментарий от anonymous

ну или map-файл собрать, и убедиться, что лишних зависимостей нету или ldd ./helloworld|grep libLLVM и убедиться, что в бинарнике размером около 6kb все библиотеки LLVM размером ~15Мб не помещаются :))

anonymous ()
Ответ на: комментарий от anonymous

> На самом деле виртуальная машина - это абстрактная семантика.

во! но апи рантайма стандартной библиотеки — это тоже абстрактная семантика АБИ программы на каком-то языке. То есть, разница между рантаймом стандартной библиотеки языка и виртуальной машиной языка (например, интерпретатором) только в уровне этой абстрактной семантики — ниже какого-то уровня это ещё рантайм, выше какого-то метауровня это уже виртуальная машина. Если ещё считать что при этом и языки меняются (язык для интерпретатора <=> подмножество языка для компиляции <=> подмножество метаязыка (языка виртуальной машины компилятора) (то есть, ищется неизвестная виртуальная машина неизвестного метаязыка, которым по сути является АБИ программы), то для произвольной программы нельзя наугад ткнуть пальцем и сказать, где заканчивается виртуальная машина и начинается уже рантайм.
Хотя для обычных случаев оно всё-таки гораздо чётко выделено.

anonymous ()
Ответ на: комментарий от segfault

> Для нелюбителей ходить по ссылкам цитирую: «Виртуальная машина исполняет некоторый машинно-независимый код».

ты сам-то свою ссылку читал?

http://ru.wikipedia.org/wiki/%D0%92%D0%B8%D1%80%D1%82%D1%83%D0%B0%D0%BB%D1%8C...

также, спецификация некоторой вычислительной среды (например: «виртуальная машина языка программирования Си»).

ИСПОЛНЯЕТ. Понятно?


и что, тебе непонятно какой тут язык исполняется, чем именно и в какой момент трансляции?

Да и не логично это вовсе - называть «машиной» семантику кода.


пипец. А это по-твоему что http://en.wikipedia.org/wiki/SECD_machine ? только не говори, что семантика тут не причём.

anonymous ()
Ответ на: комментарий от segfault

>> а самом деле виртуальная машина - это абстрактная семантика.

Да и не логично это вовсе - называть «машиной» семантику кода.


как раз логично — взяли операционную семантику языка и выделили её в виде виртуальной машины. Взяли исполнили программу на этой виртуальной машине — получили интерпретатор. Взяли прогнали (man РЕФАЛ прогонка суперкомпиляция) интерпретатор через суперкомпилятор => сделали компилятор. Ну или без суперкомпилятора, проинтерпретировали интерпретатор другой транслирующей машиной, более простой => получили компилятор.

Это если явно семантику кода определять, можно явно сказать: вот она, семантика, реализуется виртуальной машиной. А если эта семантика не такая явная, сама получена из другой виртуальной машины — можно сказать это рекурсивные виртуальные машины, вложенные друг в друга, и программа, апи в конкретных деталях вплоть до аби и исполнения, виртуальная машина — это одно и тоже, только с разных точек зрения (логических уровней. Физически код-то тот же самый, как ни смотри).

anonymous ()
Ответ на: комментарий от segfault

> Интерпретатор в компиляторе... \0

начнём с С++. напиши факториал шаблонами, и скажи мне, как без интерпретора (языка шаблонов) может завершиться и отработать конпелятор (языка С++)?

потом можно будет к С перейти. Например, почему gcc -m32 и gcc -m64 транслируют int или void* в разное количество байтов? вот есть у меня структура из int-ов и указателей, как мне узнать во время комиляции сколько байтов она займёт и конкретно где, учитывая выравнивание?

anonymous ()
Ответ на: комментарий от segfault

> Главное - на выходе полноценный пакет с нативными процессорными инструкциями,

а ты ещё и про микрокод процессора небось совсем не знаешь?
нативные инструкции такие нативные

anonymous ()
Ответ на: комментарий от anonymous

> GCC это компилятор. Между ними нет никакой архитектурной разницы.

ну, архитектурная разница есть. Она в способе структурирования модулей: у gcc это отдельные программы (cpp, cc1, as, ld который в свою очередь обёртка над collect2), связанные через пайпы кодом в универсальной форме (что по Э.Реймонду Art Of the Unix Programming есть TrueЪ), в итоге имеем понятные данные и код, в котором относительно сложно разобраться.
в LLVM это АПИ библиотек на С++, которые разбиты на модули, реентерантны и сидят в виде библиотек в памяти. Всё что нужно — дёргать за API вызовы, не нужно столько обёрток.

параллелизм по данным / параллелизм по коду типа

И LLVM и GCC можно использовать в качестве JIT,


а как сделать GCC-JIT?

anonymous ()
Ответ на: комментарий от anonymous

> И тот, и другой, генерят ассемблерный код, который потом отдается отдельно ассемблеру и линкеру.

ЕМНИП, clang может генерировать бинарник напрямую в обход ассемблера, если его об этом специально не просить — работает с биткодом в памяти напрямую, не передавая его в стороние тулзы, вроде tcc через libtcc

anonymous ()

ещё интересная идея здесь http://piumarta.com/S3-2010/ : компилятор, в котором в качестве и фронтенда и бекенда используется PEG парсер. Язык вроде Scheme транслируется в ассемблер x86, в статье описано представление, упрощающее трансляцию. Производительность оттранслированного в районе 75% от GCC, с парой тривиальных описанных в статье оптимизаций в районе 80-95% от того же кода, собранного GCC.

компилятор простой, на пару страниц.

Что интересно было бы сделать: прикрутить к этому компилятору трансляцию в SSA форму и LLVM в итоге, и использовать LLVM для оптимизаций (отдельно генерируя биткод и запуская opt) и окончательной кодогенерации.

anonymous ()
Ответ на: комментарий от anonymous

из этой идеи следует, что компилятор языка это морфизм, отображающий абстрактную высокоуровневую виртуальную машину языка в низкоуровневую исполняющую виртуальную машину. Он сам по себе является виртуальной машиной какого-то другого языка.
Оптимизатор со всеми проходами оптимизации и определением того, какая оптимизация наиболее оптимальная — тоже морфизм. Была ссылка про поиск оптимизации как наиболее правильного морфизма, если вспомню и найду — отпишу.

anonymous ()
Ответ на: комментарий от anonymous

> Она в способе структурирования модулей: у gcc это отдельные программы (cpp, cc1, as, ld который в свою очередь обёртка над collect2), связанные через пайпы кодом в универсальной форме (что по Э.Реймонду Art Of the Unix Programming есть TrueЪ), в итоге имеем понятные данные и код, в котором относительно сложно разобраться.

LLVM тоже бывает в виде кучки отдельных бинарников - opt, llc, llvm-link, и т.д. И gcc при желании можно в один большой бинарник собрать.

а как сделать GCC-JIT?

Это довольно таки жуткое извращение, конечно же. Я подменял драйвер (cc1) своей оберткой. Правда, без промежуточных ассемблерных файлов и пайпа к gas не обошлось, но jit был примерно как TCC устроен.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.