LINUX.ORG.RU

LLVM 3.0

 , ,


1

3

30.11.2011 в свет вышла очередная версия фреймворка для построения компиляторов и виртуальных машин.

Википедия

Low Level Virtual Machine (LLVM) — универсальная система анализа, трансформации и оптимизации программ, реализующая виртуальную машину с RISC-подобными инструкциями. Может использоваться как оптимизирующий компилятор этого байткода в машинный код для различных архитектур либо для его интерпретации и JIT-компиляции (для некоторых платформ).

Проект LLVM официально включает в себя следующие основные проекты:

  • LLVMCore - библиотеки для обеспечения платформонезависимой оптимизации и кодогенерации под различные виды процессоров и платформ;
  • CLang - компилятор языков C/C++/Objective-C для LLVM;
  • dragonegg - объединяет в себе парсер GCC-4.5 и оптимизацию и кодогенерацию на основе библиотек LLVM;
  • LLDB - дебаггер, использует Clang и LLVM;
  • libc++ - реализация стандартной библиотеки C++ (включает неполную поддержку стандарта C++11);
  • vmkit - реализация языков Java и .Net для LLVM;
  • SAFECode - память-безопасный компилятор С/С++.

Помимо упомянутых официальных проектов существует большое количество проектов, которые используют LLVM для компиляции программ для таких языков как Ruby, Python, Haskell, Java, D, PHP, Lua и т.д.

Основные изменения:

  • llvm-gcc больше не поддерживается, рекомендуется использовать clang или dragonegg;
  • LLVM IR (intermediate representation - платформонезависимый ассемблер для LLVM) включает в себя полную поддержку атомарных операций с памятью (load, store, compare, exchange, read/modify/write, etc.);
  • полностью переделан механизм обработки исключений в LLVM IR;
  • полностью переделана система типов LLVM IR;
  • MIPS backend доведён до production quality;
  • ...

Полный и подробный перечень изменений можно посмотреть в подробностях.

В настоящее время для скачивания доступен только исходный код (через svn). В ближайшее время на сайте в списке закачек ожидается появление бинарных сборок и тарболла.

>>> Подробности (англ.)

★★★★★

Проверено: mono ()
Последнее исправление: mono (всего исправлений: 2)

Все так же тормозит?

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

IIRC, там как минимум зависимость от endianness.

А при чем тут это?

Вот при этом:

namezys> С чего это при выдаче llvm-ассемблера должно быть предположение о конечной архитектуре?

Endianness - это как раз знание о целевой архитектуре. И, вполне возможно, есть еще что-то.

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

А кодогенератор не тупой. Если есть: a+b, c+d, он вполне догадается их раскидать на разные регистры

Тогда при кодогенерации на лету будут тормоза.

Если же кодогенерировать зараннее, то это вообще практически не отличается от классической схемы.

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

Байткод LLVM не интерпретируется, а транслируется в машинные инструкции целевой платформы, причем не в рантайме как делает это .NET, JVM и т.д. а в момент компиляции. Так что вы получаете бинарь с машинными кодами. Транслятор этот как раз «умный» и может производить оптимизации под заданную архитектуру.

Байткод LLVM не добавляет никакого оверхеда - это просто сериализованное по стандарту то самое «промежуточное представление».

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

Endianness - это как раз знание о целевой архитектуре.

Это скорей надо знать разработчику, а не ассемблеру. Ему то что - байты, массивы, int и тд. А в ситуации, когда надо это учитывать, не какой компилятор не спасет - должны еще и мозги быть

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

Тогда при кодогенерации на лету будут тормоза.

Господи. Сгенерил один раз - далее юзаешь. Тем более при запуске можно генерить код без оптимизации, а его по ходу при свободных ресурсах генерить.

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

Endianness - это как раз знание о целевой архитектуре.

Это скорей надо знать разработчику

Это надо знать тому, кто «выдает LLVM-ассемблер».

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

Ну конечный продукт обычно не идёт в байт коде LLVM. Он не для этого создавался. А вот используя компоненты этого компилятора можно создать какую хотите VM. Коими скорее всего и являются отладчики.

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

Это надо знать тому, кто «выдает LLVM-ассемблер».

Зачем? Я не разу не представляю, зачем это надо, кроме как работе с char[] и (char*)&a

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

Ну конечный продукт обычно не идёт в байт коде LLVM.

OpenCL как раз вроде в байткоде идет. Просто сейчас нет необходимости в этом, ибо одна платформа

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

Ну для OpenCL все-таки есть дополнительный транслятор на исполняющей этот код стороне. Так что думаю байт код OpenCL является целевой платформой для всего LLVM стека. Ну я по крайней мере так сделал бы.

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

ну да. в общем не суть. по мне не должно быть разницы, на какой платформе исполнять, и код должен быть один и тот же (до тех пор, пока ты не начал выдирать байты из объекта)

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

При чем тут это. Если ты работаешь с типом более одного байта, то ты можешь считать, что там биты последовательны, до тех пор, пока ты не полезешь оттуда байт доставать.

А как вообще это влияет на то, что вы написали, я не понимаю.

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

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

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

Sparn
()
Ответ на: комментарий от cvs-255

Объясните смысл этой системы?

Любой компилятор состоит, как правило, из 2 больших частей - front-end и back-end.

Front-end разбирает на токены, парсит исходник, строит синтаксическое дерево и генерирует промежуточное представление кода.

Back-end производит оптимизации и генерирует машинный код для таргет-платформы (в т.ч. для и для всяческих виртуальных машин и т.д.).

