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)

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

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

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

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

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

> Раз нет платформонезависимого байт-кода, то это плохо.

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

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

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

Шикарно мы подготовили данные, полученный из бинарного файла...

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

Какой?

Хитрые шаблоны. Или побитовый разбор float point'а

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

> С того, что на другой платформе int может быть 8 килобайт, и на это закладываться нельзя. Читайте внимательней

А на третей платформе вообще if ветвления нет.

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

Дак они ещё сколько-то проходов (Pass) добавили. Явно скорости не прибавится =)

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

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

Польза сомнительна. Не так много приложений, которыми пользуешься в течении долгого времени. Мифическое ускорение будет нивелироваться тормозами на начальных этапах работы. Кроме того, нет особого желания, чтобы кеши постоянно засирались перекомпилированием libc

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

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

Для написания обычных приложений принципиальной разницы между ними нет.

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

> Мифическое ускорение будет нивелироваться тормозами на начальных этапах работы.

Да. Небольшая задержка при первом запуске приложения - это серьезно.

Тем более для плохочитающих сообщаю, что clang-llvm обычно генерит нативный код

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

> Для написания обычных приложений принципиальной разницы между ними нет.

Чукча не читатель, чукча писатель

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

>Шикарно мы подготовили данные, полученный из бинарного файла...

Ты подготавливаешь байт-код, который получается сборкой программы на языке C. Или ты на машинном языке сразу программируешь?

Хитрые шаблоны.

Тот пример с int, что ты привел, мы уже обсудили. Обсуждать по второму разу бессмысленно. Это не проблема.

Или побитовый разбор float point'а

Что ты имеешь ввиду?

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

>А на третей платформе вообще if ветвления нет.

Если бы у бабушки был бы х.й, она была бы дедушкой.

Давай конкретнее. Я говорю об обычных программах. Возьмем GNOME. В скольких его компонентах есть архитектурные вставки?

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

>Да. Небольшая задержка при первом запуске приложения - это серьезно.

Небольшие задержки -> плохая оптимизация => нахер.

Тем более для плохочитающих сообщаю, что clang-llvm обычно генерит нативный код

Тогда зачем это говно вообще нужно?! По тестам сливает, компилирует не все. Когда доведут до ума - будет совсем безбожно тормозить

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

я хочу в бинарном виде вытащить мантиссу из double. Делаю это просто. Беру double как последовательность байт, и читаю только нужные байты (на с 1 по 48 например)

на ppc это одно, на x86 это другое, на ARM это третье (может надо читать с 17 по 64)

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

где-то я постил у себя вывод gcc, когда я ошибся на один знак в шаболен

18 страниц вид:

a< vcxcv<char *, fdhjkdsf< jdsakld<sdjash<ashdfks<fdslkfj<int, fdhjkdsf< jdsakld<sdjash<ashdfks<fdslkfj<, fkdsjfld>, fdhjkdsf< jdsakld<sdjash<ashdfks<fdslkfj< fdhjkdsf< jdsakld<sdjash<ashdfks<fdslkfj< T>, f, s, d> >>>, fdhjkdsf< jdsakld<sdjash<ashdfks<fdslkfj> >

а всего-то вместо typdef a b я написал typdef a c;

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

>как только у тебя появляется адрессна арифметика, код перестает быть универсальным

Мы это уже обсудили. Будет также, как с порядком байт

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

> я хочу в бинарном виде вытащить мантиссу из double

а зачем вы такими жуткими делами занимаетесь?

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

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

> Мы это уже обсудили. Будет также, как с порядком байт

Блин. Ага. Идет код:

char * a = from_hui_znaet();

я зову a[4], a[7], a[11] на х86

а на х86_64 надо звать a[8], a[11], a[19]

как компилятор догадается?

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

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

Ну так написано же, что это только у *некоторых* пользователей линукса... ;)

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

если использовать библиотеки вида from_hui_znaet() глючить будет на всех платформах и любых компиляторах

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

>char * a = from_hui_znaet();

я зову a[4], a[7], a[11] на х86

а на х86_64 надо звать a[8], a[11], a[19]

