LINUX.ORG.RU

Вышел LLVM 3.1

 


0

5

После 6 месяцев, прошедших с выпуска LLVM 3.0, представлен очередной релиз проекта LLVM 3.1. LLVM (Low Level Virtual Machine) — универсальная система анализа, трансформации и оптимизации программ, реализующая виртуальную машину с RISC-подобными инструкциями. Может использоваться как оптимизирующий компилятор этого байткода в машинный код для различных архитектур либо для его интерпретации и JIT-компиляции (для некоторых платформ).

Некоторые изменения:

  • значительно расширена поддержка C++'11 в компиляторе Clang;
  • AddressSanitizer — инструмент для поиска ошибок работы с памятью, позволяющий обнаруживать типичные ошибки при программировании на Си и Си++, такие как выход за границы буфера и т.п.;
  • в генератор кода добавлена поддержка так называемых «связок инструкций», позволяющих значительно повысить качество генерируемого кода для архитектур процессоров VLIW;
  • улучшена работа MIPS и ARM бэкенда;
  • помимо основных функций, этот релиз включает в себя улучшение производительности, исправление ошибок и другие усовершенствования.

Напоминаю, что LLVM позволяет компилировать программы написанные на языках С, C++, Objective-C, Fortran, Ada, Haskell, Java, Python, Ruby, JavaScript, GLSL или любом другом, для которого реализован front-end. В рамках проекта разработан фронтенд Clang для языков C и C++ и версия GCC, использующие llvm в качестве бэкенда. В Glasgow Haskell Compiler также реализована компиляция посредством llvm, существует ещё множество программ, использующих данную инфраструктуру.

>>> Подробности

★★★★★

Проверено: tazhate ()
Последнее исправление: thelonelyisland (всего исправлений: 2)
Ответ на: комментарий от wota

Fff..ck!

Прошу прощения туплю уже не по-детски. Все. Хорош на сегодня. Я — домой. Можно же было бы от размера регистра посчитать.

Еще раз прошу прощения.

anonymous
()

LLVM позволяет компилировать программы написанные на языках...Ada

Ого, появился компилятор что ли?

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

int64_t либо gmp

Но полностью отказаться от использования int тебе не дадут. Вот пишут стандаты, пишут, разные учёные люди их оценивают а на выходе получается такое... С законами понятно - распильное лобби мешает думать правильно, а в ЯП наверно тоже, кто-то загоняет налево неучтённые байты оптом и в розницу.

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

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

Интересно, где учат искать логические ошибки многократной компиляцией? А алгоритм смотреть нет смысла? Граничные условия назначать? Логи вести, отладочные сообщения в конце концов?

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

По моему, ничего олее велосипедного не придумать. А потом еще в релизе включить флаги оптимизации и получить нерабочее поделие...

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

wota ответил.

Я, просто в дороге сейчас.

Но у меня тогда встречный вопрос. Сейчас gcc по максимуму использует архитектуру того процессора, под который собирается код. Да-да, это и указание native или сборка в кросс-компиляторе. RTL позволяет. «Использует по максимуму» означает что gcc отталкивается, например, от размера регистра для того же int. Да и вообще для простых типов данных.

А вот в java например, всем пофигу какая там длина слова. Проблем с таким подходом не хапнем? А то лично мне пофиг рост производительности для питона или хаскеля. Мне бы производительность С не потерять...

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

Не уверен

что jvm/clr или более высоко или низкоуровневые аналоги это правильно.

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

мой коллега-анонимус

заблуждается. Компилятор ada с версии gcc (ЕМНИП) 3, введен в дерево gcc. Называется gnat.

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

Интересно, где учат искать логические ошибки многократной компиляцией?

«С нами поживёт, позеленеет.»(С)

А алгоритм смотреть нет смысла?

Ага, 10 потоков занимаются сексом в реальном режиме времени - смотри засмотрись.

Граничные условия назначать?

Всего не предусмотришь и ошибки в константах тоже могут случаться.

Логи вести, отладочные сообщения в конце концов?

Логи могут превратиться в километры, тормоза при их написании могут изменить выполнение алгоритма зависимого от времени, думай потом: «поменялось/непоменялось, вот в чём вопрос». А для отладочных сообщений 10 компиляций как раз и есть самое то:) Посмотрел на сообщения, понял чего нехватает, дописал, посмотрел и так далее, пусть железо пашет.

По моему, ничего олее велосипедного не придумать. А потом еще в релизе включить флаги оптимизации и получить нерабочее поделие...

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

Napilnik ★★★★★
()
Ответ на: wota ответил. от anonymous

А вот в java например, всем пофигу какая там длина слова. Проблем с таким подходом не хапнем? А то лично мне пофиг рост производительности для питона или хаскеля. Мне бы производительность С не потерять...

Там просто типов данных очень мало - вот вам один тип строк, одна кодировка и пишите на них коммерческие приложения.

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

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

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

