LINUX.ORG.RU

Вышел LLVM 2.8

 , , , ,


0

0

Спустя полгода активной разработки анонсирован выход версии 2.8 набора компиляторов LLVM , распространяемых по условиям BSD-подобной лицензии UIUC. Одновременно вышли и обновления подпроектов LLVM: компилятора C/C++ — Clang, модифицированной версии GCC 4.2.x (использует LLVM для генерации кода) — llvm-gcc, плагина для GCC 4.5 (и выше) — dragonegg.

Наиболее значимые изменения:

  • в основной проект вошел отладчик LLDB;
  • другим дополнением проекта стала замена libstdc++ — совместимая с C++0x стандартом библиотека libc++;
  • LLVM Machine Code (MC) — подсистема для поддержки ассемблирования, дизассемблирования и обработки бинарных форматов файлов (подробности в блоге);

    К сожалению, вышеперечисленные новшества реализованы в LLVM 2.8 только для платформ Mac OS X (x86 и x86-64).

  • llvm-diff для семантического сравнивания .ll-файлов.

В числе других изменений можно отметить:

  • оптимизация внутренних функций работы с памятью;
  • более эффективная отладка за счет генерации метаданных для отладчика в режиме реального времени;
  • более эффективная оптимизация циклов, вложенности функций (inlining), -loweratomic pass;
  • Clang теперь поддерживает ключи -momit-leaf-frame-pointer, -ffunction-sections, -fdata-sections;
  • значительно улучшен аллокатор регистров (особенно для -O0), возможен выбор алллокатора (в зависимости от ключа -O) при использовании ключа -regalloc=default, также будет задействованы SSE-регистры;
  • множество процессор-специфичных оптимизаций для платформ ARM и x86 (SSE, AVX, NEON).

Просмотреть полный список изменений (также по ссылке доступен и список нерешённых проблем выпуска).
Ознакомиться с материалами конференции разработчиков LLVM, прошедшей перед выпуском.
Загрузить source-tarballs.

>>> Сайт проекта

★★★★★

Проверено: hibou ()
Последнее исправление: MuZHiK-2 (всего исправлений: 3)

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

>Кстати, оффтопик. .NET приложение под винду запускается из одного бинаря на x86 и IA64 без перекомпиляции?

«без перекомпиляции» для .NET - неоднозначный термин.

Если в бинаре нет unmanaged кода — перекомпиляция в байткод не нужна. JIT-компиляция байткода в натив будет в любом случае (она в run-time делается).

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

>Т.е. получается, что если все виндовые приложения и сама винда будут на .NET (чего вроде и хотят МС), то винда спокойно взлетит на ARM вместе со всеми фотошопами?

Да. Но см. выше про требование 'managed-only'. Т.е. переписать придется _весь_ код.

Sectoid ★★★★★
()

в тарболле не убрали RC с номера версии ;)

$/usr/local/llvm-2.8/bin/llc --version
Low Level Virtual Machine (http://llvm.org/):
llvm version 2.8rc
Optimized build.
Built Oct 6 2010 (12:26:18).
Host: i386-pc-linux-gnu
Host CPU: penryn

Registered Targets:
cpp - C++ backend
x86 - 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64
$/usr/local/llvm-2.8/bin/clang --version
clang version 2.8 (branches/release_28)
Target: i386-pc-linux-gnu
Thread model: posix

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

Во голова. Я это смотрел, но уж не помню. Спасибо

А раньше ведь был маленький и захудалый llvm. А теперь вырос с большой проект

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

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

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

>Зачем?

Он красивые warningи и errorы рисует, подсвечивая конкретное место в строке.

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

> Если в бинаре нет unmanaged кода — перекомпиляция в байткод не нужна.

Не совсем так. В assembly может и не быть managed кода, но она может быть помечена как x86 и не будет запускаться на .net64.

Это обычное явление когда на 64-битной windows стоят одновременно два .net 32 и 64 бита.

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

а когда туда добавят openmp, gcc можно будет хоронить

Там уже есть компилятор Фортрана, реализующий хотя бы 95-тый стандарт и могущий потягаться в продуктивности с gfortran или g77?

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

> WinForm вроде же есть уже. WPF нету.

не знаю. но можно же сделать. хотя кака вроде

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

>> Или проще говоря - хочу чтобы программа работала на Linux с любой архитектурой.

Это не возможно пока большинство программ написано на C/C++. Часть
информации о платформе (типа sizeof(long)) используется при компиляции
в байткод. Соответственно изменить эти значения для уже странслированной
программы невозможно.

С размерами указателей проблемы нет. Ведь работают 32-х разрядные программы на x86_64

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

Linux им пока не собирается?

Нет и не будет нормально собираться, скорее всего. Какие-то приложения собрать будет можно, но само ядро и большинство других --- нет. Это бздатый компилятор для бздунов и макосников, развиваемый на деньги Яббла. GCC в этом отношении ничего не угрожает.

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

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

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

> Там уже есть компилятор Фортрана...

Я бы ещё больше сказал. BSD - нет пути! Опять какие-то предатели дела GNU за копейку продали свой труд корпорациям. Опять это их дело, но они опять поддержали их а не нас.

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

дело в том , что проект очень активный, на Си они не забили, но решают пока другие проблемы, Obj-C++ например )

