LINUX.ORG.RU

Вышел LLVM 3.1

 


0

5

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

Некоторые изменения:

  • значительно расширена поддержка C++'11 в компиляторе Clang;
  • AddressSanitizer — инструмент для поиска ошибок работы с памятью, позволяющий обнаруживать типичные ошибки при программировании на Си и Си++, такие как выход за границы буфера и т.п.;
  • в генератор кода добавлена поддержка так называемых «связок инструкций», позволяющих значительно повысить качество генерируемого кода для архитектур процессоров VLIW;
  • улучшена работа MIPS и ARM бэкенда;
  • помимо основных функций, этот релиз включает в себя улучшение производительности, исправление ошибок и другие усовершенствования.

Напоминаю, что LLVM позволяет компилировать программы написанные на языках С, C++, Objective-C, Fortran, Ada, Haskell, Java, Python, Ruby, JavaScript, GLSL или любом другом, для которого реализован front-end. В рамках проекта разработан фронтенд Clang для языков C и C++ и версия GCC, использующие llvm в качестве бэкенда. В Glasgow Haskell Compiler также реализована компиляция посредством llvm, существует ещё множество программ, использующих данную инфраструктуру.

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

★★★★★

Проверено: tazhate ()
Последнее исправление: thelonelyisland (всего исправлений: 2)
Ответ на: комментарий от theos

Кому очевидно? Откуда вообще вы это взяли

ну чего вы такой непонятливый. читайте полностью:

llvm - байткод который выполняется эффективнее чем распространяемые бинарники собранные один раз и для всех => очевидно что llvm-байткодный дистрибутив ожидает нас

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

взял gcc/clang - собрал бинарник для своей расширенной архитектуры. проблем 0.

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

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

И вообще, какая разница?

У стековых машин [потенциально] выше плотность кода. Регистровые потенциально кое-где побыстрее. В случае с LLVM, где байткод используется, как compiler IR, а не для дистрибуции, трейд-оффы отличаются от традиционных для виртуальных машин.

triampurum
()

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

МЦСТ смотрит с одобрением!

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

llvm - байткод который выполняется эффективнее чем распространяемые бинарники

Вы лично меряли?

очевидно что llvm-байткодный дистрибутив ожидает нас

Если бы пара процентов производительности была бы для всех на первом месте, все бы пользовались source-based дистрибутивами, что как мы замечаем, не так.

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

У стековых машин [потенциально] выше плотность кода

Какая разница для реализации динамический языков.

Регистровые потенциально кое-где побыстрее.

При условии компиляции в native - нет (а именно так делает LLVM)

theos ★★★
()

Наконец-то он стал поддерживать ламбды, списки инициализации и прочие фичи 0x, которые до этого были только в GCC.

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

libvpx которые кодирует и декодирует vp8 с включенными sse3 и sse4 будет иметь значительный прирост производительности т.к. сам алгоритм учитывает их

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

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

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

C, C++, Objective-C - clang. Fortran, Ada - DragonEgg (последний является плагином GCC), Java - в составе IcedTea и Vmkit, Python - Unladen Swallow и бэкенд для Pypy, Ruby - Rubinius, JavaScript - хз, GLSL - в составе знаешь-чего.

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

Как это ничего? Все необходимые инструменты для JIT.

Yes, but
«Similarly, it makes really-fast JITing hard. LLVM is fast compared to some other static C compilers, but it's not fast compared to real JIT compilers. Compiling one LLVM IR level instruction at a time can be relatively simple, ignoring the weird stuff, but this approach generates comically bad code.» http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html
Рассказывает девелопер LLVM из Apple.

«First of all, we explored a lot of pros and cons of using LLVM for the JIT code generator. The initial choice to use LLVM was made because at the time none of us had significant experience with x86 assmebly, and we really wanted to support x86 and x86_64 and potentially ARM down the road. There were also some investigations of beefing up psyco, which I beleive were frusturated by the need for a good understanding of x86. Unfortunately, LLVM in its current state is really designed as a static compiler optimizer and back end. LLVM code generation and optimization is good but expensive. The optimizations are all designed to work on IR generated by static C-like languages. Most of the important optimizations for optimizing Python require high-level knowledge of how the program executed on previous iterations, and LLVM didn't help us do that.».
http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospective.html
разработчики из Unladen Swallow.

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

В LLVM для JIT нет PGO. Вот почему он уступает таким JIT, как HotSpot. Разработчики psyco столкнулись с необходимостью писать эту часть самостоятельно, словили острый когнитивный диссонанс и решили забить на всё. Но в основном по причине того, что Гугль оказался не заинтересован в быстром Питоне.

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

И еще. Перед глазами как-то пробегал кандидат на GSoC 2011, бравшийся впилить PGO в LLVM JIT, но что-то я об этом больше не слышал. Возможно, задача оказалась неподъемной.

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

В LLVM для JIT нет PGO. Вот почему он уступает таким JIT, как HotSpot. Разработчики psyco столкнулись с необходимостью писать эту часть самостоятельно

Ты хотел сказать «Unladen Swallow»?

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

Python - Unladen Swallow и бэкенд для Pypy

Оба проекта мертвы. Не знаю ни об одном живом Python-to-LLVM компиляторе - думаю, Python можно уверенно вычеркуть из списка поддерживаемых языков.

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

Да про него, могу путаться. Каюсь, конец рабочего дня. Начало рабой ночи :)

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

в общем случае llvm-байткод _платформозависим_.

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

с включенными sse3 и sse4

Использовать опционально использовать SSE3, SSE4 ему ничто не мешает и сейчас. Это уж не говоря о том, что для декодирования видео есть видеокарточка.

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

