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)

А никто не сравнивал скорость компиляции Clang, llvn-gcc и самого gcc (и еще, может быть, icc)? Не скорость исполняемого года, а именно скорость компиляции исходников.

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

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

clang, llvm-gcc, dragonegg

с остальным, цифры не приведу, но примерно вот так получалось, по скорости самой сборки (-O2)

icc > clang > llvm-gcc > gcc 4.1 - 4.4 > gcc-4.5 / gcc-4.5+dragonegg

хотя серьезного отрыва не было нигде, все в пределах погрешностей,при явном аутсайдерстве ядра gcc-4.5

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

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

template<int s> class A;
A<sizeof(int)> b;
вот и fail. Он прав

Стандарт C не устанавливает жестких правил на размеры int, long. Говорится лишь, что один должен быть не больше, чем другой, и т.д.

Компилируем int -> 4, long -> 4, - обычные размеры для 32-х разрядных платформ. Почти между всеми платформами, они совпадают.

Приложение компилируется для использования 32-х битных адресов, для 64-х разрядных архитектур используется они же (как это происходит при исполнении sparc32 на sparc64, x86 на x86_64). На 64-х разрядных архитектурах используются compat системные вызовы. Порядок байт преобразуется при исполнении байт-кода, где это нужно: изначально компилируется для наиболее распространенного порядка и преобразуется только на непопсосых платформах.

Понятное дело, это потребует некоторых ограничений на исходный код (например, не использовать специфичные системные вызовы, хотя это тоже решается; эмуляцией), но большинство приложений и так не использует специфичные для платформы возможности. Так что мешает-то?!

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

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

>Если взять размер в 4 байта, то на x86_64 мы не получим выигрыша.

Если взять 8 байт, то на x86 мы получим проигрыш.

Какой выигрыш? Если человек пишет sizeof(int), значит ему достаточно 4 байтов, и не надо ничего придумывать.

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

>а ведь кроме нее, есть еще проблемы с endianness (которая тоже может

закладываться в скомпилированную программу).

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

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

> Приложение компилируется для использования 32-х битных адресов, для 64-х разрядных архитектур используется они же (как это происходит при исполнении sparc32 на sparc64, x86 на x86_64). На 64-х разрядных архитектурах используются compat системные вызовы

Отсыпь :) Зачем такая поделка нужна? Уже сейчас можно легко запускать на x86_64 системе x86 софт без всяких llvm-ов? ;-)

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

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

Читал статью в LinuxFormat про LLVM, запускал обычный .ll файл как программу. KLEE... то вижу пишут что это интерпретатор, то тест-генератор... KLEE может быть как JVM - берем байткод и оно само позаботится чтобы все оптимизировалось и работало?

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

>Зачем такая поделка нужна? Уже сейчас можно легко запускать на x86_64 системе x86 софт без всяких llvm-ов? ;-)

Разговор о том, чтобы запускать байт-код на любой платформе

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

KLEE - виртуальная машина для выполнения байткода.
вместо JVM есть еще VMKit, он более ориентирован на Java, была еще VMKit .NET (но на нее тоже забили с 2.8)

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

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

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

Хм. То есть: транслятор байткода делает нативную программу, она работает неправильно из-за того, что была скомпилирована в байт-код на платформе с другой endianness, и это нормально?

tailgunner ★★★★★
()

к сожалению вышеперечисленные новшества реализованы в LLVM 2.8 только для платформ MacOSX x86 и x86-64

Кто платит, тот и музыку заказывает. Тревожно.

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

>не знаю как с «чистым» .ll

подозреваю, что «чистый .ll» ничего не знает (и знать не хочет) про размер указателя: http://llvm.org/docs/LangRef.html#t_pointer

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

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

>Хм. То есть: транслятор байткода делает нативную программу, она

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

на платформе с другой endianness, и это нормально?

Если напишешь совсем тупой транслятор байт-кода, то именно так он у тебя и будет работать.

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

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

>Но у некоторых пользователей Линукса и gcc не стоит. И живут люди.