Давайте уж говорить правду и не лукавить. Они делают то, за что Яббл им платит, а для Яббла важно Objective-C++. Вот они его и пилят. А сделать чисто сёвый компилятор лучше GCC им всё равно вряд ли удастся. И уж тем более они не потащат реализации Фортрана, Ады и Паскаля. Им это не нужно.

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

Только почему оно сейчас генерирует более медленный код, чем gcc?

Если вы сравниваете сишный код --- отвечу: потому что это не целевой язык. Им важно Objective-C++ в первую очередь. Там у них особых конкурентов среди свободный проектов нет. Рассматривать LLVM как перспективный C/C++ компилятор и тем более как замену GCC --- неразумно.

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

естественно они делают то, за что им платит главный спонсор, Си они тоже не кинут, потому что Эппл от GCC будет избавляться, и Си компилятор им все равно нужен, в 2.8 они постарались выкинуть libstdc++ , Си и Си ++ не так просто вот взять и выкинуть, он нужен, это не Фортран , не Ада и не Паскаль



И (тут на ЛОРе не было) - Эппл прекратил отдачу кода разработчикам GCC
http://www.opennet.ru/opennews/art.shtml?num=27924

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

> С размерами указателей проблемы нет.

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

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

> Кстати, оффтопик. .NET приложение под винду запускается из одного бинаря на x86 и IA64 без перекомпиляции?

Да, и даже на mono запускается во многих случаях.

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

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

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

>Рассматривать LLVM как перспективный C/C++ компилятор и тем более как замену GCC --- неразумно.

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

ну и BSDшники все «в праведном негодовании» грозятся тоже выкинуть GCC )

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

> Давайте уж говорить правду и не лукавить. Они делают то, за что Яббл им платит, а для Яббла важно Objective-C++

Яблоку важен C, C++ и надстройка в виде objective-c ver 2

То есть вот это и пилится.

Лучше, хуже - это будет мало кого волноваться, когда достигнуть паритета в производительности. А вот в удобвстве использования он уже лучше

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

> то винда спокойно взлетит на ARM вместе со всеми фотошопами?

Если .NET портируют на ARM со всеми возможностями (включая тот же разрекламированный WPF), то да. При условии, что будут использоваться только MSIL-библиотеки.

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

> Информация о размере указателей теряется при трансляции C -> llvm bytecode.

template<int s> class A;

A<sizeof(int)> b;

вот и fail. Он прав

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

Странно, у меня на r300 обычный gallium работает в 3 раза быстрее (проверял на постобработке изображений с GLSL).

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

> Им важно Objective-C++ в первую очередь.

Им важен objective-c. А он зависит прямо от С

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

Си они тоже не кинут, потому что Эппл от GCC будет избавляться

Никто и не спорит. Как Яббл скажет, так в этом проекте и будет. Это тем более говорит о том, что заменою GCC для пользователей альтернативных MacOs-X систем и не пахнет.

Си и Си ++ не так просто вот взять и выкинуть, он нужен, это не Фортран , не Ада и не Паскаль

На самом деле от Фортрана никак нельзя избавиться во многих случаях. Практически все серьёзные расчёты требуют компилятора F77 или даже f90, просто часто библиотеки уже идут скомпилированными и вы его не ставите. Но у некоторых пользователей Линукса и gcc не стоит. И живут люди.

