#llvmweekly

https://c3.handmade.network/blog/p/8852-how_bad_is_llvm_really

TL;DR - медленно, семантика промежуточного представления (над которым производятся оптимизации) заточены на С/С++, и сделать иначе - невозможно. Ну, например, деление на 0 в LLVM - UB, а какой-то "другой" язык хочет уметь это обрабатывать. В итоге, LLVM навязывает некоторую семантику любому языку, которые хочет его использовать. Например, бесконечный цикл в rust, который некорретно оптимизировался llvm - https://github.com/rust-lang/rust/issues/28728

Зато много готовых оптимизаций из коробки.

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

У автора замена аллокатора для LLVM на mimalloc дает хороший буст в скорости (+10%).

Я систематически бенчил clang с разными аллокаторами, и остановился на #tcmalloc от Google, по скорости тот же mim, но в пике жрет прямо существенно меньше памяти.

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

#llvmweekly

https://msinilo.pl/blog2/post/compilers-are-too-smart/

Текст про то, что чувак дизассемблировал какую-то простую функцию, состоящую из какого-то довольно простого вызова в libc++, и охуел удивился увиденному.

Как выяснилось, авторы libc++ заложились на то, что clang проведет определенную оптимизацию вот такого блока кода:

inline _LIBCPP_HIDE_FROM_ABI size_t __constrain_hash(size_t __h, size_t __bc) {
  return !(__bc & (__bc - 1)) ? __h & (__bc - 1) : (__h < __bc ? __h : __h % __bc);
}

И заменит его на popcount (что не произошло в случае автора этого текста).

Не знаю, с одной стороны, это очевидный догфудинг, и "используйте наш самый лучший в мире clang для компиляции нашей самой лучшей stl библиотеки", с другой - некоторое хамство.

Ну вот нужен тебе popcount, проверь, что он есть, и позови напрямую, даже через какой-нить builtin/intrinsic, чтобы у людей опыт использования либы был более-менее консистентным.

UPD: меня вот тут поправляют, что я неверно все понял - https://t.iss.one/c/1469934025/27643

#llvmweekly

https://discourse.llvm.org/t/rfc-require-discussion-of-impact-to-monorepo-stakeholders-when-adding-new-clang-extensions/79613

Разработчик llvm просит разработчиков clang договариваться с остальными stakeholders, если они делают какие-то изменения, которые могут затронуть всю остальную кодовую базу:

"As a concrete example of what I mean, the __restrict qualifier extension in C++ is treated as a cv-qualifier in Clang, including allowing it to be written on a member function. This impacts libc++ because e.g. std::function and std::invoke need to be able to invoke qualified member functions, and qualifiers have a combinatorial number of cases to consider for both tests and within the implementation"

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

Удивительно, но, вроде, все договорились.

#llvmweekly

https://discourse.llvm.org/t/rfc-overflow-idiom-exclusion/80093

TL;DR - коллеги предлагают (за флагом cli) убрать из (undefined? я в них запутался уже) sanitizer обработку некоторых типов overflow.

Почему?

Потому что разработчики ядра Linux вертели на причинном месте мнение стандартов на язык С, про то, что можно, и что нельзя, и считают вот такой код

if (base + offset < base) { 
    ... 
}

вполне валидным.

Мнение Линуса на этот счет вполне известно:

https://www.yodaiken.com/2018/06/07/torvalds-on-aliasing/

"This is why we use -fwrapv, -fno-strict-aliasing etc. The standard simply is not *important*, when it is in direct conflict with reality and reliable code generation"

Менять он его не собирается, поэтому приходится подстраиваться.

Было бы интересно посмотреть, как в clang/llvm пришли бы с похожими потребностями из проекта послабее, чем ядро Linux.

#llvmweekly #rant

https://discourse.llvm.org/t/a-bytecode-for-lldb-data-formatters/82696

TL;DR - хочется уметь красиво выводить в отладчике не встроенные типы, для этого предлагается завести секцию, в котороую писать bytecode, который умеет выводить на эран те или иные типы в программе.

Почему не положить туда готовые python форматтеры, которые уже есть, и написаны?

"The logical next step would be to store full Python formatters instead of summary strings, but Python code is larger and more importantly it is potentially dangerous to just load an execute untrusted Python code in LLDB.

To address these problems, I’m proposing a minimal bytecode tailored to running LLDB formatters. It defines a human-readable assembler representation for the language, an efficient binary encoding, a virtual machine for evaluating it, and format for embedding formatters into binary containers"

Объяснение не стоит и выеденного яйца, потому что ТЫ УЖЕ ЗАПУСТИЛ этот бинарь, запусти и Python, в песочнице.

https://discourse.llvm.org/t/a-bytecode-for-lldb-data-formatters/82696/10