вот так меня обзывают. спасибо. я не говорил что код будет платформонезависимый. насколько я помню я говорил о том что в рамках платформы x86_64 при компиляции этого промежуточного байткода будет использоваться максимально расширенный набор инструкций в частности заикнулся о sse4. в качестве пруфа я хотел бы показать вот эту ссылку: http://nondot.org/sabre/LLVMNotes/InlineAsm.txt где черным по белому написано:

Many inline asms are very stereotyped. Inline asm is commonly used for atomic memory access, use of instructions (like popcnt or ctlz) that don't have a direct C analogue, etc. It would be better to raise these to LLVM code and intrinsics where possible. This is particularly important for the JIT, which will not understand inline asm blocks.

т.е. если использовать интрсинков из http://llvm.org/docs/LangRef.html#intrinsics то решать использовать программную или аппаратную реализацию той или иной функции будет компилятор байткода на этапе JIT. аппаратная реализация интрсинка зависит от поддежки конкретных инструкций процессором

а теперь заглянем в исходник llvm: http://llvm.org/svn/llvm-project/llvm/trunk/utils/TableGen/X86RecognizableIns... и что же мы видим:

It contains the implementation of a single recognizable instruction

а внутри файла сплошь и рядом можно встретить инструкции sse3 sse4 mmx и тд. ну комментировать что-то дальше я считаю излишним

punya ★★
()
Ответ на: Хммм... от anonymous

Прошу прощения, на автомате и тут заменил long на long long. Речь была о первом, который по логике будет i32/i64 в зависимости от платформы.

Ладно, лишь бы работало, а то 3.0 не всегда отличает создание переменной от вызова функции. Правда при этом удивляется собственному поведению и выдает варнинг. Рефлексирующий такой компилятор )

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

где я неправ

На эту тему есть шикарный коан.

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

Профессор следил за тем, как переполняется чашка, и, наконец, не выдержал: «Она же переполнена. Больше уже не войдет!» «Так же, как эта чашка, — сказал Нан-Ин, — Вы полны Ваших собственных мнений и размышлений. Как же я смогу показать Вам дзэн, если Вы сначала не опустошили Вашу чашу?»

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

внутреннее представление данных в gcc используется только в gcc и не развивается в другую сторону => надежно

частный велосипед => надёжно, попытка сделать универсальный инструмент => ненадёжно.

И где тут логика?

а из llvm делают монстра

а из GCC его сделали вскоре после рождения, что и является основной претензией к нему.

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

тут начнуться проблемы типа «не компилится байткод»

то есть проблемы «не компилятся сорцы» никого не смущают, к проблемам с зависимостью тоже привыкли, проблемы «программа падает с сегфолтом/выбрасывает исключение» тоже, а тут вдруг трагедия?

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

а вообще как обычно они релиз подогнали к WWDC 2012 чтобы его успели прибить к Хкоду и показать народу какие они молодцы

Boy_from_Jungle ★★★★
()

а вообще где можно глянуть насколько он крут по сравнению с гцц, только наверное на их оф сайте)

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

имхо считаю что универсальный инструмент ненадежно. сосредоточились бы чисто на clang - было бы и просто и надежно

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

Как убийцу бекэнда gcc. А с фронтендами его же он очень неплохо дружит.

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

Ты баран совсем обдолбан? Интринсики выбирает frontend (clang или gcc), в зависимости от целевой платформы. По этой причине (в частности) биткод не переносимый.

А теперь для барана персонально, вопрос на засыпку: в чем принципиальная разница между LLVM IR и GIMPLE?

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

решать использовать программную или аппаратную реализацию той или иной функции будет компилятор байткода на этапе JIT

И еще, тупицо: при компиляции C/C++/ObjC/OpenCL никакого JIT нет в принципе, как нет его и в GCC.

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

Добавлю: интринсики могут и промежуточными пассами оптимизации вставляться (в частности, instcombine), для чего целевая платформа прописывается в модуле.

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

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

Советую почитать что-нибудь про компиляцию. Тогда может не будешь писать такие глупости.

tensai_cirno ★★★★★
()
Ответ на: И... от anonymous

целая куча промежуточного байткода. Просто gcc его не показывает.

... Вы его видите? Он Вам чем-то мешает?

Мне ничем не мешает. Я пытаюсь возразить на фразу «llvm + jit компиляция = программа может оказаться быстрее только если машинный код ущербен» показывая тот факт что gcc тоже «грешит» промежуточными представлениями.

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

Ты думаешь отчего пишут «игра X требует под хренью N Гб оперативы, под вистой - N+1».

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

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

llvm - байткод который выполняется эффективнее чем распространяемые бинарники собранные один раз и для всех => очевидно что llvm-байткодный дистрибутив ожидает нас

Вобще-то llvm - байткод никогда не декларировался как переносимый. Более того- он таки не переносимый о чем разработчики llvm чесно предупреждают. Кроме того в любом случае LLVM JIT абсолютно попарабану на файл <limits.h> с которым скомпилирована программа на С

yurkis
()
Ответ на: комментарий от Apple-ch

@ Apple-ch:

А где бы почитать, про компиляцию программ на скриптовых языках с помощью llvm? Нагуглить почему-то удаётся лишь всякую фигню: обёртки для апи и т.д.