Ада используется в NASA, для них это краеугольный камень, потому им LLVM тоже фиолетов. Думаю, есть и другие места, где она нужна.

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

Yareg> Т.е. получается, что если все виндовые приложения и сама винда будут на .NET (чего вроде и хотят МС), то винда спокойно взлетит на ARM вместе со всеми фотошопами?

Это будут ТОРРРРРМОЗААААА!

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

Это не возможно пока большинство программ написано на C/C++. Часть информации о платформе (типа sizeof(long)) используется при компиляции в байткод. Соответственно изменить эти значения для уже странслированной программы невозможно.

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

Я правильно понимаю, что мы должны рассматривать LLVM как некую абстрактную целевую платформу, со своим sizeof(int) и т.п.? Если так, то тогда все становится на свои места.

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

>что заменою GCC для пользователей альтернативных MacOs-X систем и не пахнет.

*BSD, они во всяком случае стремятся и будут стремиться, другое дело, что проплатить «программисто-часы» работы у них не получится настолько хорошо , насколько это делают Apple-Google-Qualcomm

F77 или даже f90, просто часто библиотеки уже идут скомпилированными и вы его не ставите


у меня гента, фортран нужен был только для lapack (который теперь заменили на clapack), впрочем спорить что Clang/LLVM вытеснит что то их специализированных ниш в самом деле глупо, речь о generic системе (desktop/LAMP сервер)

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

> Если скомпилированная программа в байткод будет работать только на этой же платформе...

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

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

> со своим sizeof(int) и т.п.

Если взять размер в 4 байта, то на x86_64 мы не получим выигрыша. Если взять 8 байт, то на x86 мы получим проигрыш. Плюс сломаются все сишные программы, которые *уже* написаны с учётом разницы в размере int.

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

dimqua> Из вашего утверждения следует, что разработчики FreeBSD дурачки

Разве это не так? Помнится даже Линус Торвальдс матерился, когда код FreeBSD посмотрел.

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

> Это тем более говорит о том, что заменою GCC для пользователей альтернативных MacOs-X систем и не пахнет.

clang важен не столь, как компилятор, а как анализатор исходника, который можно интегрировать в xCode

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

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

ну как минимум оптимизация под процессор

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

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

JIT, например, можно делать.

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

I-Love-Microsoft> Тогда я ровным счетом не понимаю зачем нужен LLVM.

Оптимизации на лету.

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

cruxish> Хм, на лету? Как вы себе это представляете? :)

Умный JIT

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

> Я правильно понимаю, что мы должны рассматривать LLVM как некую абстрактную целевую платформу, со своим sizeof(int) и т.п.? Если так, то тогда все становится на свои места.

llvm - это скорее большая библиотека для быстрого написания трансляторов для чего угодно.

Она состоит из трансляторов C/C++/Obj-C (aka clang), генераторов машинного кода, интерпретаторов/jit-компиляторов, оптимизаторов и так далее.

Каждый компонент можно использовать более-менее независимо.

Внутри llvm использует промежуточное представление в виде некоего абстрактного ассемблера. Это представление можно сохранять на диск (в виде текста либо двоичных данных), хранить в памяти в виде C++ объектов.

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

Sylvia, они меня запутали все тут :)

«LLVM can provide the middle layers of a complete compiler system, taking intermediate form (IF) code from a compiler and outputting an optimized IF that can then be converted and linked into machine-dependent assembler code for a target platform.»

Стало быть IF это machine-independent код. Меня чисто из практического интереса волнует, могу ли я написать программу, откомпилировать в байткод, затем запустить ее на произвольном Linux-железе с установленным <что из байткода оптимизирует и делает бинари и кэширует надеюсь> и все будет работать?

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

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

Это примерно как демократия и материальное благополучие

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

> Хм, на лету? Как вы себе это представляете? :)

Грузим бинарь. Смотрим - байт-код. Оптимизируем. Пишем резальтат в кэш. Запускаем

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

> Грузим бинарь. Смотрим - байт-код. Оптимизируем. Пишем резальтат в кэш. Запускаем

Только мне кажется, что такая «оптимизация» будет сливать по скорости тому же -mtune?..

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

не знаю как с «чистым» .ll , но KLEE должна позволять это делать, вопрос конечно насколько это оправдано будет, по сравнению с уже собраным кодом под платформу...

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