Или возьми готовый VM, в который llvm уже умеет (hint - #WebAssembly, #bpf, #ebpf https://discourse.llvm.org/t/a-bytecode-for-lldb-data-formatters/82696/12).

Но нет, это было бы слишком просто, на таком фиолетовое не получить.

Вообще, удивительно, в маленький #harfbuzz тащат большой #WebAssembly (https://t.iss.one/itpgchannel/1201), а в большой LLDB (который уже умеет в #WebAssembly) тащат самопальный байткод...

Где логика-то?

#llvmweekly

https://discourse.llvm.org/t/rfc-modelling-errno-memory-effects/82972

TL;DR - коллеги собираются сделать какие-то оптимизации, которые смогут полагаться на то, что произвольный указатель может указывать на errno, только если он имеет тип int* (и совместимый).

Еще одна причина не использовать int в своем коде!

#llvmweekly

https://llvmweekly.org/issue/569

"The basic definition for “LLVM” as the environment part of a triple (as in x86_64-pc-linux-llvm was added, intended for use to indicate LLVM’s libc"

https://github.com/llvm/llvm-project/commit/7672216ed7f4

Хорошо быть libc при компиляторе - сами с собой обсудили добавление нового суффикса -llvm для libc от llvm, сами и закоммитили, ни с кем договариваться не надо!

Упорство, с которой вот эту вот ебалу "x86_64-pc-linux-llvm" называют "триплет", меня, конечно поражает.

#llvmweekly

https://discourse.llvm.org/t/nanobind-for-mlir-python-bindings/83511

Коллеги пишут, что ускорили какой-то биндинг из LLVM в Python, за счет использования nanobind вместо pybind11 (я хз что это, я использую cython), ажно на 10%.

Больше всего меня удивило не это, а вот этот вот отрывок текста:

"For a complicated Google-internal LLM model in JAX, this change improves the MLIR lowering..."

Это что значит?

Я просто не понимаю, что значат эти слова, когда их ставят рядом - где LLM, а где "MLIR lowering"?

#llvmweekly

https://discourse.llvm.org/t/rfc-commit-access-criteria/84073/48

Крис Латтнер выступил против усложнения получения права на коммит в LLVM.

Аргументация хорошая, всем любителям анально огородить свой проект must read.

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

#llvmweekly

ВНЕЗАПНО послать всех нахуй не вышло, и был принят исходный proposal - https://github.com/llvm/llvm-project/pull/127006/commits/d5492cfe0a52512b981a452dea2a373d640e1416

#llvmweekly

https://nnethercote.github.io/2025/03/19/how-to-speed-up-the-rust-compiler-in-march-2025.html

"Every LLVM major update for several years has made the Rust compiler faster. This is not due to some law of nature. Rather, it reflects sustained, excellent work from the LLVM developers. Kudos to them"

UPD:

Several years ago:

https://www.npopov.com/2020/05/10/Make-LLVM-fast-again.html

> Each LLVM release is a few percent slower than the last. LLVM 10 put some extra effort in this area, and somehow managed to make Rust compilation a whole 10% slower, for as yet unknown reasons.

(далее описывается внедрение CI с бенчмарком)

#llvmweekly

https://discourse.llvm.org/t/rfc-intra-procedural-lifetime-analysis-in-clang/86291

"This analysis draws inspiration from Rust’s Polonius borrow checker. While adapted for C++'s semantics (e.g., handling opaque calls, no enforced exclusivity, configurable strictness), its internal model still uses concepts like Loans and Origins which are analogous to formulation of lifetime in Rust’s Polonius.

This notion of a Origin/Loans serves a role closely related to the lifetime/origin tracking in Polonius, providing a conceptual bridge. This proposal develops the necessary CFG-based dataflow infrastructure that could also support more explicit, Rust-style lifetime systems if they were introduced to Clang"

TL;DR - в clang уже есть [[clang::lifetimebound]], его предлагается расширять так, чтобы он мог работать между вызовами функций, используя идеи из Rust borrow checker.

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

Это вам не сраные профили безопастности от Страуструпа (https://t.iss.one/itpgchannel/2763), ага.

#llvmweekly #cplpl_doomed

https://discourse.llvm.org/t/factoid-each-class-template-instantiation-costs-1kib/86189

TL;DR - каждый раз, когда вы инстанциируете шаблон, в мире умирает котик, вы тратите 1K памяти, и это очень много, потому что header only библиотеки:

"Maybe what this all points to is that header-only library evolution is a dead end when it comes to compile time, and that if you want to have fast compiles, the old ways, i.e. forward declarations, pimpl patterns, and other forms of implementation hiding, are still relevant if you care about compile time, even in a modular world"

Очень пересекается с цитатой из https://t.iss.one/itpgchannel/22, 100500 раз писал, и буду продолжать писать, что избыточная мономорфизация/inline - зло, не надо бояться virtual method call, pimpl, и вот это вот все.

И это коллега пишет только про время и потребление ресурсов компилятором, и не упоминает того, что избыточно встроенный код еще и медленнее может быть, потому что плохо использует кеши процессора (например, https://t.iss.one/itpgchannel/1547).

UPD: про pimpl вот еще ссылка - https://github.com/llvm/llvm-project/commit/bb1765179e1f, пример того, как сам LLVM у себя выпиливает излишнюю мономорфизацию.

(сорян, у меня много #llvmweekly, я их с месяц не читал, там много накопилось интересного)

https://discourse.llvm.org/t/improving-the-reproducibility-of-linker-benchmarking/86057

"The idea is to use the Nix project to build the projects with a custom linker wrapper that collects the reproducers. Nix builds are (at least theoretically) reproducible and all projects are built in a fairly uniform way which makes it fairly easy to inject the linker wrapper into any project without knowing project-specific details. Nix also supports cross compilation so the same machine can be used to build reproducers for all architectures (but there are some bugs which mean that at the moment not all projects can be cross compiled and not all projects end up using the linker wrapper). And we can upgrade project versions by using a new version of Nixpkgs (Nix’s “ports tree”)"

TL;DR - давайте возьмем reproducible Nix + наш враппер над LLD, чтобы уметь собирать статистику по временам работы LLD при сборке произвольно большого набора OSS проектов.

Очень, очень, хорошая и плодотворная идея.

#llvmweekly

https://github.com/llvm/llvm-project/commit/d68c732473a1

"flang/lib/Parser/Fortran-parsers.cpp:
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:47.31 -> 0:41.68
Maximum resident set size (kbytes): 2062140 -> 1745584

flang/lib/Lower/Bridge.cpp:
Elapsed (wall clock) time (h:mm:ss or m:ss): 1:19.16 -> 0:45.86
Maximum resident set size (kbytes): 3849144 -> 2443476

flang/lib/Lower/PFTBuilder.cpp
Elapsed (wall clock) time (h:mm:ss or m:ss): 1:29.24 -> 1:00.99
Maximum resident set size (kbytes): 4218368 -> 2923128

flang/lib/Lower/Allocatable.cpp
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:53.03 -> 0:22.50
Maximum resident set size (kbytes): 3092840 -> 2116908

flang/lib/Semantics/Semantics.cpp
Elapsed (wall clock) time (h:mm:ss or m:ss): 1:18.75 -> 1:00.20
Maximum resident set size (kbytes): 3527744 -> 2545308"

TL;DR - прямо ооочень значимое сокращение времен сборки flang, с использованием precompiled headers, даже неожиданно. Правда, это тщательно выбранные файлы, не общее время, но, тем не менее.

#llvmweekly (Остапа понесло, ага)

https://github.com/llvm/llvm-project/commit/d1fd97737e90

А вот если кому-то интересно, как запилить поддержку санитайзера под пока неподдерживаемую OS.

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

Муторно, но не очень сложно.

И взгляд с другой стороны - https://keithp.com/blogs/sanitizer-fun/, как поддержать неизвестную libc в санитайзерах, и с чем пришлось столкнуться.

https://discourse.llvm.org/t/rfc-adding-sframe-support-to-llvm/86900/3 #dwarf #llvmweekly

Поддержка sframe в llvm, не прошло и трех лет!

Вообще, новость, конечно, позитивная, по модулю того, что llvm уже умеет "compact unwind" на mach-o платформах.

#llvmweekly

https://discourse.llvm.org/t/rfc-llvm-link-llvm-dylib-should-default-to-on-on-posix-platforms/85908/60

These are again for release+assert with non-pie baseline:

            | static | dylib | slowdown
check-llvm  |  1:30s | 1:53s | 25%
check-clang |  1:11s | 1:28s | 24%

Тут написано, что тесты на clang/llvm, если брать динамически слинкованный clang, на четверть медленнее, чем со статически слинкованным clang.

В копилочку к https://t.iss.one/itpgchannel/2939 (два последних пункта).

#llvmweekly, история одного #debug.

Довольно существенный прогресс у gcc rust codegen (это, напомню, rust, но с оптимизатором от gcc) - https://fractalfir.github.io/generated_html/cg_gcc_bootstrap.html

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

#llvmweekly

https://llvm.org/docs/DTLTO.html
https://github.com/llvm/llvm-project/commit/3b4e79398de5
https://github.com/llvm/llvm-project/commit/6520b21ce0

Гля какая красота, LLD умеет распараллеливать часть thin lto между несколькими хостами, не только в многопоток на одном хосте!