char. Ты уверен? Моя картина мира рушиться. Всегда думал, что char везде 1 байт фиксированно

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

> char. Ты уверен? Моя картина мира рушиться. Всегда думал, что char везде 1 байт фиксированно

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

может там лежит что нить типа struct { long a; char b; long c; char d; }

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

он имеет ввиду что «никто» не знает что возвращает функция from_hui_znaet() а указатель на char выбрано рандомно, ксожелению такие библиотеки действительно бывают

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

>а указатель на него ?)

void * a

;)

А указатели у нас всегда 32-х битные, как мы уже выше обсудили. Типы в название которых не зашит размер - на всех платформах одинаковые

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

>что char везде 1 байт фиксированно
Угу, щяззз. На каких-нибудь DSP и на некоторых архитектурах вполне себе может быть и не 1.
А ты представь ещё, что байт не обязательно восьмибитный...

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

> А если он по разному на разных платформах формируется?

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

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

>А ты знаешь, что там в этом буфере лежит. А если он по разному на разных платформах формируется?

может там лежит что нить типа struct { long a; char b; long c; char d; }

Размеры заранее оговорены. Так что нормально. Сложно с битовыми операциями, но тоже проходимо

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

>На каких-нибудь DSP и на некоторых архитектурах вполне себе может быть и не 1.

А ты представь ещё, что байт не обязательно восьмибитный...

Вешать еритиков за яйца

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

>> А указатели у нас всегда 32-х битные

вы отстали от жизни

Ну пожертвуем большими адресными пространствами ради переносимости. 3GB для пользовательского пространства - достаточно, усраться можно. Уже обсуждали выше

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

>И вводим новый язык. С-cross. И переписываем все с использованием его.

Для большинства программ не понадобится

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

а зачем жертвовать? если можно не жертвуя писать переносимый код, или вы считаете что 3GB хватит всем на всегда?

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

Ах да. Не понадобится... А кто будет гарантировать это. В общем бред некомпентентный

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

>а зачем жертвовать?

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

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

> А кто будет гарантировать это

платформо независимый код можно писать я гарантирую это! :D

to namezys

а зачем вы все таки извлекали мантису из double?

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

>из вас, извините, единственная пользу - увелечение энтропии

Зачем ты так говоришь? Ты же меня не знаешь. Слил, так слил, не расстраивайся ;)

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

>я не писал, я юзал

Юзал много таких 3 гигабайтных программ, прямо пачками? И все компилировал LLVM? И тебе нужно было, чтоб каждая была кроссплатформена?

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

>Ну пожертвуем большими адресными пространствами ради переносимости. 3GB для пользовательского пространства - достаточно, усраться можно. Уже обсуждали выше

щаз. GIS, google it! Для некоторой геотрахомудии - не достаточно. У меня даж пара самописных чисто числодробильных костылей больше жрут (один - 4, второй - 9.6). И это не лечится без жуткой потери производительности (матрица 33452х16726 double-ов, заменить ее не на что).

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

Значит не надо компилировать GIS с помощью LLVM. Он для других целей.

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

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

> Потому что это единственная польза, которую можно извлечь из говна под названием LLVM

2 звёздочки, а такой упоротый.

Ещё раз объясняю для тупых:

LLVM bytecode - это промежуточное представление внутри LLVM - оно не предназначено для того, чтобы с его помощью писать некий «compile once, run everywhere» код, для таких вещей есть Java bytecode и MSIL. GCC так же использует своё внутреннее представление при компиляции, с помощью которого back-end и front-end копилятора взаимодействуют. Принципиальное отличие LLVM от GCC в архитектуре. GCC - это большая монолитная программа, а LLVM - это модульная библиотека.

Попробуй из GCC выдрать C++ парсер, чтобы прикрутить к IDE.

Попробуй использовать GCC для динамической компиляции шейдеров в машинный код процессора (для эмуляции новых версий шейдеров без поддержки их видеокартой, как это делается в MacOSX)

Когда осилишь, можешь кричать, что LLVM не нужен ;-)

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

простой пример: logic + kontakt 3 + EWQL + 7 дорожек по 5.1

на 8 дорожке радостно сообщаем, что не можем выделить память

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