#LLVM news.

https://reviews.llvm.org/rG6a9487df73e9 - полезная проверка, что строки не конструируются от nullptr. Впрочем, начиная с С++2023 соответствующие конструкторы просто забанены.

llvm считает важным упомянуть вот об этом замечательном событии, и мы тоже, вслед за всем прогрессивным человечеством!

"The next Women in Compilers and Tools meetup will take place on December 9th. It will feature Sangeeta Chowdhary’s talk, Fast and Precise Approaches to Detect, Debug, and Repair Numerical Errors."

———
https://www.opennet.ru/opennews/art.shtml?num=56291 #yeswecan #provider

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

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

———
https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)

"every frame is perfect", ага.

1) Разработчики Firefox умудрились устроить мне мерцание даже в Wayland, хорошо заметно под нагрузкой.

2) Авторы Sway вообще не понимают, как надо делать композитор. При переключении рабочих столов они сначала рендерят frame, показывают его, а потом уже применяют накопившиеся(пока рабочий стол был скрыт) изменения к итоговой картинке. Это приводит к тому, что первый кадр всегда содержит stale данные. И, соответственно, к мерцанию.

Кстати, лет 10 назад, когда про Wayland еще никто ничего не знал, Я любил мне показывать фотографии вот этой замечательной женщины, когда я что-то искал на тему.

https://yandex.ru/images/search?from=tabbar&text=wayland%20susann

Так я и полюбил латекс.

https://www.phoronix.com/scan.php?page=news_item&px=More-Apple-M1-For-Linux-5.17

Вот тут вот пишут, что в ядро добавили еще больше M1. В mesa я никакой активности про драйвер не вижу, увы. И, если уж начал про mesa и аппаратное ускорение, то я осилил статически слинкованный opengl и аппаратно ускоренные драйвера в одном бинаре.

pg@:~/sources/mix ls -la /home/pg/mix/store/
106d22493865f8686a8eb38db12e4711
-b-shell-sway/bin/sway
-rwxr-xr-x 1 pg pg 206469240 Dec 10 17:10 
/home/pg/mix/store/
106d22493865f8686a8eb38db12e4711
-b-shell-sway/bin/sway
pg@:~/sources/mix strip 
/home/pg/mix/store/
106d22493865f8686a8eb38db12e4711
-b-shell-sway/bin/sway
pg@:~/sources/mix ls -la 
/home/pg/mix/store/
106d22493865f8686a8eb38db12e4711
-b-shell-sway/bin/sway
-rwxr-xr-x 1 pg pg 78393840 Dec 10 18:51 
/home/pg/mix/store/
106d22493865f8686a8eb38db12e4711
-b-shell-sway/bin/sway

Я думал, будет раза в 3 больше. Впрочем, я нашел интересный способ не линковать #LLVM в каждый бинарь.

https://docs.mesa3d.org/drivers/zink.html - реализация opengl поверх vulkan. #zink
https://www.opennet.ru/opennews/art.shtml?num=51026 - компилятор шейдеров от Valve, который не требует LLVM. Все #хорошее в графическом стеке Linux делают корпорации!

Совместно это дает ускоренный OpenGL, не зависящий от LLVM.

К сожалению, Vulkan мне пока не удалось завести. Разработчики Khronos Group - какие-то невменозы. Я тут уже однажды писал, что делают разрабы, когда у них заканчиваются задачи. Ответ - начинают их себе выдумывать на ровном месте. Вот это и делает Khronos Group. Мегабайты кода аццкого качества, задача которого - загрузить .so, экспортировать из нее функцию, которая вернет структуру, заполненную коллбеками(короче, интерфейс). Где-то там происходит нечто, из-за чего какой-то коллбек от драйвера становится nullptr, и все падает. Копипаста между разными репозиториями одного проекта, где-то заголовки используются из системы, в виде библиотеки, где-то их нужно положить рядышком, во время сборки. Разные репозитории имеют не совместимые друг с другом версии. Там 4 важных репозитория, если взять их последние релизы, они не совместимы друг с другом. У этих гондонов даже есть файлик с номерами ревизий, с которыми, типа, работает. Не с зарелиженными версиями, с ревизиями! https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob/master/scripts/known_good.json

