LINUX.ORG.RU

LLVM 3.0

 , ,


1

4

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 ()

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

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

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

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

Ну понятно, если пытаться реализовывать то, что не понимаешь вляпаешься со 100% вероятностью. :)

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

Ну кто им мешал генерить не x86 асм, а для llvm

То, что они генерят и перегенерируют асм постоянно. Насчет пригодности LLVM для Python хорошо было написано в посмертной записке Unladen.

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

Это же LLVM, он низкоуровневый, т.е., распараллеливанием он не занимается.

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

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

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

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

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

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

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

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

Сколько пользуюсь STL, на ошибки в нем вроде не наталкивался. Хотя, конечно, некоторые моменты сделаны не лучшим образом.

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

Он используется как промежуточное представление: LLVM API дает возможность генерировать только байт-код, который только потом можно скомпилить (не сохраняя байт-код на диск).

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

Сколько пользуюсь STL, на ошибки в нем вроде не наталкивался.

Вот, кстати, да. Правда я не так уж интенсивно пользую C++/STL, но из личного опыта - STL вполне надёжен.

Вот про Boost не скажу ни за, ни против - на практике не использовал, только немножко поковырялся по собственной инициативе.

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

Ошибаешься. Компиляция (любая современная) состоит из таких этапов:

1. Препроцессинг, синтаксический анализ и прочие (здесь LLVM не при чем).

2. Генерация промежуточного кода (этот и последующие пункты входят в компетенцию LLVM)

3. Оптимизация промежуточного кода.

4. (и только здесь производится оптимизация кода под архитектуру) Генерация нативного кода (она еще делится на кучу этапов, но не суть).

Такая схема не только у LLVM, а почти у всех.

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

А зачем изобретать велосипед

Спросите у фанатиков :)

С++, написанный моими кривыми руками

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

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

Вот в случае надобности такое распараллеливание должно делаться LLVM-ом при компиляции байткода в нативный код.

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

LLVM-код сам по себе никак не прибит к endianess.

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

Втянули меня в этот спор :) Вообще автоматическое запаралелливание в том виде о котором мы сейчас говорим не синоним оптимизации, оно редко кому нужно в компиляторе. Оно только увеличивает суммарное количество операций которые нужно выполнить программе. А выполнение нескольких инструкций за такт это уже стадия компиляции в native код.

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

Этот самый адрес сгенерирует LLVM при компиляции байт-кода в нативный код. Зачем он до этого?

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

С размерами и смещениями работает LLVM, а не фронтенд.

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

Не обязательно. Распараллеливание теоретически может происходить и на этапе оптимизации, только, дейтсвительно, поближе к трансляции в нативный код. Правда зачем оно нужно не знаю =).

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

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

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

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

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

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

Ну ты и хам, так мою работу обзывать!!!

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

Байт-код LLVM, к сожалению, не является платформено-независимым. Некоторые вещи LLVM определяет при формировании кода, так-то разрядность, размер int,word и т.п. Ну и Big/Litle Endian. Это вам не Java, и не C#. Кстати, информацию о том, что LLVM-байткод не может служить кросс-платформенным представлением программы для различных аппаратных платформ был в официальных доках на сабж. Байт-код сабжа собранный в Linux под x86_64 отлично компилируется/интерпретируется в Winodws под ту же аппаратную платформу, но заглохнет на ARM. Всё из-за того, что желая по максимуму использовать все особенности поддерживаемых архитектур, компилятор сабжа в баткод засовывает и дополнительную информацию. Ну а определять размер int и прочих примитивных типов данных равными стандартным для данной аппаратной архитектуры - это преступление. В Java и .NET типы данных одного размера для любой архитектуры. Поэтому у них нормальная виртуальная машина, истинно кросс-платформенная, а разрабы LLVM испортили такую идею.

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

В Java и .NET типы данных одного размера для любой архитектуры. Поэтому у них нормальная виртуальная машина, истинно кросс-платформенная, а разрабы LLVM испортили такую идею.

То есть размер указателя там всегда 32 бита?

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

да кто мешает комилятору генерировать код с учетом этого? тогда будет кроссплатформенно. Это не задача llvm

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

как? младший арифметичски байт может как быть младшим, так и старшим по адрессу. А значит выбирать не так рпосто

namezys ★★★★ ()

[trollmode]Круто, теперь можно взять исходники любой открытой или не очень виндодиректной игры и компильнуть под линукс! Да хоть фотожоп с сонивегасом, если кто сырцы сольёт. LLVM преобразует WinApi в LinApi и дело в шляпе.[/trollmode]

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

Я обычно извлекаю биты так: (unsigned_number >> bit_num) & 1

Т.к. оно работает с числами, то пофиг, как эти самые байты размещены физически.

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

А в LLVM еще проще, т.к. там есть целые числа любой длины.

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

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

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

Т.к. оно работает с числами, то пофиг, как эти самые байты размещены физически.

ну я об это и говорил. а вот если через массив чаров тянуть

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

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

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

И да, вы не поверите, но «passing bу name» абсолютно ничего не меняет.

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

читали эту статью, думаете она ни с того ни с сего появилась?

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

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

PyPy в принципе другая вещь, чем LLVM.

конечно другая, PyPy - реализация ЯП, LLVM - backend

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

это почему? и с недавних пор - это года с 2000?

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

Насчет пригодности LLVM для Python хорошо было написано в посмертной записке Unladen.

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

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

PyPy - реализация ЯП

PyPy - это нечто большее.

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

это почему?

Я уже сказал, где это разъясняется.

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

PyPy - реализация ЯП

PyPy - это нечто большее.

???? пруф или не было

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

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

это почему?

Я уже сказал, где это разъясняется.

ссылочку не подкинешь?

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

просто в байте биты «номеруются» с 1 до 8. А вот в слове хер знает как

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

Ну а младший бит как был a & 1, так им и останется. Девятый бит тоже остаётся (a & 0x100) >> 8 — порядок слов на порядковых номерах битов не сказывается.

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

Так, значит я всё же правильно помнил основные тезисы.

Первый тезис, и самый главный: The primary reason is that we weren't able to generate enough internal customers at Google. То есть если бы не это любые вопросы можно было бы порешать.

Едем дальше, читаем про llvm.

1) «Unfortunately, LLVM in its current state is really designed as a static compiler optimizer and back end.» - не нашёл кнопку «сделать хорошо».

1) «LLVM code generation and optimization is good but expensive.» - WTF??? и что?

2) «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.» - снова не нашёл кнопку «сделать хорошо», отличная тема, чо.

3) «LLVM will not fold loads from the Python stack across calls to external functions (ie the CPython runtime, so all the time). We eventually wrote an alias analysis to solve this problem, but it's an example of what you have to do if you don't roll your own code generator.» - плачется и говорит что порулили, чего тогда плакался, снова не нашёл кнопку?

4) «For example, LLVM doesn't really support back-patching, which PyPy uses for fixing up their guard side exits. It's a fairly large dependency with high memory usage, but I would argue that based on the work Steven Noonan did for his GSOC that it could be reduced, especially considering that PyPy's memory usage had been higher.» - верните кнопку, скоты!

5) .... всё, это все претензии к LLVM?

Мой вердикт таков - чувак думал что LLVM - это страшное колдунство и если его запустить то оно автоматом все проблемы ему порешает. Ну чо, наивный малтшик, не в курсе что означают две первых L в слове LLVM.

Только я не пойму как это доказывает тезис «LLVM если и подходит для динамических языков, то только с недавних пор»? И ещё больше я не пойму, Unladden Swallow - это что, единственный динамический язык на свете, других не бывает?

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