...но таки шо же это за жизнь! Бедные пользователи Линукса и gcc...

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

>Но у некоторых пользователей Линукса и gcc не стоит

для DKMS теперь gcc (базовый) ставится даже в десктопной убунте.

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

Если мультиплатформности ни в каком виде не будет, то вердикт один - не нужен. Это говно будет тормозить почти все время по ходу работы программы.

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

>>Хм. То есть: транслятор байткода делает нативную программу, она работает неправильно из-за того, что была скомпилирована в байт-код на платформе с другой endianness, и это нормально?

Если напишешь совсем тупой транслятор байт-кода, то именно так он у тебя и будет работать.

Я вообще не напишу транслятор байт-кода. Но я думаю, что никто не напишет достаточно умный.

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

>Я вообще не напишу транслятор байт-кода. Но я думаю, что никто не напишет достаточно умный.

Достаточно умный уже есть, и я тебе его уже привел в пример - QEMU. Если стандартизировать интерфейсы и компилировать с оглядкой на многоплатформенную трансляцию, то может получиться совсем простой.

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

>Но видать денег льют много - пилят быстро.

Высокая скорость разработки - следствие, скорее, грамотной архитектуры проекта, нежели объёма вливаемых средств.

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

GMP 4.3.2 (небольшая, очень хорошо портабельная библиотека)
--enable-cxx i686-pc-linux
-O2 -march=pentium4 -fomit-frame-pointer

Clang 2.8:
user 0m57.425s
sys 0m10.401s


llvm-gcc 4.2.1-llvm-2.7:
user 0m56.161s
sys 0m10.267s

ICC 11.1:
user 0m56.096s
sys 0m13.139s

GCC 4.3.5-PRO(filed): простого нет, поэтому в аутсайдерах он точно не будет
user 0m50.826s
sys 0m9.005s


GCC 4.1.2 (RedHat):
user 0m52.443s
sys 0m9.243s


GCC 4.5.2-PRE(release):
user 0m55.408s
sys 0m9.792s

DragonEgg 2.7 (Gcc 4.5.2pre, тот же что и выше):

user 1m8.502s
sys 0m11.392s

в целом результаты очень близкие, GCC 4.3-PRO обошел по скорости с некоторым преимуществом, но оно должно нивелироваться если будет обычный GCC 4.3




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

KLEE - виртуальная машина для выполнения байткода

A major feature of klee is that it can produce a testcase in the event that it detects a bug

Просто testcase, не найти список поддерживаемых архитектур...

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

Ну это типа в сферической в вакууме теории.

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

>> Я вообще не напишу транслятор байт-кода. Но я думаю, что никто не напишет достаточно умный.

Достаточно умный уже есть, и я тебе его уже привел в пример - QEMU.

Кому нужна такая скорость...

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

ps: собирается оно вместе с llvm, тарболлов пока нет, взяла с svn... но т.к. llvm и clang я уже собрала и поставила, но пересобирать у меня сейчас большого желания нет )

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

>Кому нужна такая скорость...

О том-то и разговор - сделать попроще и побыстрее. И это реально ;)

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

те же что и llvm

OK, спасибо за консультацию. Куда становиться в очередь на запись в фанаты LLVM? ^_^

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

>>> Достаточно умный уже есть, и я тебе его уже привел в пример - QEMU.

Кому нужна такая скорость...

О том-то и разговор - сделать попроще и побыстрее. И это реально ;)

Пруф? Не говоря уже о том, что qemu - это не транслятор (хотя внутри у него есть транслятор).

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

>Пруф?

Ты уж определись с позицией - сначала говоришь, что невозможно, а вот после примеров цепляешься ещё за что-то, как утопающий за соломенку ;)

Не говоря уже о том, что qemu - это не транслятор (хотя внутри у него есть транслятор).

А что же он тогда?

Если тебе интересно исполнение программ пользовательского пространства, то пожалуйста: каталоги *-linux-user/, исполняемые файлы qemu-$arch (без system)

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

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

вот это не факт. вроде это как раз микрооптимизация (регистры, поток команд и тд)

