Hacker News Digest

TPDE-LLVM — новый бэкенд LLVM-O0, который в 10–20 раз быстрее стандартного, при сопоставимой скорости выполнения и росте кода на 10–30 %. Работает с IR Clang-O0/O1, цели x86-64 и AArch64.
Данные SPEC CPU 2017 (x86-64, ускорение компиляции и размер кода относительно LLVM 19 -O0):

бенчмарк	O0 IR	O1 IR
perl	11.4× / 1.27×	15.1× / 0.97×
gcc	12.5× / 1.32×	17.6× / 1.01×
omnetpp	21.5× / 1.24×	26.5× / 1.03×
геом.ср.	13.3× / 1.27×	17.6× / 0.97×

Как работает: три прохода — очистка IR, анализ (циклы + liveness), единый codegen (lowering, регистры, кодирование).
Поддержка: как библиотека, llc-подобный инструмент, патч для Clang. DWARF и улучшенный рег-аллокатор в планах.
Ограничения: не все IR-конструкции, векторы, TLS-глобалы, i260 и т.д.

Что ускорило бы LLVM ещё сильнее:

• убрать ConstantExpr внутри функций;
• запретить гигантские структуры/массивы как значения;
• упростить доступ к TLS и произвольную битовую арифметику.

• Пользователи обсудили, что Gentoo всё ещё используют с флагом -O8 для максимальной производительности.
• Кто-то спросил, нужно ли добавить пометку «(2020)» к цитируемому тексту.
• Упомянули, что «все» якобы перешли на Arch, где компилятор якобы умеет -O11.
• Уточнили: пост 2025 года, но он цитирует запись 2020-го; попросили модератора исправить.

TPDE-LLVM: 10-20× быстрее -O0
Новый open-source бэкенд TPDE-LLVM ускоряет компиляцию в режиме -O0 в 10–20 раз при сопоставимой скорости выполнения и увеличении кода на 10–30 %. Поддерживаются x86-64 и AArch64, типичное IR Clang O0/O1.

SPEC 2017 (x86-64)	Ускорение	Размер
perl	11.4×	1.27×
gcc	12.5×	1.32×
mcf	9.7×	1.27×
omnetpp	21.5×	1.24×
xalanc	19.0×	1.24×
x264	10.5×	1.26×
deepsjeng	9.6×	1.25×
leela	21.4×	1.24×
xz	11.0×	1.30×
geomean	13.3×	1.27×

Как работает
Три прохода: очистка IR, анализ (циклы + живость), кодогенерация (lowering, регистры, код) за один проход. Подробности — в статье.

Планы

• DWARF, улучшенный регистровый аллокатор.
• Поддержка Flang/Rust неполная (векторы, FP-операции).
• Нет non-ELF, других целей.

Использование
Библиотека, llc-подобный инструмент, патч для Clang.

Почему не ускорить LLVM?
LLVM 18→20 стал быстрее на 18 %, но 10× требует радикальных изменений.

Что мешает ещё быстрее

• ConstantExpr внутри функций.
• Структуры/массивы произвольного размера.
• Прямой доступ к TLS-глобалам.
• Арифметика произвольной битности (i260).

Факты

• 4 байта padding в Instruction для служебных номеров.
• PHINode::getIncomingValForBlock квадратичен при >1 k предков.
• 90 % времени tpde-llc — парсинг биткода.

• TPDE — новый бэкенд, генерирующий код на 10–20× быстрее LLVM, но чуть медленнее -O0.
• Участники спорят, насколько «парето-улучшение» реально: поддерживается лишь «типичное» подмножество LLVM-IR, векторные инструкции и экзотика не работают.
• Некоторые вспомнили Copy-and-Patch и другие подходы, где LLVM используется для библиотеки патчей, но теряется 2,5× в рантайме из-за регистров.
• Основная узкость теперь — фронтенды (rustc, Clang), которые даже при TPDE занимают >98 % времени сборки.
• Желают скорейшего переноса в Swift и Wasmer, но сомневаются в готовности сообщества LLVM что-то менять.