www.rubymotion.com - коммерческий компилятор ruby в натив x86 и arm для платформы Apple iOS (для симулятора - x86 и устройств - arm). Очень активно поддерживается и развивается...

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

я нигде не говорил что он переносимый. я не виноват что вы читаете между строк то что вам хочется прочитать. я говорил про свою платформу x86_64 и то что llvm будет пытаться использовать самые расширенные инструкции процессора. и я не отказываюсь ни от одной фразы что выше сказал. лимиты и прочие платформозависимые вещи используются на первом этапе компиляции в байткод и я этого этапа нигде не касался. я сравниваю машинный код собранный для x86_64 и llvm байткод собранный для той же платформы x86_64

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

Ты пробовал ? жанга работать без магии (или с ней) будет ?

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

rubinius

Слышу звон, да не знаю где он. Вы рубиниус пробовали? Или только потому что он на LLVM, назвали его? :)

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

Ну ты придурь. Ты этого байткода не увидишь вообще, точно так же, как ты не увидиь GIMPLE в GCC. Что clang c llvm, что gcc выдадут тебе более-менее одинаковый машинный код.

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

когда компилируется байткод llvm он пытается использовать расширенный набор инструкций для текущей архитектуры. обычный машинный код будет ограничен стандартными инструкциями. пруф я писал выше

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

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

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

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

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

Странное желание класть в тип из 4-х байт, числа больше 4-х байт...

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

Слухи преувеличены...

... несколько. Всё-таки, насколько я понимаю, в llvm gcc можно использовать как front-end.

Тут же предлагают LLVM как убийцу GCC.

На мой взгляд, тут в другом проблема. /* Да, я упорот в хлам. */

Вот сами посудите — у виндарасов есть их CLR, у джавовцев есть их JVM. А мы-то что, рыжие что ли? Давайте и мы свою vm побыренькому сгоношим, такую чтоб лоу-левел и не иначе. Этакий свой велосипед, самый велосипедистый из велосипедов. Это проблема «моды» на некоторые решения, а не реальной необходимости. Ведь, пока я например не увидел конструктивной критики того же gcc окромя обвинений в монструозности.

Неясным только остаётся вопрос — а что бы не воспользоваться существующим решением в виде gcc? Там вроде законодательно не запрещено создать свой front-end и, как следствие, синтаксический анализатор для практически любого из существующих языков? Или качество выхлопа компилятора после уже существующего back-end'а не кузяво? Хочется именно в vm? Ну, не вопрос. Вэлкам...

С другой стороны, набор после первого взгляда на него, заставил прослезиться от хохота... Clang Static Analyzer! Отлично! Чуваки до сей поры не открыли для себя splint? Address-sanitizer... Уууу! Да чуваки не открыли для себя ни valgrind, ни electric fense...

Но это-то ещё пол-беды. Вот тут интереснее что будет с такими говноподелиями как (например) bitrix. Там контент (тексты, заливаемые юзерами) хранятся в виде php-файлов. Да, вот такая странная CMS, которая требует MySQL, но хранит там минимум всего. Мне просто интересно как будет выглядеть всё это php-llvm в таком случае. В конце-то концов практическая ценность всего этого какая-то предвидится или это очередная развлекуха для нердов из Apple?

anonymous
()
Ответ на: Слухи преувеличены... от anonymous

Давайте и мы свою vm побыренькому сгоношим, такую чтоб лоу-левел и не иначе. Этакий свой велосипед, самый велосипедистый из велосипедов. Это проблема «моды» на некоторые решения, а не реальной необходимости. Ведь, пока я например не увидел конструктивной критики того же gcc окромя обвинений в монструозности.

Да, ты упорот и ты дебил. Этих самых VM внутри самого GCC есть несколько штук. LLVM отличается от GCC только тем, что у него эта VM одна и унифицированная, примерно идентичная GCC GIMPLE. Все остальные VM, используемые в GCC, по большому счету лишние и без них все проще, как практика llvm и показывает.

а что бы не воспользоваться существующим решением в виде gcc

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

Там вроде законодательно не запрещено создать свой front-end и, как следствие, синтаксический анализатор для практически любого из существующих языков?

Там это на пару порядков сложнее и извращеннее делается, чем с llvm.

Clang Static Analyzer! Отлично! Чуваки до сей поры не открыли для себя splint? Address-sanitizer... Уууу! Да чуваки не открыли для себя ни valgrind, ни electric fense...

Ты тупое быдло. Если не понимаешь, чем лучше иметь доступ к AST непосредственно, то тебя близко к программированию подпускать нельзя.

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

Забейте.

вот так меня обзывают.

Именно забейте. Это просто Интернет... Не более.

ну комментировать что-то дальше я считаю излишним

А тут пока комментировать что-то не получится. Мало статистики. Ну да, там Apple использует... Где-то, как-то. Ну вот чего-то для фряхи гондобят... Посмотрим во что выльется. Не исключено что через некоторое время народ будет плеваться ото всего этого.

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