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

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

Я вообще не понимаю, нафига нужна переносимость такой штуки как KLEE; вместо ява-апплетов есть NaCl + че-то вроде FatBinary. (и да, жду аппаратного запрета по любым переходам, не кратным 16, с помощью флажочка дескриптора сегмента/страницы)

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

Но если кому-то и вправду нужны, пусть фиксируют разумные размеры целого, endianness и вперед.

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

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

Так количество звездочек как раз означает обратное.

LLVM bytecode - это промежуточное представление внутри LLVM - оно не предназначено для того, чтобы с его помощью писать некий «compile once, run everywhere» код

Так я и говорю, что это говно не нужно в таком виде, как оно сейчас существует

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

Если бы макинтошники умели бы писать нормальный код, как в линуксе, ничего подобного им не нужно было.

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

;)

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

Красноглазые аналитики не нужны. Я тебе привёл два примера, где LLVM нужен, аргументов у тебя нет. Пока.

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

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

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

Статическая компиляция - это без запуска программы.

А разработчики LLVM уже знают об этом?

Да.

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

Нет, и даже некроссплатформенный код сейчас сливает обычной компиляции.

Хотя бы по это причине никто не напишет «умный» компилятор байт-кода.

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

Смотри бенчмарки с жабой.

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

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

f2c спасет тебя от компилятора фортрана. фортран уже давно стал read-only языком

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

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

Так я и говорю, что это говно не нужно в таком виде, как оно сейчас существует


Почтенному знатоку стоит выйти на публику с предложением об упразднении tree-ssa в исходниках GCC, ибо говно. О результатах докладывать не надо, мы отсюда услышим.

Если бы макинтошники умели бы писать нормальный код, как в линуксе, ничего подобного им не нужно было.

Eсли б ещё Линукс ком б на десктопе был нужен... А то прям не код, а эквивалент неуловимого Джо, такой из себя нормальный.

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

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

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

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

На эшафот!

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

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

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

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

В таком случае, написавший char *foo = ... - калека. Нормальные люди пишут struct bar *foo = (struct bar *) ... и не тратят потом время на отлов кучи багов.

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

Компилятор D для LLVM будет включен в Fedora 14.

Мы знаем. Но это компилятор D1, а этот язык уже устарел и не имеет никакой перспективы.

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

А зачем?

А зачем все эти велосипеды? Только из-за лицензий? Чем GCC так плох, что его пытаются заменить всем вот этим?

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

Таки да, фортран еще юзабелен) И, в принципе, не собирается сдавать позиций. Писать числодробилки на нем в разы приятней.

buddhist ★★★★★
()

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

Мда. Сразу видно, новость не читали... А почему же тогда MC сплошь и рядом используется на elf-платформах? :)

Ознакомиться с материалами конференции разработчиков LLVM, прошедшей перед релизом

Ну, если «перед» - это год назад, то да. На дворе вроде бы 2010 год, а не 2009.

anonymous
()
Ответ на: А зачем? от anonymous

А зачем все эти велосипеды? Только из-за лицензий? Чем GCC так плох, что его пытаются заменить всем вот этим?

Видите ли, Яббл хочет свой компилятор. У мелкомягких есть, а Ябблы вынуждены использовать GCC. Это не только бьёт по ЧСВ Жоббса, но и ставит их в прямую зависимость от других компаний, той же Красной Шляпы. Для удешевления разработки было решено прототип тестировать и разрабатывать силами красноглазых, лицензию, естественно, поставили BSD подобную, чтобы когда дозреет, полученный код успешно прихватизировать.

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

Вот, в общем-то и вся суть дела.

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

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

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

В чем отличие frontend'а от backend'а представляем? Или нет?

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

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

Ты что, смеёшься? Это же нельзя делать! Программу нужно обязательно разбивать на подсистемы, выделять подсистемы в библиотеки, компилировать их отдельно и помещать их в разные пакеты! Да, еще, чтобы этим всем управлять - нужен пакетный менеджер. Только тогда наступит щастье. Ведь если исправят баг в библиотеке, этот баг исправится во всех программах, использущих библиотеку! Вот о чем надо думать.

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

> Вот, в общем-то и вся суть дела.

Спасибо за разъяснения

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

дорогой анонимус, задайте этот вопрос Кристоферу Латтнеру, это с него копипаста

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

>> icc ... 90% пакетов собирается

о_О ничего не перепутал?

хотя на 64 может быть...

анабиозник?

Из того, что не собирается (вернее, собирается, но некорректно работает) - glibc. Ядро - с небольшими правками (в основном - дополнением соответствующего compiler.h). А что не собирается-то icc (хоть 32, хоть 64 битное)?

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

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

Открою тебе секрет: sizeof(int) == 4 и на x86, и на x86_64

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

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

icc - лучше не сравнивать. Это угрёбище на каждый запуск (считай - на каждую команду «icc бла-бла-бла...») читает пременный среды, в которых указаны пути к каталогам, где могут находится файлы с лицензией, ищет эту лицензию читает её, проверяет, и только потом может что-то скомпилирует.

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

тем не менее работает оно вовсе не медленно

хотя у меня лицензия лежит прямо в каталоге с бинарниками )

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

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

Я сравнивал, clang и gcc. Результат в пользу gcc 4.2 (чуть быстрее), и без PCH, и с PCH. Компилил свой «жосткий С++», использующий Boost, Gtkmm/Gtk.

