LINUX.ORG.RU

LLVM 4.0.0

 ,


1

5

13 марта состоялся релиз LLVM 4.0.0. LLVM — это набор компонентов и технологий для создания трансляторов языков программирования.

Основные новые возможности новой версии:

  • экспериментальная поддержка сопрограмм (Coroutines in LLVM);
  • поддержка (пока экспериментальная) AVR включена в официальную версию и дальнейшая ее разработка будет происходить в основной ветви исходного кода LLVM;
  • соглашения о вызовах __vectorcall (разработано Microsoft) и __regcall (разработано Intel).

Также с 4.0.0 проект LLVM присоединился к гонке версий: новая схема номеров версий предусматривает увеличение мажорной версии с каждым новым релизом (т. е. следующий мажорный релиз будет 5.0.0); обновления к 4.0.0 будут нумероваться 4.0.x.

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

★★★★★

Проверено: jollheef ()
Последнее исправление: sudopacman (всего исправлений: 3)

новая схема номеров версий предусматривает увеличение мажорной версии с каждым новым релизом

лавров.жпг

В чем профит такой наркомании с версионированием? Кроме радости хипстеров, которые хотят каждую неделю «пробовать новую версию».

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

Престарелые эмокиды всё продолжели пердеть в сторону малолетних хипстеров, когда нормальным людям пофиг.

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

Вот это владельцам видеокарт амд было обидно.

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

Новость о LLVM - мини, новость о БаттхертОС - полная. Чего-то я не понимаю %)

Чего тут непонятного ― там исправлены три ошибки, а тут какая-то минорщина.

Deleted
()

Вопрос про корутины.

Правильно ли я понимаю, что ни корутины в MSVC ни в clang не используют пул потоков для фонового выполнения задач, а выполняются в том же потоке, в котором они были вызваны изначально? Т.е. не получится как в Go запустить goрутину, которая в фоне выполнит работу и вернет результат по окончанию (через promise, очередь или как-то еще). Вопросы про защиту от многопоточной работы с данными пока оставим в стороне.

Такое мнение у меня возникло, когда читал про LLVM Coroutines (по ссылке из новости), которые в результате оптимизации могут вообще исчезнуть.

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

Ты косячишь? Погасил звезду?

anonymous
()

Только 3.9.1 собрал. (Из-за clang-format.)

d_a ★★★★★
()

Ещё не открыл новость, но у меня уже было плохое предчувствие. Открыл. В начале новости всё тихо. Перематываю в конец... так и есть!

Зря. Помните GCC 4.0? Все заморочились и сделали код для него. Потому что смена первой цифры - это сигнал. А теперь способа дать такой сигнал не будет.

Я ещё понимаю Linux, там с 2.6 фундаментальных изменений не было. Но даже там мсжорная версия - это второе число. А тут - проект, который мутирует, как ДНК черепашки под мутагеном в сумме с гамма-излучением! Крайне неразумно было так делать

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

Я тоже в шоке. Хотел сам запилить новость, но ты меня опередил =)

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

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

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

LLVM релизится раз в пол-года и в каждом релизе ломает совместимость.

Как по мне, так штука очсложная, не удивительно что что-то ломают

AntonyRF ★★★★
()

Хм, я думал что тут уже обсудили, а я тупо новость прослоупочил, поскольку ебилды давно уже есть. А оказывается не я.

imul ★★★★★
()

Также с 4.0.0 проект LLVM присоединился к гонке версий

Когда же кто-нибудт из этих «гонщиков» додумается экспоненту использовать? «новая_нумерация» = exp(«старая_нумерация») - сразу бы всех обогнали.

мажорный релиз будет 5.0.0
обновления к 4.0.0 будут нумероваться 4.0.x.

Зачем тогда «0» посередине оставляют?

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

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

Thero ★★★★★
()

А они производительность компилятора не поправили? Или опять просадка будет?
А то в 3.8 и 3.9 такие жуткие регрессии произошли, что профита от шланга теперь нет. Собирает столько же сколько и gcc - в 2 раза дольше 3.7.

mine
()
Ответ на: комментарий от shkolnick-kun

активно пилят его, есть масштабное исследование на тему сборки ядра линукс им. Можешь в архиве llvm-dev@ почитать.

