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)
Ответ на: комментарий от devl547

The C backend has numerous problems and is not being actively maintained. Depending on it for anything serious is not advised.

* The C backend has only basic support for inline assembly code.

<<< это большая проблема при сборке многих пакетов

* The C backend violates the ABI of common C++ programs, preventing intermixing between C++ compiled by the CBE and C++ code compiled with llc or native compilers.

<<<< мне она попалась при сборке какого-то кодека,

* The C backend does not support all exception handling constructs.
* The C backend does not support arbitrary precision integers.

<< возможно попадалось, но не слишком часто.

Вообщем как решат проблемы с inline, математикой и registry pressure, то соберется не то что 90% , а почти все, кроме совсем уж заGCCированных пакетов.

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

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




/////////


тарболла DragonEGG пока нет, но должны будут выложить на днях,
равно как и тарболлы остальных субпроектов


/////////

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

Пока что самого важного они добились: на выходе получается достаточно семантической информации, можно интегрировать в IDE

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

это релиз кандидат, rc0 или rc1


Sylvia ★★★★★
() автор топика

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

buddhist ★★★★★
()

Как называется та часть LLVM что может запускать байткод на лету? Для каких аппаратных платформ реализовано? Читал год назад, тогда писали что x86 и x86_64. Есть ли возможность запускать байткод без перекомпиляции на Linux x86, ARM, MIPS и т.п.? Сколько места занимает такая пускалка?

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

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

KLEE

в 2.8 в KLEE значимых изменений нет.

Sylvia ★★★★★
() автор топика

А интересно, вот если распространять программы в llvm-байткоде, то это же должно быть очень выгодно. Будет оптимизация под процессор, как в генту, но не будет длительной компиляции.

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

> Это все такой же тормознутый трактор?

Вы давно из криокамеры? Сборка быстрее как минимум в полтора раза

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

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

для запуска байт-кода его не надо интерпретироват налету

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

> Будет оптимизация под процессор, как в генту, но не будет длительной компиляции.

Не все виды оптимизации могут быть выполнены: только микрооптимизация

namezys ★★★★
()

>набора компиляторов LLVM , распространяемых по условиям BSD-подобной лицензии

Работают на дядю? Не одобряю

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

>это большая проблема при сборке многих пакетов

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

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

>Не все виды оптимизации могут быть выполнены: только микрооптимизация

Ну так первичная оптимизация при компиляции в байт-код. Или как?

Кто-то вон говорит, что .NET под виндой с предкомпиляцией работает быстрее, чем нативный код...

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

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

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

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

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

ну и к сожалению для разработчиков LLVM основная приоритетная платформа - та за которую им платят, а основной спонсор известно кто, три из четырех изменений, которые помечены в заметках о релизе как наиболее значимые не реализованы на другие платформы, кроме Darwin x86/x86-64, в 2.8 хорошо хоть за ARM cерьезно взялись.... а вот Linux и *BSD для них неприоритетны

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

И icc его тоже не собирает, выходит дело? :(

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

> Ну так первичная оптимизация при компиляции в байт-код. Или как?

В частности, llvm наверно не сможет сделать inline подстановку. Или сгенерировать несколько прототипов функции, как это делается для оптимизации в ppc (где-то слышал).

А так. В пределах одного блока переставить регистры и операции - это запросто

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

Ну чтож поделать. Хоть это пилят. Но видать денег льют много - пилят быстро.

Да и АРМ яблокам нужен. яФона же на нем. И TV

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

ядро ? нет.
FreeBSDшники все пытаются собрать ядро чем-то другим, pcc, tcc, у них даже получалось, а linux собирается только GCC, или с патчами linuxdna - ICC (но может не работать)

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

Как я уже сказал выше, gallium-llvmpipe у меня работал жутко медленно. Хотя бенчмарки Clang'а действительно показывают, что код должен быть медленнее процентов на 10-15..

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

я не собирала, ядро с железками работает все-таки... страшно )

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

интересно, почему

хотя я даже не знаю что это такое

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

где вы такие бенчмарки брали и какой они давности?

gallium-llvmpipe не показатель, это часть мезы, там есть свои проблемы и оптимизации
gallium-llvm работает быстрее чем просто gallium (хотя и глючнее... во всяком случае r300 у меня)

если брать код общего назначения, Clang компилирует отнюдь не худший код чем GCC

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

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

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

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

про opencl
слайды http://llvm.org/devmtg/2009-10/OpenCLWithLLVM.pdf
видео http://devimages.apple.com/llvm/videos/OpenCLandLLVM.mov

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

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

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