Но что меня удивило - оно (собранное clang'ом) даже работает. :) Немного цифр тут - http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-September/011168.html

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

Короче говоря, счастья (= быстрой компиляции С++ в debug-режиме) не будет.

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

Видите ли, Яббл хочет свой компилятор. У мелкомягких есть, а Ябблы вынуждены использовать GCC. Это не только бьёт по ЧСВ Жоббса, но и ставит их в прямую зависимость от других компаний, той же Красной Шляпы. Для удешевления разработки было решено прототип тестировать и разрабатывать силами красноглазых, лицензию, естественно, поставили BSD подобную, чтобы когда дозреет, полученный код успешно прихватизировать.

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

Это всё проясняет.

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

> В таком случае, написавший char *foo = ... - калека. Нормальные люди пишут struct bar *foo = (struct bar *) ... и не тратят потом время на отлов кучи багов.

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

namezys ★★★★
()
Ответ на: А зачем? от anonymous

> Чем GCC так плох, что его пытаются заменить всем вот этим?

монолитностью

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

> интересно, есть ли в планах реализация кошерного runtime для Objective-C

нет. OpenStep только v1 и то тормоз

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

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

если удишевление - оплатить разработку, то тогда да

переход на clang имеет другие причины, я писал

namezys ★★★★
()
Ответ на: А зачем? от anonymous

IMHO:

1. LLVM/Clang написан на C++, а значит С++-ники не будут ощущать себя людьми второго сорта из-за того, что компилятор для них делают С-шники. Соответственно, и проблемы С++ лучше понимаемы и решаемы (легче договориться, ближе мировоззрение).

2. Конкуренция уж точно не помешает.

И да, хоть BSD-вая лицензия такая BSD-вая, но с GPL у LLVM нет никакого шанса,- в этом случае аргументов нужности LLVM было бы меньше (не нужен, есть же уже GCC, все то же самое же!). А тут хоть лицензия помягче, глядишь разработчики и набигут(c) .

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

> А тут хоть лицензия помягче, глядишь разработчики и набигут(c) .

Пример набигания: некто Douglas Gregor, активный разработчик библиотеки Boost, так «разбежался», что теперь Clang получил очень качественную поддержку C++98 (буст собирается Clang'ом без ошибок и без всяких хаков).

L_user
()

Зачем LLVM? Затем, что при помощи этой штуки можно писать оптимизирующие компиляторы haskell, Си, го, и прочего без постоянного изобретания велосипедов.
Алсо, clang требует меньше ресурсов компьютера.
А для переносимого байткода есть Dis из Inferno, nekoVM и другие, даже есть JVM и MSIL, если вы — извращенец.

anonymous
()

И да, Си++ отвратителен, но он повсюду.

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

на самом деле не важна конкретика (разве что как пример),
важен момент что можно разработчикам удалять внимание только разбору семантики фронтэндом и возможностям самого языка, а машинный код будет генерировать и оптимизировать llvm как универсальный бэкэнд для много чего. Конечно если брать тот же GHC, LLVM в бенчмарке пока остает от родных кодогенераторов ( в пределах 10% ), но ситуация будет меняться постепенно.

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

>А для переносимого байткода есть Dis из Inferno, nekoVM и другие, даже есть JVM и MSIL, если вы — извращенец.

Dis может быть без Inferno? А то неслабый такой «рантаймчик» получается для vm.

nekoVM - без jit-а, на каждый тред - по отдельной vm, ты-б ещё паррот посоветовал...

что-то негусто с выбором получается...

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

> Ну из-за BSD и apple набежала

Я имею в виду разработчиков, а не инвесторов (хотя важно и то, и другое). Например, если бы яббл вложился в еще одну базу данных, то это не значит, что набегание также бы произошло.

В современном IT-мире не все деньгами меряется, или, по-другому, бабло и разработчики часто ортогональны, особенно на таких «социальных» проектах, как компиляторы/интерпретаторы, дистрибутивы и прочее.

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

У меня 265 МБ ОЗУ, селерон и гента.
Собираю с использованием GCC — всё тормозит.
Собираю с использованием clang — всё тормозит гораздо меньше.
ЧЯДНТ?

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

> А то неслабый такой «рантаймчик» получается для vm. Ну так и ява не очень-то маленькая. (алсо, можно уладить всё лишнее же)

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

> Вот, в общем-то и вся суть дела.

А самое главное пропустил.

GCC по-наглому огорожен *в дополнение* к GPL.

Например, сделать GPL патч к GCC, чтобы он выдавал наружу какое-то внутреннее предстваление, типа GIMPLE, хотя и можно... но как у почтальона Печкина, выхлопом пользоваться будет *нельзя* совместно со стандартной библиотекой (без нее можно).

Тот же (прообраз) gcc-xml долгое время был незаконен по этой причине.

Естественно, нормальных людей такое ограждение не устраивает. ЛЮБЫЕ данные, которые получены в результате компиляции МОЕЙ программы, должны быть мне доступны для дальнейшей автоматической обработки.

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

> но как у почтальона Печкина, выхлопом пользоваться будет *нельзя* совместно со стандартной библиотекой (без нее можно).

И почему же?

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

это ограничение специально для жцц обсуждалось где-то подробно на lwn

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

> И почему же?

Потому что кто-то из FSF (не будем указывать пальцем) боитеся, что Нехорошие Пропраетарщики обойдут GPL и сам GCC методом «сделал выхлоп внутреннего представления жцц, а затем применил к нему пропраетарные Супер Пупер Оптимизации»

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