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)

Ура ура ура. Кстати, libcxx прекрасно на линуксе работает, хотя и написано, что она только на макоси поддерживается. Но блин, хочу лямбды!

Gorthauer ★★★★★
()

На общем «кислом» фоне, наконец-то, действительно положительная новость.

И главное - как вовремя новая версия вышла // это уже с личной, «потребительской» точки зрения ;)

OldFatMan
()

C++0x

C++11 оно теперь называется

unfo ★★★★★
()

Классная новость! Теперь D можно пересобрать с третьей версией и забыть про Си как страшный сон страуса.

matumba ★★★★★
()

память-безопасный

Классное словосочетание)

CKPbIT_HUK
()

Объясните смысл этой системы? Если интерпретировать llvm-байткод, то производительность хромает.

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

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

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

Готовый бэкенд для компиляторов. Достаточно написать компилятор в llvm — можно будет компилировать под любую платформу, поддерживаемую llvm

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

Но блин, хочу лямбды!

во во, без лямбд оно пока что не очень годно

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

Достаточно написать компилятор в llvm — можно будет компилировать под любую платформу, поддерживаемую llvm

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

cvs-255 ★★★★★
()

для таких языков как Ruby, Python, Haskell, Java, D, PHP, Lua

да... LLVM - супер технология! базовая, очень важная, прогресс => светлое линукс-будущее

если не секрет, подскажите самый основной проект LLVM+Python? мне любопытно насколько он быстр и совместим ли с PyQt/PySide и т.п.

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

Так в отличие от жавы, результатом компиляции является не байт-код. а native, под конкретную архитектуру. Или я неправ?

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

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

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

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

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

Когда я пытался разбираться в коде коллеги, который ни с того ни с сего стал писать на C++11 и активно использовал лямбды я не мог не желать ему смерти.

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

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

должны быть предположения об возможности распараллеливания

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

когда исходники компилировались в байт-код, делались предположения об архитектуре реального процессора, такие как число команд за такт и возможности распараллеливания

Эмм... ты точно понимаешь, что такое байт-код?

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

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

FIX

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

должны быть предположения об возможности распараллеливания

Распараллеливания чего?

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

Все попытки забыть Си утыкаются в громадное количество сишных программ и библиотек, как утыкались в свое время попытки забыть Фортран. Однако, если для Фортрана еще можно было сделать f2c, то сделать какой-нибудь «c2d» не так уж просто, поскольку немалая часть кода на си — низкоуровневая.

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

Тонкости неизвестны, но принцип знаю. И получается, что байт-код, оптимизированный для x86, с его 1-2 команды за такт, будет тормозить на итаниумах.

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

И получается, что байт-код, оптимизированный для x86, с его 1-2 команды за такт, будет тормозить на итаниумах.

С какого перепугу синтаксический транслятор занимается микрооптимизацией?

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

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

Да, а в аду С++ программисты будут разбирать ошибки STL и Boost :)

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

Байткод не оптимизируется под архитектуру. Оптимизация производится при трансляции байткода в машинный код.

buddhist ★★★★★
()

Годно, нужно, одобряю!

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

Тонкости неизвестны, но принцип знаю.

Судя по тому, что ты пишешь — не очень.

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

LLVM реализует виртуальную RISC-машину (так говорит википедия). Если мы будем потом это исполнять на существенно отличающейся архитектуре, то тормоза неизбежны.

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

Ну укроти для начала дракона, что ли....

Компиляция всегда состоит из нескольких стадий:
* препроцессинг
* синтаксический анализ
* семантический анализ
* генерация кода

После семантического анализа промежуточное представление фактически уже не содержит не каких знаний о языке. Что gcc, что llvm генерит используют какое-то промежуточное представление в виде как-то абстрактной простой машине. Далее работает кодогенератор, переводя с промежуточного представления в машинный код.

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

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

в аду С++ программисты будут разбирать ошибки STL и Boost

А особо злостные грешники ещё и ace с loki? =)

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

Если мы будем потом это исполнять на существенно отличающейся архитектуре

А вот не надо это исполнять. Надо оттранслировать в нативный машинный код, попутно оптимизнув под целевую систему.

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

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

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

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

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

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

Если мы будем потом это исполнять

Иди курить матчасть, в обычных условиях оно не исполняется, а компилируется в машинные коды. Виртуальная машина там -лишь прослойка между фронт- и бэкендом.

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

да, и вообще, самая нормальная интеграция с нативщиной - у Mono(.net), это обычные дэлэлэ/сошки, вот так наверное и стоило делать Си-шные расширения для питона, а то странная ситуаций все равно получается - куча расширений совместимы с одной реализацией и не совместимы с другой

кажется я заблуждаюсь, поясните пожалуйста в чем :)

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

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

А компиляция в нативный код у нас тупая? Хотя тут конечно сложно проследить, что вычисления вычитаемого надо производить с учетом разного знака. Я думаю и семантический анализатор это не сделает

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

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

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

а, ясно, но питон же может простые dll/so подтягивать? ведь там можно как-то это приукрасить и упростить этот механизм со стороны языка? не? вот как в Mono сделано...

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

и еще, например если расширение ориентировано на API Python 3.2 (просто от балды версия), но и в CPython и в PyPy и еще в другой реализации они будут гарантированно работать? они - расширения, модули (dll/so)... или какой там формат у расширений

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

Ну вот мы получили некоторое промежуточное представление. А затем мы его переводим не в машинные коды, а в байт-код. А лишь затем байт-код будет переводиться в машинный код. Если бы все процессоры были бы строго фон-Неймановскими машинами, то разницы бы не было. Но это не так. И если в коде есть участки, которые могут выполняться параллельно, то надо по-возможности их распараллелить. Но на архитектурах, выполняющих 2 и 22 команды за раз, это происходит несколько по-разному. А потому, если мы хотим оптимизации на разных архитектурах, то интерпретатор байт-кода должен быть «умным», т.е. динамически раскидывать байт-код на параллельные куски. Но при этом существенно теряется скорость => быстрый интерпретатор должен быть простым. А тогда он не сможет оптимизировать байт-код для разных архитектур

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

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

А ты его пробовал выдавать? IIRC, там как минимум зависимость от endianness.

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

Ну если была бы договоренность. Но пока достигнуть ее не получается, ибо CPythone сдена по принципу максимальной защищенности, а пипи скорости

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

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

Какая разница? Не кто не обязывает компилятор инструкцию a+b неоптимизировать.

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

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

Насчет затрат на трансляцию байт-кода в машинный, если уж интересно, рекомендую посмотреть, что такое JIT и HotSpot в жабе. Но к этой теме это отношение не имеет: llvm может выдовать код в нативном виде. Кроме того, результат работы кодогенератора можно кэшировать.

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

А тогда он не сможет оптимизировать байт-код для разных архитектур

Поэтому там не один оптимизатор. Один - во время препроцессинга, второй - во время преобразования байткода в машинный.

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