DELIRIUM ☆☆☆☆☆
()

Опять поломали все так что теперь ни один сторонний бэк не взлетит?

upcFrost ★★★★★
()
Ответ на: комментарий от shkolnick-kun

Помнится мне, его раньше хотели на мороз отправить ибо не кому было допиливать

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

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

Если честно, я не в курсе, я lld ваще не трогал, краем глаза видел обсуждения в рассылке, я по llvm/clang (и то, по одной подсистеме) и совсем чуть-чуть по lldb, а по lld, я даже не знаю, могу ли я туда коммитить (не проверял).

DELIRIUM ☆☆☆☆☆
()
Последнее исправление: DELIRIUM (всего исправлений: 1)
Ответ на: комментарий от mine

А то в 3.8 и 3.9 такие жуткие регрессии произошли, что профита от шланга теперь нет.

А шланг он вовсе не компилятор. Он backend для инструментов типа clang-format, синтаксического анализа и выдачи сообщений об ошибках компиляции и неопределенного поведения.

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

http://llvm.org/docs/Coroutines.html Корутины тупо делают быстрое переключение (сохраняют callee-saved регистры и некоторые флаги при начальном вызове или resume и меняют указатель стека), возвращают изменённый хендл после suspend. done проверяет закончилось ли выполнение.

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

anonymous
()

Блин, вот теперь сижу переписываю бэк. Начиная с 3.7 одна и та же функция сначала возвращала указатель, потом значение, теперь снова указатель. Вот нахрена эта моральная мастурбация? Еще веселее только с case-sensitive названиями. Блин, RemoveBranch и removeBranch - оно уже тоже раза три менялось.

upcFrost ★★★★★
()
Последнее исправление: upcFrost (всего исправлений: 1)
Ответ на: комментарий от anonymous

Не знаю как в llvm. В msvc коруьины работают через fiberы. API fiberов позволяет вроде запускать их в разных потоках и делать переключение на fiber созданный в другом потоке. Соответственно можно считать на коруьины в другом потоке и ждать ее через тоже вроде можно

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

Корутины тупо делают быстрое переключение (сохраняют callee-saved регистры и некоторые флаги при начальном вызове или resume и меняют указатель стека), возвращают изменённый хендл после suspend. done проверяет закончилось ли выполнение.

Это ты щас описал корутины boost::context, а в MSVC и clang именно так и не стали делать (https://www.youtube.com/watch?v=Ts-1mWBmTNE). Насколько я понял, корутина в версии от MS - это результат превращения функции в функтор C++ (локальные данные сохраняются в переменных объекта). Причем компилятор разбивает функцию на несколько частей (начальная инициализация, куски между co_yield) и при очередном вызове operator() (оно же coroutine_resume()) срабатывает диспетчер на switch(), который передает управление на метку, с которой нужно продолжить выполнение (а при вызове co_yield() индекс следующей метки сохраняется в переменные объекта). В результате такая корутина работает на одном стеке и для ее работы нужна поддержка компилятора.

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

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

У меня тоже создалось такое впечатление, но его придется делать вручную (в смысле по стандарту он не предусмотрен). Опять же эти корутины разрабатывались под Windows, а там completion ports сильно отличается от того, что есть в Linux и в результате, потребность в отдельном менеджере там сильно меньше.

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

В msvc коруьины работают через fiberы

Насколько я понял из https://www.youtube.com/watch?v=Ts-1mWBmTNE, виндовые корутины не используют fibers сами по себе (там сознательно отказались использовать fiber), однако, пользовательский код в этих корутинах вполне может запустить что угодно, в том числе и создавать fibers, нужные для их работы и выполнять их в фоновых потоках. (т.е. когда ты пишешь корутину, которая будет что-то загружать по сети, то она может создать fiber, thread, что угодно, инициализировать начало загрузки и далее работать в другом потоке, однако компилятор сам ничего не знает про fiber, когда генерирует код для корутины и ни к каким fiber его не привязывает). Но, возможно, я что-то не так понял.

IMHO, когда рассказывают про корутины в примерах в документации используют неудачные примеры - там везде примеры с генераторами (для которых никакие корутины не нужны, достаточно функтора). Гораздо интереснее, если бы они рассказали, как на корутине реализовать фоновую закачку по сети (Гор приводит код, но там про виндовый completion port, которому передают callback, и который я не понимаю кто и когда вызывает, в общем мне это осталось не понятно).

anonymous
()

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

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

В msvc коруьины работают через fiberы

Хотя с другой стороны, если корутины сами запускают fiber'ы и в них делают фоновую закачку, то чем они отличаются от обычных функций, которые возвращают future... Повторно вызывать ее тут совсем не нужно.

В общем, не догоняю я смысла этого творения от MS. Генераторы, которые любят использовать в примерах для корутин делаются с таким же успехом через функторы и для этого не надо в язык вводить три новых ключевых слова и заставлять компилятор преобразовывать функцию в функтор, а функции, которые возвращают future<> и что-то делают в фоне с помощью файберов не нужно вызывать повторно (т.е. опять же корутины тут не нужны).

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

По ходу ты прав, затупил файберов действительно нету. Т.к там stackless corutine. Но они были в await для msvs13))

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