что мешает оптимизировать 1 раз и запускать уже оптимизированное?

ты заранее знаешь, на каком процессоре это будет исполняться?

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

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

template<int s> class A; >A<sizeof(int)> b; >вот и fail. Он прав

Стандарт C не устанавливает жестких правил на размеры int, long. Говорится лишь, что один должен быть не больше, чем другой, и т.д.

А если спецификация шаблона template<> class A<4> и template<> class A<8> кардинально отличается?

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

> Кто платит, тот и музыку заказывает. Тревожно.

Хоть какая-то музыка играет. и то хорошо

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

> Если напишешь совсем тупой транслятор байт-кода, то именно так он у тебя и будет работать.

ой. У нас прямо ИИ получается, а не транслятор. За программиста думает

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

>> Пруф?

Ты уж определись с позицией - сначала говоришь, что невозможно,

Моя позиция может измениться под влиянием ранее неизвестных мне фактов.

а вот после примеров

Каких примеров? Волшебного слова «qemu»? Это не пример. Пока что никто не показал: 1) пригодность внутренних алгоритмов qemu для статической компиляции; 2) в случае истинности 1, возможности достижения сгенерированным кодом производительности, равной производительности кода, сгенерированного gcc.

цепляешься ещё за что-то, как утопающий за соломенку ;)

Так пруфлинк будет или нет?

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

>А если спецификация шаблона template<> class A<4> и template<> class A<8> кардинально отличается?

Тогда нефиг писать int. Указывайте размер явно в типе: int8_t. Если ты пишешь int и закладываешься на его точный размер, то это некроссплатформенная программа. А некроссплатформенное написание на языке высокого уровня без явной нужды к этому - быдлокодерство. Типа того.

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

> Достаточно умный уже есть, и я тебе его уже привел в пример - QEMU

Не правда. Это интерпетатор. Полного транслирования невозможно. Или возможно с большими пенальтами для производительности, и только для специфичных языков (например, в которых задан заранее порядок байт).

Да и я привел пример, где ни какой транслятор не справится.

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

> А некроссплатформенное написание на языке высокого уровня без явной нужды к этому - быдлокодерство. Типа того.

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

Еще пример. Код, который разбирает побайтово представление float point'а. Тоже зависит от платформы, хотя может быть скомпилирован в байт-код

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

для сравнения еще:

llvm-gcc 4.2.1-llvm-2.7:
user 0m56.161s
sys 0m10.267s

llvm-gcc 4.2.1-llvm-2.8:
user 0m58.749s
sys 0m9.944s

быстрее не стало)

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

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

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

>Моя позиция может измениться под влиянием ранее неизвестных мне фактов.

Вот это правильно.

Пока что никто не показал:

1) пригодность внутренних алгоритмов qemu для статической компиляции;

OMG, преобразование байт-кода в код целевой платформы - это статическая компиляция? А разработчики LLVM уже знают об этом?

2) в случае истинности 1, возможности достижения сгенерированным кодом производительности, равной производительности кода, сгенерированного gcc.

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

Так пруфлинк будет или нет?

Смотри бенчмарки с жабой. Для интерпрайза её скорость вполне приемлима. Так что за это можно побороться.

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

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

Во первых - как минимум возможность низкоуровневой оптимизации на целевой платформе.

Во вторых - llvm это не только компилятор C/C++

Смотри бенчмарки с жабой. Для интерпрайза её скорость вполне приемлима.

Жаба язык с заранее определенными ограничиными возможностями. В отличае от С

namezys ★★★★
()

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

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

>Не правда. Это интерпетатор. Полного транслирования невозможно. Или возможно с большими пенальтами для производительности, и только для специфичных языков (например, в которых задан заранее порядок байт).

Неправда. В QEMU есть TCG - Tiny Code Generator, который ускоряет подряд идущие куски кода.

Но у QEMU и исходные данные другие. Вообще говоря, они могут быть произвольными. А в нашем случае мы сами подготавливаем их оптимальным образом.

Да и я привел пример, где ни какой транслятор не справится.

Какой?

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