Стык загрузчика от Khronos Group и кода Mesa - это жесть. Им там не хватает информации в передаваемых контекстах, поэтому там вовсю всякие пертредные хештаблицы со всякими недостающими запчастями.

Зато я впервые трассировал графический драйвер, это интересно.

Нашел странную упячку в Mesa - там есть шейдерный кеш, и там есть часть ключа в этом кеше, которая зависит от dl_iterate_phdr на какую-то определенную функцию в библиотеке(https://github.com/mesa3d/mesa/blob/main/src/util/build_id.c#L118). Мне кажется, они таким странным способом хотели сказать, что кеш нужно инвалидировать при смене версии библиотеки, очень интересным способом(название исходника как бы намекает на это).

Дело осложнилось тем, что на границе кода #Mesa <-> Khronos Group происходит потеря информации в возвращаемой ошибке, поэтому драйвер просто возвращал "не могу проинициализироваться", без указания из-за чего, и где. Кстати, как эта проблема решается в языках без динамических исключений, типа Rust, когда коллбек имеет более богатую ошибку, чем вызывающий код может прокинуть наверх?

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

#cross #cmake В CMake нет кросс-компиляции. Видимо, ее было сложно добавить постфактум(ну, не знаю, не глобальную переменную с набором environment завести, а сделать два экземпляра класса - для target, и для host). Вообще, добавить кросс-компиляцию в систему, которая для этого не дизайнилась изначально, сложно.

Ну и что же делать? Вот, вместо того, чтобы таки запилить кросс-компиляцию, товарищи запилили страничку, на которой, на голубом глазу, утверждают, что кросс-компиляция в CMake есть!

https://cmake.org/cmake/help/book/mastering-cmake/chapter/Cross%20Compiling%20With%20CMake.html

Конечно есть! Только вам надо 1 раз прогнать cmake, собрать все провалившиеся вызовы TRY_RUN, записать их предполагаемые результаты в файлик, и прогнать это говно еще раз!

https://cmake.org/cmake/help/book/mastering-cmake/chapter/Cross%20Compiling%20With%20CMake.html#using-compile-checks

Вдумчивый читатель спросит - а как в сборке запустить собранный host бинарь? А точно так же! Собираешь бинарь отдельно(твои проблемы, как), и подсовываешь его в cmake!

https://cmake.org/cmake/help/book/mastering-cmake/chapter/Cross%20Compiling%20With%20CMake.html#running-executables-built-in-the-project

Так же несколько раз по тексту эти господа прозрачно намекают на wine, qemu, и прочие достижения прогресса, чтобы TRY_RUN таки работал.

Я подумал, что это какая-то outdated хрень, но вот, пжалста, инструкции по кросс-сборке #LLVM:

https://bcain-llvm.readthedocs.io/projects/llvm/en/latest/HowToCrossCompileLLVM

-DLLVM_TABLEGEN=<path-to-host-bin>/llvm-tblgen
-DCLANG_TABLEGEN=<path-to-host-bin>/clang-tblgen

Удобные переменные, чтобы передать путь к заранее предсобранным бинарничкам, чтобы CMake не перенапрягся. Вообще, удивительно, что у программы, которая облегчила кросс-компиляцию в 100500 раз, такая отстойная кросс-компилирующая сборка.

"Cross-compiling is fully supported by CMake, ranging from cross-compiling from Linux to Windows; cross-compiling for supercomputers, through to cross-compiling for small embedded devices without an operating system (OS)."

Феерические долбоебы.

———
Ну и вот вам еще душераздирающих историй. У меня тут свалилась сборка glslang, компилятора шейдеров от Khronos Group. Эти негодяи попросту поменяли файл по релизной ссылке:

Было:

https://github.com/KhronosGroup/glslang/
archive/refs/tags/master-tot.tar.gz
f51c4b12ac0c8f9dee2067dc207a4fca

Стало:

md5sum master-tot.tar.gz 
71c7f379d1d73eebdce3fd05c7727af4
master-tot.tar.gz

Не, по ссылке(и по предыдущему опыту взаимодействия) было понятно, что ссылка не жилец, но все же. Кстати, к тому, что по github commit id данные часто приезжают с другим md5, я уже давно привык, это какое-то общее место.

https://groups.google.com/g/llvm-dev/c/HxXbT3qKYgg/m/kvNdxP0oAgAJ #maskray

Впервые с товарищем я столкнулся, когда он пришел в уютненький тредик про busybox style multicall binary для #LLVM(я очень ХОТЕТ). Он, соответственно, рассказывал, что это не нужно, и что это не дает перфа, и что размер не улучшится. Потом я узнал, что он один из авторов LLD, и ведет блог про линкер(не, реально, пишет много про линковку) - https://maskray.me/, правда, половина там на китайском. Короче, неудивительно, что человек, постигший все тайны динамической линковки не хочет оставаться не у дел, потому что статическая линковка проста, как 3 копейки. Пчелы против меда. Ульриха Дреппера про динамическую линковку не стоит слушать по той же причине(https://gavinhoward.com/2021/10/static-linking-considered-harmful-considered-harmful/).

Правда, потом он исправился, и даже зачинил несколько багов для multicall binary(ссылку не дам, лень искать).

А вот на днях он опубликовал пост про LLD, сравнение с #mold(кстати, Mold особенно хорошо идет с Rust, хехе), и все такое. Коллега совершает стандартную ошибку тех, кто не занимается перфом профессионально - он не делает прямых измерений(perf record), а только косвенные, и строит по ним предположения, как же работает программа.

https://maskray.me/blog/2021-12-19-why-isnt-ld.lld-faster

———
Short news - последнее время вместо HN я читаю lobste.rs, чего и вам желаю. Никакой политоты, только технически интересные штуки.

———
https://tom-kaitchuck.medium.com/designing-a-new-prng-1c4ffd27124d

Товарищ решил, что ему хочется не только посмотреть на срачик Мелиссы О'Нил и автора Хороширо, но и присоединиться к ним. Еще один PRNG.

Я однажды тоже запилил свой PRNG, он был норм, и по скорости, и даже проходил DieHard, Test01, и BigCrush, но у меня хватило ума не внедрять его никуда. Ну был он на 10% лучше, чем тогдашний конкурент? Но если что пойдет не так - не отмоешься же потом(как и произошло с автором Хороширо).

(срачик его с Мелиссой я уже в этом блоге кидал)

Небольшое продолжение про #systemd, конкретно, про #udev(который какого-то хера стал частью systemd).

https://github.com/illiliti/libudev-zero

"Another udev problem is non-portable home-grown language called "udev rules". Udev authors definitely don't know(or care) why it's better to avoid reinventing the wheel. Strictly speaking, I think they did that on purpose to overcomplicate udev as much as possible. Why? So that only authors(RedHat/IBM) can rule and dictate the future of udev. The recent eudev death only proves that it's really hard to support such unmaintainable mess."

Забавно, но я пришел к таким же выводам, весь этот ваш systemd - это классический vendor lock-in, со стороны IBM/RedHat.

———
https://lists.llvm.org/pipermail/llvm-dev/2021-December/154371.html #loongson

В #LLVM приземляют поддержку loongarch. Это ОЧЕНЬ странно. LLVM, на моей памяти, отказали почти ВСЕМ, в их желании поддержать новую архитектуру в LLVM. Их позиция - лучше меньше, но лучше. Почему этот принцип не сработал в данном случае, и кому занесли китайские товарищи(или на кого собрали компромат, хотя какой в современном западном обществе возможен компромат, когда все можно и все, что можно, - хорошо)?

———
https://justine.lol/sectorlisp2/

Lisp, на этот раз с GC, за 436 байта.

Еще ссылок от #Justine:

https://justinetunney.com/dox/unicode.html
https://justinetunney.com/endian.html

Хотел на ее примере написать что-то типа "вот есть же нормальные тетки-программисты, и без всяких этих ваших SJW-конференций https://www.youtube.com/watch?v=xOmQFBirbOg", а потом передумал.

Я ничо не понял, но, кажется, это, наконец, про porno + Deep Learning. 30 лет жду.

https://github.com/liaoxiong3x/DeepCreamPy (божечки, название просто огонь)

———
https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20211227/992076.html

С моим подходом к разработке запилить новый таргет в LLVM я не смогу никогда. Ну и вообще, документ какой-то "запретительный". Как-то это не круто - типа, сделайте всю работу, а мы подумаем, нужна ли нам такая архитектура, или нет.

———
https://devblogs.microsoft.com/oldnewthing/20211229-00/?p=106061

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

Узнал красивое:

"Indeed, there’s no requirement that the code bytes for the RemoteThreadProc function be contiguous at all! Profile-Guided Optimization will rearrange basic blocks, and the code for a single function may end up scattered across different parts of the program, depending on their usage patterns."

Оказывается, PGO умеет не только функции переставлять, но и отдельные блоки так, что код функции перестает быть непрерывным. Интересно, много ли это дает, и умеет ли #LLVM так.

———
https://www.phoronix.com/scan.php?page=news_item&px=Mesa-2021-Tops
https://www.phoronix.com/scan.php?page=news_item&px=Microsoft-D3D12-Mesa-SSBO
https://www.phoronix.com/scan.php?page=news_item&px=Mesa-22.0-Build-macOS-Zink

У #Mesa все хорошо. Microsoft коммитит в Mesa, Valve коммитит в Mesa. Впрочем, Microsoft не забывает и про альтернативу - https://github.com/microsoft/angle (ссылку я привел, чтобы показать, что MS контрибутит в #ANGLE, сама репа deprecated) Я так понимаю, Microsoft думает, как же у нее в дальнейшем будет устроен OpenGL over DirectX. #zink

———
https://www.opennet.ru/opennews/art.shtml?num=56429
https://www.phoronix.com/scan.php?page=article&item=kde-gnome-wayland21&num=1

Ни на грош не верю тестам от Phoronix, да и сравнение это, скорее, композиторов, а не технологий.

It is a shame, что, для того, чтобы игры не тормозили, в Wayland композиторе надо написать кучу кода.

https://www.phoronix.com/scan.php?page=news_item&px=Linux-Remove-a.out

Linux убирает поддержку a.out, придется в gcc -o давать какие-то более осмысленные имена, если вы понимаете, о чем я.

———
https://llvm.discourse.group/

#LLVM съезжает с допотопных рассылок. С одной стороны - это хорошо, в почтовых архивах решительно невозможно было ориентироваться. С другой - это какая-то закрытая платформа, я там не нашел кнопки "скачать письма за 2021 год".

———
https://www.opennet.ru/opennews/art.shtml?num=56503
https://github.com/chrisdutz/blog/blob/main/plc4x/free-trial-expired.adoc #money

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

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

———
https://venam.nixers.net/blog/unix/2021/02/07/audio-stack.html

Неплохой текст про состояние аудио стека в Linux.

https://github.com/jackaudio/jack2

The activation system has been changed for a data flow model and lock-free programming techniques for graph access have been used to have a more dynamic and robust system.

Класс. А это пример lock-free технологий из jack2:

    while ((err = snd_pcm_resume(handle)) == -EAGAIN)
      usleep(100);  /* wait until the suspend flag is released */
    if (err < 0) {
-

Слово usleep в кодовой базе встречается 50 раз.

При этом, jack все еще лучший звуковой сервер под Linux, все, как и 15 лет назад.

———
https://developers.redhat.com/articles/2022/01/12/prevent-trojan-source-attacks-gcc-12

Сначала создаем себе проблемы, потом героически их решаем. Не, так работы нам хватит навсегда.

Хотелось бы, конечно, флаг в компиляторах -fno-porridge -fascii-only-source, я более чем уверен, что есть сильная антикорреляция между тем, что человек использует эмодзи с какахой non-ascii symbols в коде, и тем, что его код может быть мне как-то полезен.

https://blog.ffwll.ch/2018/08/no-2d-in-drm.html

Недавно плакался, что для ускорения десктопа используется дорогущее и жрущее батарейку 3D железо. Хотя хватило бы блиттера и смешения по альфа-каналу.

Вот, объяснение, можно сказать, от самих разработчиков dri. Пишут, что 2D сложнее, чем 3D. Интересно, что он этим имеет в виду? Конечно нет, не сложнее. Просто не стандартизировано, в отличие от. Стандартизировать ни у кого желания нет, потому что профит по сравнению с уже существуюшим 3D не то чтобы большой.

———
https://wingolog.org/archives/2021/12/13/webassembly-the-new-kubernetes

Писал про #ebpf + #io_uring, и, буквально, на днях, про #wasm. Короче, идея, что нужна более легкая виртуализация, витает в облаках.

———
https://www.supergoodcode.com/zink-4ever/

Важная для меня тема :) Я в Mix решил строить графический стек в виде #zink + vulkan, чтобы 2 раза не вставать(и чтобы без #LLVM в драйверах*). И оказывается, не прогадал. Уже писал, что zink по перфу догнал классический OpenGL, а теперь просто прекрасное - #zink - самый фичастый из OpenGL в Mesa. Короче, старый стек уже можно закапывать.

Чувак работает на Valve.

Все #хорошее в OSS делают корпорации, когда это не основной их продукт. Гугл продает рекламу, а не браузер, FB, знаете ли, не продает системы сборки, и так далее. А вот результат у mongo и elastic немного хуже. Вот и Valve продает не OpenGL, а игры.

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

*: кстати, в копилку про "не умеют договариваться" и #fontconfig - в нормальной жизни компилятор шейдеров был бы демоном. Тогда и кеш понятно, как устроить, без вычисления md5 от образа библиотеки, и как не запускать llvm в каждом приложении, и как падения ретраить(sic).

PS: тут про компилятор шейдеров я имел в виду штуку, которая SPIR-V в машинный формат переводит.

#llvm weekly

https://reviews.llvm.org/rGf06abbb39380

Аааа, llvm busybox style binary приземлился! Пока в довольно ограниченном виде:

(1) the multicall binary cannot currently properly handle
multi-dispatch tools. This means symlinking llvm-ranlib to llvm-driver
will not properly result in llvm-ar's main being called.
(2) the multicall binary cannot be comprised of tools containing
conflicting cl::opt options as the global cl::opt option list cannot
contain duplicates.

Но лиха беда начало!

В прошлых сериях рассказывал, почему такой multicall хорошо и правильно, и что в llvm community есть сильное мнение против этой фичи. Очень переживал, что оно так и не будет внедрено, поэтому рад несказанно.

———
https://mawfig.github.io/2022/06/18/v-lang-in-2022.html
https://lobste.rs/s/hfjlba/v_language_review_2022

Давеча писал про #vlang, с прицелом на написание необходимых мне сборочных скриптов.

Python ужасно тормозной, например, мой clang wrapper замедляет сборку примерно в 2 раза, а его задача - просто переосмыслить cmd line для запуска настоящего компилятора.

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

Вот, по ссылке - разбор современного состояния vlang.

TL;DR; - все плохо, бОльшая часть заявленных фичей не работает, да и корки в типа безопасном языке - ну такое.

———
Bootstrap story.

Собирал себе wireshark. Потому что в транк приземлили поддержку QT6, а QT5 у меня нет, и мне ее лень собирать.

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

Но что-то сломалось в сумасшедших скриптах для cmake от QT, они начали писать, что, внезапно, у меня нет glib, хотя он, конечно, присутствовал.

Дебажить cmake скрипты - это дело совершенно безблагодатное, поэтому мне показалось, что проще убрать упоминание про glib в сгенеренных cmake скриптах от QT - https://github.com/pg83/ix/commit/7b46d6133b62f7b09cb37a57ba3817313e90ae7a#diff-19b6fefa6a33c75dfaedcd1b884a63a665b515b6c9894595aec999a951da530bR53

Лучше, конечно, было бы разобраться, но в cmake нет такой возможности.

Все, что оно умеет для отладки - это выдать дамп исполнения, со значениями переменных, которые были в IF(), FOR(), etc.

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

#llvm

Я несколько раз рассказывал, что бинари в тулчейне от llvm - не совсем бинари, а ссылки на основной бинарь, который, по значению argv[0], делает диспетчеризацию в нужную функцию. Так работает busybox, это один из важных способов сэкономить на размере бинаря в случае статической сборки.

Например, llvm-strip - это символическая ссылка на llvm-objcopy.

Я тут задался вопросом, будет ли работать символическая ссылка "strip" -> "llvm-objcopy".

Понятно, что оно может работать, а может и не работать, смотря как сделать диспатчинг по argv[0].

Вот как оно сделано в llvm - https://github.com/llvm-mirror/llvm/blob/master/tools/llvm-objcopy/llvm-objcopy.cpp#L319

bool IsStrip = sys::path::stem(ToolName)
    .contains("strip");

Сделано оно очень хорошо и правильно, "широкими мазками", без попытки выпилить лобзиком только "llvm-strip".

Это очень грамотное решение, оно позволяет одним и тем же бинарем заменить:

strip
linux-gnu-x86_64-strip
...
llvm-strip

И так далее.

По сути, покрывает все возможные вызовы strip, в кросс-компиляции, для замены в gnu toolchain, etc.

LLVM, в очередной раз, порадовали.

#llvm, будни #bootstrap

Сегодня llvm не молодцы.

В libc++16 появился заголовочный файл libunwind.h. Но есть один нюанс - уже есть библиотека, в котором тоже есть libunwind.h:

pg# ls /ix/store/F...6-lib-unwind/include/ 
    | grep libunwind.h
libunwind.h
pg# ls /ix/store/i...m-lib-c-plus-plus-16/include/ 
    | grep libunwind.h
libunwind.h

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

Дело еще осложнилось тем, что у меня, по сути, почти все зависит от libc++, потому что я всякие свои дополнения для musl (например, кастомный dlopen) пишу на С++, а на чем же еще? Пришлось повыпиливать лобзиком.

Ссылок не даю, там нет ничего (технически) интересного, так, жонглирование зависимостями.

Закрывая (кажется) тему #llvm libc++16 на ближайшее время.

В libc++ есть своя реализация format (почему? потому что могут же!), но она не работает. Поэтому авторы ее закомментили, до поры, до времени - https://github.com/llvm/llvm-project/blob/main/libcxx/include/format#L176

Но вот в последнем релизе libc++ эта реализация вылезла наружу, без каких-то guard на использование, через заголовочный файл vector - https://github.com/llvm/llvm-project/blob/main/libcxx/include/vector#L295

Что, ожидаемо, ломает проекты со своими polyfill (во какое слово узнал!) https://gitlab.com/ananicy-cpp/stl-polyfills/std-format/-/blob/main/polyfills/format/format

Ломает понятным образом - в namespace std:: появляются 2 реализации std::format.

#rant open source такой open source - тестов нет, все сломано, ничего не работает, и работать не будет.

https://reviews.llvm.org/rGa6213088812f

Какой-то странный движ вокруг #llvm #libc.

Ее допиливают под GPU target platform, вот, коммит, в котором запилили malloc/free.

С одной стороны, проехаться на растущей популярности этой платформы - норм, но как бы это не заслонило ту конечную цель, на которую надеялся я - стать THE libc для Linux.

#llvm

https://reviews.llvm.org/rG75a1797044fc

Поддержка fat lto .o файлов.

Сделано это изящным (нет) хаком:

"The new pipeline initially clones the module and runs the
selected (Thin)LTOPrelink pipeline, after which it will serialize the
module into a .llvm.lto section of an ELF file"

Натурально, положили IR в отдельную секцию в .o файле.

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

Думаю, сделано это от бедности, чтобы можно было протащить IR через системы сборки и пакетирования, которые ничего про это не знают, до LTO линкера.

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

https://discourse.llvm.org/t/survey-mlir-project-charter-and-restructuring-survey/82996

Проект #LLVM решил провести опрос (тема не столь важна), и использовал для этого платформу Google Docs:

"Following up our long discussion on the MLIR project governance and charter, we decided to create a survey to understand how MLIR developers and users connect to the upstream infrastructure"

Результат убил:

"Apparently the survey is in “violation of Google’s Terms of Service”, and requesting a review brings a 404 page. Luckily, they didn’t delete the spreadsheet results, so I’ll still be able to extract information from it, just not as quick as I hoped. I also made copies, in case the sheets also get deleted.

This means the survey is now closed"

Я так понимаю, Google (контора пидорасов!) теперь будет пилить свой компилятор, ага.