которому передают callback, и который я не понимаю кто и когда вызывает

он вызывается где то из WinApi и в том callback делается resume корутине которая зделала co_await на соответсвующем awaitable

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

Блин, вот теперь сижу переписываю бэк

Никто и не переписывает. Итого каждый собирается со своей версией. Да и вообще, как-то сложно там все, туториалов для чайников не хватает. Короче как бы круто оно не выглядело, но реально лучше генерить си код и скармливать его gcc, чем связываться с этим геморроем.

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

Никто и не переписывает

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

Да и вообще, как-то сложно там все, туториалов для чайников не хватает. Короче как бы круто оно не выглядело, но реально лучше генерить си код и скармливать его gcc, чем связываться с этим геморроем.

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

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

Если стоит задача просто перегнать свой ЯП в бинарь, то разбиратся с LLVM assembly очень муторно, а генерить его сразу в виде структуры в памяти непортируемо между версиями. Вот и хочется плюнуть и сгенерить у себя на выходе текстовый си файл, который потом просто пропустить через gcc не задумываясь. Но да, согласен, задачи разные бывают. Не все программисты до сих пор болеют своим ЯП с блекджеком...

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

часть скриптом если изменения тривиальные, часть вручную

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

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

При чем тут свой яп? Вот ты под arm как, под каждую его вариацию собирать будешь компилятор? LLVM как раз хорош абстрактностью

Да и нафига тебе на выходе текстовый С если бинарь нужен?

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

нафига тебе на выходе текстовый С если бинарь нужен?

gcc из любого текстового С сделает бинарь же. И довольно неплохой по качеству к тому же.

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

gcc из любого текстового С сделает бинарь же

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

upcFrost ★★★★★
()
Последнее исправление: upcFrost (всего исправлений: 1)
Ответ на: комментарий от upcFrost

В принципе от языка зависит. Если суть твоего языка в том, чтоб добавить к С нормальные классы с интерфейсами и пропертями, модули и прочую модную синтаксическую сахарню (см. vala), то сомневаюсь, что существуют толковые оптимизации данного языка, которые gcc не сумеет применить по сишному выхлопу. Ну если язык совсем эзотерический типа хаскеля, то может быть да, можно придумать случаи, в которых генерировать машинные коды напрямую выходит производительнее, чем через Си. И то, думаю можно обойтись ассемблерными вставками.

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

Если суть твоего языка

я бэк пишу вообще-то. ну да ладно.

добавить к С нормальные классы с интерфейсами и пропертями

это у нас что, пачку define теперь языком стало можно назвать?

и кстати - ок, вот есть у тебя транслятор в C. а почему его нужно собирать gcc, а не шлангом?

upcFrost ★★★★★
()

llvm37-3.7.1_4.txz - 22 987 696 байтов

llvm39-3.9.1_2.txz - 216 339 864 байта

llvm40-4.0.0.r4.txz - 228 886 956 байтов

Компиляторы с каждой новой версией всё жирнее и жирнее...

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

Если стоит задача просто перегнать свой ЯП в бинарь, то разбиратся с LLVM assembly очень муторно

Если тебе с LLVM assembly разобраться сложно,то сделать свой ЯП вообще неподъемная задача

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