LINUX.ORG.RU

Вышел LLVM 2.2

 ,


0

0

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

Новое в версии 2.2:

  • генерация кода для процессоров Cell
  • экспериментальная поддержка преобразования Ada и FORTRAN через gcc-backend в промежуточное представление
  • поддержка типа long double на x86/x86_84 (80 бит) и Darwin PPC/PPC64 (128 бит)
  • поддержка более чем одного адресного пространства
  • в комплект поставки включены учебные руководства

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

★★★★★

Проверено: Shaman007 ()

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

Кто-нибудь пользовал? Какие впечатления?

dpkg ★★★★
()

>> поддержка типа long double на x86/x86_84 (80 бит) и Darwin PPC/PPC64 (128 бит)

А long long double сколько еще ждать ? и еще версия 2.2 ...

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

> а что с этим низкоуровневым представлением делать

генерировать из других языков (например, из языка шейдеров OpenGL, как это будет делать следующая версия Mesa), а потом переводить в код x86

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

> а потом переводить в код x86

Или не x86.

"static back-ends for the X86, X86-64, PowerPC 32/64, ARM, Thumb, IA-64, Alpha and SPARC architectures, a back-end which emits portable C code, and a Just-In-Time compiler for X86, X86-64, PowerPC 32/64 processors."

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

frontend'ы есть не только для C/C++, но и для Objective C, Ada, Fortran, Python, Stacker, Java и Scheme. В разработке LLVM D Compiler. Может есть еще для чего...

naryl ★★★★★
()

Почему в новости не указана лицензия?! Мне что поссылкам ходить?! Совсем ньюсмейкеры охренели!

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

> Почему в новости не указана лицензия?! Мне что поссылкам ходить?! Совсем ньюсмейкеры охренели!

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

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

> frontend'ы есть не только для C/C++, но и для Objective C, Ada, Fortran, Python, Stacker, Java и Scheme.

Т.е. вместо javac можно будет собрать прямо в промежуточный код, из которого преобразовать затем в нативный?

Хочу собраться Eclipse для Cell :D

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

> frontend'ы есть не только для C/C++, но и для Objective C, Ada, Fortran, Python, Stacker, Java и Scheme.

Лучше бы ты схему не вспоминал. Мало того, что сам компилятор - на mzscheme, так ещё реализовано настолько "узкое" подмножество языка, что о том чтобы сам себя сделал можно и не мечтать...

И к тому-же, данная "схема" не типизирована - итог: "в сад"!

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

Поищи - попадаются. Как сравнение скорости компиляции, так и выполнения полученной проги. По обоим параметрам llvm вроде впереди (а иначе зачем бы результат публиковать :), но у него есть один существенный минус: заточка под него большого проекта - всё равно что под отдельную платформу.

yyk ★★★★★
()

А на нем КС работает?

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

> А что, компилеры в нативный код нынче уже не в моде? Лавры дот-нета спать не дают?

Не совсем корректное сравнение. И Сановский и Микро$офтовский байткоды интерпретируются или JIT компилируются. Очень редко AOT компилируются. Они не предназначены для AOT компиляции. LLVM не просто так назвали Low Level VM. Прежде всего были написаны компиляторы из LLVM в машинный язык, а потом уже VM с JIT Compiler'ом.

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

> Прежде всего были написаны компиляторы из LLVM в машинный язык, а потом уже VM с JIT Compiler'ом.

В результате чего llvm чаще используется как альтернативный си-компилятор, а именно vm почти не используется - библиотека "из коробки", мягко говоря, _очень скромная_. И это таки получаются "два разных си".

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

> библиотека "из коробки", мягко говоря, _очень скромная_

Нужно дать ему немного времени на развитие. Повезет - все будет. Не повезет - gcc не так уж плох.

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

> Шоман, ну осиль уже spellchecker к браузеру прикрутить!

Ты что! Ты разве не знал, что настраивать что-то под МакОсью неджобсоугодно? А уж тем более, "прикручивать". Этим только красноглазые линуксойды-нищеброды занимаются :-)

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