Вот LLVM - это очень клёвый кроссплатформенный back-end с весьма удобным промежуточным представлением (IR) и собственной RISC-like VM с JIT и интерпретатором.

shty ★★★★★
() автор топика
Ответ на: комментарий от cvs-255

Главное отличие то, что LLVM - фреймворк для написания компиляторов. Фронтенды, которые работают с текстом программы и бэкенды, генерирующие нативный код, достаточно слабо связаны между собой.

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

Конечно, возможно, инфорацию о платформе можно использовать и на стадии семантического анализа, но в данный момент я не представляю, какую помощь при этом могут оказать эти данные

да никакую не могут - это фигня полная

shty ★★★★★
() автор топика
Ответ на: комментарий от I-Love-Microsoft

это обычные дэлэлэ/сошки

там только название похожее, а на самом деле, .NET'овские dll и «обычные» dll - это совсем разные вещи.

и в линуксовом Mono, тоже .dll, а не .so.

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

В чем проблема? В самом LLVM IR есть поддержка практически любых типов, целых типов с произвольной разрядностью 8, 16, да хоть 17, 1(бит) или 256, с плавающей точкой, структур, указателей, всё что вашей душе угодно.

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

да никакую не могут - это фигня полная

Ну привели пример из дервних платформ

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

Инструкции LLVM достаточно высокоуровневые, вообще его IR похож на высокоуровневый язык,

Знаю. Но речь шла о платформной (не)зависимости.

гляньте в википедию.

А можно, я буду читать статьи авторов LLVM? %)

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

Мне тут утверждают, что на стадии синтаксического или семантического анализа кода надо знать порядок байт в слове. До сих пор не объяснили, зачем это знать компилятору.

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

Допустим, машинная команда перехода имеет размер 4 байта и находится по адресу 0x1234.

Напиши адрес, по которому хранится младший байт.

Rzhepish
()
Ответ на: комментарий от cvs-255

А затем мы его переводим не в машинные коды, а в байт-код.

либо в нативный код, либо в байт-код для машины, либо вообще не переводят никуда, а просто интерпретируют

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

До сих пор не объяснили, зачем это знать компилятору.

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

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

Знаю. Но речь шла о платформной (не)зависимости.

Ну код LLVM IR обычно (на выходе из семантического анализатора) платформонезависим. Специфические инструкции есть, но появляются они уже когда включаются оптимизаторы под конкретную платформу, т.е. уже после высокоуровневых оптимизаций.

А можно, я буду читать статьи авторов LLVM? %)

Ради бога)

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

Если ты узаешь union, то ты ССЗБ, и в своем КОДЕ должен учитывать эти проблему. А не компилятор, ему то по фиг.

Лежит тут int, и лежит. А то, что ты к нему, как к char[] полез, это твои личые трудности, но не в коем случае трудности компилятора

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

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

То есть промежуточное представление llvm является машинозависимым (точнее может являться). Иначе говоря, оптимизатор на стадии анализа кода использует знания о конечно платформе?

НЕ ВЕРЮ

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

Как думаешь, уж не компилятор ли работает с описанными типами пользователем, с их размерами и, в частности, со смещением полей в составных типах?

компилятор - это не блоб тебе монолитный, ты сейчас какую часть компилятора имеешь в виду?

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

Я честно говоря тоже не понял задачи. Вы работаете с типом «указатель» или типом «целое 32 бита»? Какой код вам нужно транслировать?

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

код LLVM IR обычно (на выходе из семантического анализатора) платформонезависим.

Вопрос в том, является ли байткод LLVM платформонезависимым _by design_.

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

google struct, union

Зачем компиляторы рассчитывать младший байт в int, если align в struct, union происходит в порядке увеличения адреса в байтах.

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

Вы не совсем поняли в корне о чем идет речь. Считайте это частью обычного компилятора. Например Вы создатель своего языка. В обычном случае Вам нужно написать много компиляторов для разных архитектур/ОС. Или же Вы можете написать один раз компилятор в LLVM, а потом выпустить n компиляторов под n архитектур, включив туда библиотеки под n разных архитектур. Коечный пользователь здесь так же получит файлы so, dll и т.п., но разработчику это упростит существенно жизнь. А если появится новая архитектура, то достаточно подготовить соответствующий реализацию для LLVM, а вам для вашего компилятора, вашего языка ничего дописывать под эту архитектуру не нужно.

Это простой вариант, просто чтобы иметь понятие о чем идет речь.

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

Вопрос в том, является ли байткод LLVM платформонезависимым _by design_.

Байткод LLVM настолько же платформонезависим, насколько платформонезависим исходный код, из которого он сгенерирован.

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

Да. Код LLVM IR ожет быть платформо зависимым ) там есть специфические типы. И нет. Оптимизатору не обязательно знать о конечной платформе, всё зависит от того на какой стадии он включается. Там ведь редко бывает один оптимизатор, обычно их целая тирада. Платфомо зависимые оптимизаторы включаются в последнюю очередь.

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

Байткод LLVM настолько же платформонезависим, насколько платформонезависим исходный код, из которого он сгенерирован.

Это заявление имело бы вес, если бы сопровождалось ссылкой, или исходило от человека, который написал хотя бы учебный бэкенд для LLVM.

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

Это интересно. Правда при этом я не вижу причину это делать, ну если только для использования специфичных инструкций

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

Ваша задача все равно либо притянута за уши либо вы не можете её сформулировать.

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