Феерическая чушь. Ты не имеешь никакого понятия, что такое llvm, и как его применяют - изучи, пожалуйста. Подсказки: статический анализ, jit итп

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

этот LLVM байт-код он кроссплатформенный?

Конечно. Ты можешь смело копировать эти байты с одной платформы на другую - ничего с ними не сделается.

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

Кроссплатформенно очень большое подмножество байт-кода, но не весь, т.к. он поддерживает inline assembler и платформозависимые инструкции.

И кроссплатформенность байткода != кроссплатформенность программ.

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

вот то что вы сказали я ниразу не спорю. я указывал на понятное слово «native» которое указывает на применение всех фич моего процессора.

а какой у вас процессор?

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

Однопроходной компилятор-оптимизатор

зачем?

Допустим есть у тебя воспроизводимая логическая ошибка, тут ты на слабом железе за несколько секунд всё собираешь, запускаешь и смотришь, раз 10, и находишь нужную бяку. А если сборка занимает дофига в квадрате времени, то нужно изобретать что-то другое, велосипедное.

Napilnik ★★★★★
()
Ответ на: Ага... от anonymous

А вот сейчас они (типы данных) так и скачут... Так и скачут... То int'ом, то float'ом прикидываются...

А int это сколько байт;)

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

Кстати да, раз уж начинается веселье. FAQ говорит, что «int X() { int i; return i; }» скомпилируется в «ret i32 undef». Значит ли это, что для x86 и x86_64 будет разное представление long long (и как следствие проблемы с переносимостью даже без ассемблерных вставок)?

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

у меня нет претензии к llvm как средствам анализа, реализации opencl (как было замечено кем-то вверху) и тд. внесу чоткости что меня бесит:

source-based дистрибутивы и так прекрасно работают. внутреннее представление данных в gcc используется только в gcc и не развивается в другую сторону => надежно. а из llvm делают монстра. любой его чих скажется на clang => ненадежно

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

Хммм...

Значит ли это, что для x86 и x86_64 будет разное представление long long (и как следствие проблемы с переносимостью даже без ассемблерных вставок)?

Странно, но всё же — http://software.intel.com/en-us/articles/size-of-long-integer-type-on-differe...

Если повар нам не врёт, ой, простите, Intel, то:

If it is important to you for integer types to have the same size on all Intel platforms, then consider replacing «long» by either «int» or «long long». The size of the «int» integer type is 4 bytes and the size of the «long long» integer type is 8 bytes for all the above combinations of operating system and architecture.

Цитата из ссылки выше.

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

тебе аватара мозг съела, добро пожаловать!

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

Мсье идиот? В детстве головой об пол роняли?

На уровне машинного кода можно делать только очень немногие, крайне примитивные оптимизации. Бегом курить хотя бы dragon book, лошара!

Кстати, для разминки, ознакомься с тем, на каком уровне промежуточного кода и какие оптимизации делает gcc. Очень удивишься.

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

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

Еще один идиот. Паскаль компилируется в один проход благодаря особенностям синтаксиса. Оптимизировать же в один проход его невозможно. Ознакомься, лошара, с темой. Даже банальный liveness analysis, без которого эффективно переменные по регистрам не раскидаешь, требует более одного прохода по CFG. Я уж не говорю про что-то более серьезное, типа SSA-преобразования, constant propagation и агрессивного DCE.

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

Батенька, вы дебил. Клинический.

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

с точки зрения пользователя что llvm есть его нет - глазу не заметно

Недоумок.

Пользователь llvm и clang - это программист. А ему очень даже заметно: более качественные сообщения об ошибках, возможности кросс-модульной оптимизации (включая глобальный DCE, это даже в последних gcc с его недоделанным LTO глючит адски), множество полезных пассов для анализа кода, унифицированное представление промежуточного кода, модульная архитектура, тупой как пробка plain C API и все такое прочее, чего в gcc никогда уже не будет.

anonymous
()
Ответ на: Дык! от anonymous

Linux IA-32 4, Linux Intel 64 8, Linux IA-64 8, но мне это не мешает как-то. :)

А если тебе надо класть в int числа возможно занимающие больше 4 байт и ты не хочешь устраивать глюки пользователям 32 битных платформ, тогда тоже не мешает?

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

Недоумок. Ты не понял, что такое llvm. Он от gcc отличается ровно по одному пункту : там, где у GCC множество разных промежуточных представлений, у llvm оно всего лишь одно. Все остальные различия на фоне этого несущественны. И, кстати, gcc тоже умеет сериализовать в биткод свое промежуточное представление (см. LTO). Только у него это херово получается.

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

llvm - байткод который выполняется эффективнее чем распространяемые бинарники собранные один раз и для всех => очевидно что llvm-байткодный дистрибутив ожидает нас

IMXO пока никто не переводит критичные к скорости участки сишных проектов на байткод виртуальной машины,
даже наоборот - критичные к скорости участки проектов под Java или Андроид(dalvik) переписывают на С и компилируют - почему?

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

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

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

выложен только llvm байткод и он автоматически оптимизируется под каждую платфому

Это невозможно. Биткод платформозависимый.

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

Кстати да, раз уж начинается веселье. FAQ говорит, что «int X() { int i; return i; }» скомпилируется в «ret i32 undef». Значит ли это, что для x86 и x86_64 будет разное представление long long (и как следствие проблемы с переносимостью даже без ассемблерных вставок)?

Вот тебе статья http://habrahabr.ru/post/81222/ Как-то велосипедят, используют не все байты переменной. Ты думаешь отчего пишут «игра X требует под хренью N Гб оперативы, под вистой - N+1».

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