>А что, компилеры в нативный код нынче уже не в моде? Лавры дот-нета спать не дают?

Ты когда-нибудь удосуживался выяснить, как работают оптимизирующие компиляторы? Да тот же GCC? Так вот, значительная часть оптимизации происходит на уровне p-кода.

AsphyX ★★★
()

Плядь, мало того что новости вечно с ошибками, теперь еще и теги

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

> Ты когда-нибудь удосуживался выяснить, как работают оптимизирующие компиляторы? Да тот же GCC? Так вот, значительная часть оптимизации происходит на уровне p-кода.

Не-а :D P-код - это код абстрактной машины, а оптимизация в GCC производилась раньше над RTL (который _не является_ P-кодом), а сейчас - над GENERIC/GIMPLE, который тоже не является P-кодом (это древовидное представление программы, AFAIK).

tailgunner ★★★★★
()

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

HP
()

так, как я понимаю, llvm можно рассматривать как c-компилятор, со своим оптимизатором. а где бы бенчи результатов компиляции llvm vs. gcc посмотреть?

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

> Нужно дать ему немного времени на развитие. Повезет - все будет. Не повезет - gcc не так уж плох.

Так речь не о си-компиляторе, а о vm как кросс-платформе для конечных приложений, а не составляющей самого компилятора. Без либ vm - 0. А развития именно vm-ных либ я и не наблюдаю.

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

> Ты разве не знал, что настраивать что-то под МакОсью неджобсоугодно? А уж тем более, "прикручивать"

:) в Mac OS X проверка орфографии в текстовых элементах (контролах) вообще-то изкаропки :)

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

>По обоим параметрам llvm вроде впереди (а иначе зачем бы результат публиковать :), но у него есть один существенный минус: заточка под него большого проекта - всё равно что под отдельную платформу.

Хм, а почему его нельзя рассматривать как альтернативный gcc компилятор (если всякие фишечки VM не использовать, просто компилить в нативный код)?

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

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

anonymous
()

что-то сильно большой у них список Known problems для релиза с номером 2.2..

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

> Хм, а почему его нельзя рассматривать как альтернативный gcc компилятор (если всякие фишечки VM не использовать, просто компилить в нативный код)?

Почему нельзя - именно так чаще всего и используют :)

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

>Почему нельзя - именно так чаще всего и используют :)

Тогда непонятно, зачем затачивать? У него каких-то фич не хватает или реализованы по-другому, нежели в gcc?

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

> надеюсь лучшие идеи войдут в gcc

Тогда это уже будет не gcc, а gllvm.

ИМХО llvm - шаг в правильном направлении, а gcc - топтание на месте.

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

были же всякие EGCS которые потом слились с gcc, надеюсь и тут обкатают какие-то вещи и преобразуют gcc, идея то вроде верная

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

> Тогда непонятно, зачем затачивать? У него каких-то фич не хватает или реализованы по-другому, нежели в gcc?

У него "окружение" тоже собственное (линковщик и т.д.) и всё это вкупе не 100% совместимо с gcc. Как результат - "в лоб" большие программы не собираются. Посему каждый отдельный случай сборки того или иного проекта с помощью llvm на их форуме встречается с большой радостью.

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

В LLVM обещали interprocedural optimization, которую трудно делать. если окружение в коде целевой платформы и не может модифицироваться во время исполнения программы. В LLVM окружение находится в промжуточном предствлении, которое может быстро JIT-компилироваться в машиный код (отсюда и VM). IO дает очень неплохой выигрыш в производительности.

Вообще, LLVM задумывался как framework для разработки алгоритмов оптимизации.

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

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

Я угадал, я угадал! :-)

Что, и на двух языках проверяет?

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

> :) в Mac OS X проверка орфографии в текстовых элементах (контролах) вообще-то изкаропки :)

Лучше бы она была из черепной каропки юзера.

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