#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, а вот дальше есть варианты.