LLVM: Sorunlu Yanlar

 (npopov.com)
4 puan yazan GN⁺ 2026-01-13 | 1 yorum | WhatsApp'ta paylaş
  • LLVM projesinin yapısal sınırları ve teknik borcu çok yönlü biçimde analiz edilerek, iyileştirme gereken alanlar somut olarak işaret ediliyor
  • Yetersiz inceleme, API istikrarsızlığı, derleme ve compile süreleri, CI istikrarsızlığı gibi büyük ölçekli açık kaynak proje işletimindeki darboğazlar ortaya konuyor
  • IR tasarım sorunları arasında undef değerlerinin ele alınması, kısıtların kodlanması, kayan nokta anlam modeli ve spesifikasyon eksiklikleri yer alıyor
  • Backend heterojenliği, ABI işleme karmaşası, GlobalISel ve pass manager geçişindeki gecikme gibi uzun vadeli yapısal sorunlara dikkat çekiliyor
  • LLVM’in mevcut durumu olumsuzlamak yerine, bu durum sürekli iyileştirme ve katkının genişletilmesi için bir fırsat olarak sunuluyor

Başlıca yapısal sorunlar

  • İnceleme kapasitesinin yetersizliği en büyük darboğaz olarak gösteriliyor

    • Kod yazan çok kişi var, ancak reviewer sayısı az olduğu için doğrulanmamış değişikliklerin birleştirildiği durumlar yaşanıyor
    • İnceleme istemenin yazara ait bir sorumluluk olması, yeni katkı verenlerin uygun reviewer bulmasını zorlaştırıyor
    • Rust’ın PR otomatik atama sistemi bir iyileştirme yöntemi olarak anılıyor

  • API ve IR’de sık değişiklik (churn) kullanıcılar için yük oluşturuyor

    • C API görece istikrarlı olsa da C++ API sık değiştiğinden frontend ve backend bakım maliyeti artıyor
    • “Upstream or GTFO” yaklaşımı nedeniyle paylaşılmayan kod, karar alma sürecine yansımıyor

  • Aşırı uzun build süresi sorunu

    • LLVM, 2,5 milyondan fazla satır C++ koddan oluşuyor; bu da build süresini çok uzatıyor, debug build’lerde ise bellek ve disk kullanımı keskin biçimde artıyor
    • Precompiled header (PCH), varsayılan olarak dylib build, testlerin daemonlaştırılması gibi çözümler tartışılıyor

  • CI istikrarsızlığı

    • 200’den fazla buildbot farklı ortamlarda test yapıyor, ancak sistem her zaman “yeşil durumda” kalamıyor
    • Flaky testler ve buildbot sorunları uyarı sinyallerini zayıflatarak gerçek hataların tespitini güçleştiriyor
    • PR öncesi testlerin devreye alınmasıyla kısmi iyileşme sağlansa da temel sorun çözülmüş değil

  • Uçtan uca test eksikliği

    • Tek tek optimizasyonlara yönelik unit testler güçlü olsa da, tüm pipeline’ı veya backend entegrasyonunu sınayan testler neredeyse yok
    • llvm-test-suite mevcut, ancak temel işlemler ve veri türü kombinasyonlarını yeterince kapsamıyor

Backend ve performansla ilgili sorunlar

  • Backend’ler arası heterojenlik

    • Orta katman birleşik olsa da backend’lerde her hedefe özel bağımsız değişiklikler çok fazla; bu da yinelenme ve dallanmayı artırıyor
    • Ortak optimizasyonlar yerine hedefe özgü hook’lar ekleme eğilimi bulunuyor

  • Compile süresi

    • JIT ve büyük ölçekli IR üreten dillerde (Rust, C++) yavaş kalıyor
    • -O0 build’leri özellikle yavaş; TPDE backend ise 10 ila 20 kata kadar daha hızlı bir alternatif olarak sunuluyor

  • Performans takibinin olmaması

    • Resmî bir runtime performans izleme altyapısı bulunmuyor
    • LNT sistemi; kararsız çalışma, UX sorunları ve veri eksikliği gibi nedenlerle düşük etkililik gösteriyor

IR tasarım sorunları

  • undef değerlerinin ele alınmasındaki karmaşıklık

    • Her kullanımda farklı bir değer alabilmesi, optimizasyon sırasında hatalara yol açıyor
    • Gelecekte poison değeri ile değiştirilebilmesi mümkün görülüyor, ancak bellekte poison işleme hâlâ yetersiz

  • Spesifikasyonun eksik ve tutarsız olması

    • Uzun süredir çözülmemiş eski yanlış derleme örnekleri bulunuyor
    • Provenance modeli gibi tasarımsal zorluklar mevcut
    • Bunları çözmek için resmî spesifikasyon çalışma grubu oluşturulmuş durumda

  • Kısıt kodlamasında tutarlılık eksikliği

    • Poison flag’leri, metadata, attribute’lar ve assumes gibi farklı yöntemler bir arada kullanılıyor
    • Bu durum, bilgi kaybı ya da gereğinden fazla bilginin korunması nedeniyle optimizasyonu olumsuz etkiliyor

  • Kayan nokta (FP) anlam modeli sorunları

    • Signaling NaN, standart dışı ortamlar, denormal işleme, x87 aşırı hassasiyet gibi alanlarda tutarsızlık oluşuyor
    • Bunlar constrained FP intrinsic’leriyle ayrı ele alındığından karmaşıklık daha da artıyor

Diğer teknik sorunlar

  • Kısmi migration gecikmeleri

    • Yeni pass manager yalnızca orta katmana kadar uygulanmış durumda; backend tarafı hâlâ eski sistemi kullanıyor
    • GlobalISel 10 yıldır tam geçişe ulaşamadı ve SDAG ile birlikte varlığını sürdürüyor

  • ABI ve calling convention işlemede karmaşa

    • Frontend ile backend arasındaki sorumluluk ayrımı belirsiz ve dokümantasyon yetersiz
    • ABI kütüphanesi eklenmesi ve prototip uygulama üzerinde çalışmalar sürüyor
    • Hedef özelliklerinin etkinleşmesine göre ABI’nin değişebilmesi de ayrı bir sorun oluşturuyor

  • Built-in fonksiyonlar ve libcalls yönetiminde tutarsızlık

    • TargetLibraryInfo ile RuntimeLibcalls ayrı tutulduğu için yeterli tutarlılık sağlanamıyor
    • Kullanılan runtime kütüphanesinin türüne (libgcc, compiler-rt vb.) göre hangi işlevlerin mevcut olduğuna dair farkındalık yok
    • Rust gibi harici runtime’lar için özelleştirme noktaları bulunmuyor

  • Context / Module yapısındaki verimsizlik

    • Türler ve sabitler Context içinde, fonksiyonlar ve global’ler ise Module içinde yer alıyor
    • Data layout’a erişilememesi, constant folding gibi işlemlerde zorluk yaratıyor
    • Context’ler arası link verilemiyor; yapının sadeleştirilmesi gerekiyor

  • LICM (loop-invariant code motion) nedeniyle register baskısı

    • Bir maliyet modeli olmadan koşulsuz hoist yapılıyor
    • Backend tarafında tekrar sink edilmediği için spill ve reload artıyor

Sonuç

  • Sıralanan sorunlar, LLVM’in olgunluğu ve ölçeğinden kaynaklanan yapısal zorluklar olarak değerlendiriliyor;
    bunlar proje kalitesini ve katkı veren deneyimini iyileştirmek için bir fırsat olarak sunuluyor
  • Bazı alanlarda (build optimizasyonu, ABI kütüphanesi, performans takibi vb.) iyileştirme çalışmaları zaten başlamış durumda
  • Genel olarak LLVM hâlâ çok güçlü, ancak sürekli refactoring ve spesifikasyonun düzenlenmesi kritik önem taşıyor

İlgili okumalar

1 yorum

 
GN⁺ 2026-01-13
Hacker News yorumları

  • Yazının geneli iyi derlenip toparlanmış, bu yüzden büyük ölçüde katılıyorum
    Bu aralar LLVM IR kararlılığı epey yükseldi. Fil-C’yi bir gün içinde LLVM 17’den 20’ye rebase ettim.
    Başka projelerde de birden fazla LLVM sürümünde aynı pass’i korudum ve büyük bir sorun yaşamadım
    Yine de LICM’in register baskısı özellikle C/C++ dışındaki kaynaklarda ciddi. Sorun LICM’in kendisinden çok, regalloc’un rematerialize’ı daha iyi öğrenmesi gerektiği gibi görünüyor

    • regalloc zaten rematerialize’ı biliyor. Ancak backend, optimizer’a kıyasla yalnızca yerel bir bakışa sahip olduğu için LICM’in yarattığı kötü kararları geri almak zor oluyor
    • rematerialize pass’i zaten var. Bunu özellikle register allocation ile bağlamak gerekmiyor. LLVM regalloc zaten baştan beri kusursuz değildi
      Frontend geliştiricilerinin farklı ayarları benchmark edip en iyi değeri seçebilmesi için seçeneklerin daha açık olmasını isterdim
    • LLVM uzmanı değilim ama geçmişte uğraştığımda IR bana tek bir dilden çok, birden fazla dilin ortak sözlüğü gibi gelmişti.
      Her aracın ve bileşenin kendine özgü kuralları var, bu yüzden sürümler arasında fark çıkması aslında doğal görünüyor. Acaba bunu yanlış mı anlamıştım diye merak ediyorum

  • macOS’ta LLVM 18 derlemek için compiler-rt sorumlusundan sadece tek bir boolean’ı değiştirmesini istedim, ama konu “heated” diye kilitlendi ve 4 yıldır çözümsüz duruyor
    Yine de LLVM’i hâlâ seviyorum. clang-tidy, ASAN, UBSAN, LSAN, MSAN, TSAN gerçekten harika.
    C/C++ kodu yazarken clang-tidy kullanmamak bence yanlış bir tercih
    Ancak -fbounds-safety yalnızca AppleClang’de var ve MSAN/LSAN yalnızca LLVM Clang’de bulunuyor. Xcode’da ayrıca clang-tidy, clang-format ve llvm-symbolizer da yok.
    Sonunda macOS’ta doğrudan Darwin LLVM’i derleyip kullanmak zorunda kaldım.
    Linux tarafı da karmaşık. RHEL libcxx vermiyor ama Fedora veriyor. Buna rağmen MSAN için instrument edilmiş libcxx hiçbir dağıtımda yok
    Fedora neredeyse işi bitirmiş durumda ama yine de compiler-rt’yi elle derlemek gerekiyor

    • Gentoo denemenin önerildiğini gördüm. Gentoo LLVM wiki bağlantısına bakılabilir
    • Chimera Linux veya Mandriva’da LLVM’in varsayılan olarak iyi çalışıp çalışmadığı da sorulmuştu. Chimera oldukça LLVM yerel bir dağıtım

  • Son zamanlardaki LLVM tartışmalarını görünce, C’den değil doğrudan LLVM IR’den başlayan çalıştırılabilir bir test paketinin kesinlikle gerekli olduğunu hissettim
    Backend’i doğrudan yazmaya başlayınca SelectionDAG ya da GlobalISel belgeleri yetersiz kalıyor ve işlemlerin anlamı belirsiz olduğundan yanlış uygulamak kolaylaşıyor

  • C API LLVM içinde ihmal edilmiş gibi hissettiriyor. Pek çok seçenek veya opt pass dışa açılmamış

    • Bunun nedeni, LLVM’in C++ API’sinin ifade gücünü C tarzı bir arayüze aktarmanın zor olması.
      Geliştiricilerin çoğu doğrudan C++ API kullandığı için C API geri plana itiliyor ve sonuçta ikinci sınıf vatandaş olarak kalıyor

  • Kod incelemesi anında ödüle dönüşmediği için insanlar bunu pek yapmak istemiyor
    İncelemeye de katkı kredisi verilse motive edici olabilir

    • Şirket içinde de benzer bir sorun yaşıyoruz. Benim şirketim incelemelerin kalitesini ve miktarını değerlendirme ölçütlerine dahil ediyor ama bu bile hâlâ yeterince motive etmiyor

  • 6 yıl önce 8GB RAM’li bir Dell 9360 dizüstünde sık sık LLVM derliyordum. Link paralelliğini azaltınca bellek sınırı içinde kalabiliyordu
    Hâlâ 8GB ile derlenip derlenemeyeceğini merak ediyorum

    • Paralel derlemeyi kapatıp birkaç GB swap ayırırsanız mümkün. Ancak linker ayar flag’lerini düzenlemek gerekiyor
    • M1 Mac’te LLVM tüm derleme ayarlarında bir saatten kısa sürede compile oluyor

  • LLVM’in ilk dönemlerinde avantajı GCC’den daha hızlı derleme hızıydı.
    LLVM’den 23 yıl sonra şimdi yeniden yeni bir şey çıkıp çıkmayacağını merak ediyorum

    • Yakın zamanda birisi LLVM’in -O0 backend’ini 10~20 kat hızlandıran TPDE projesi üzerinde çalıştı ama pek ilgi görmedi
      LLVM IR kullanmayan Cranelift gibi alternatifler de var (Cranelift GitHub)
    • Yine de LLVM, C/C++ derleme konusunda çok güçlü. Kusursuz değil ama benzer bir seviyeye ulaşmak için on binlerce kişi-saatlik emek gerekiyor

  • ABI ve calling convention işleme en büyük sıkıntı.
    Compiler frontend’de argüman geçişini doğrudan yönetmek gerekiyor, bazen register sayısını hesaplamak bile gerekebiliyor

  • Yazıda “frontend’ler kararlı bir C API sayesinde korunuyor” denmişti ama pratikte durum böyle değil
    Bazı API’ler kararlı, ancak Orc gibi bölümler sık sık değişiyor

  • LLVM’de neredeyse hiç issue inceleme sistemi yok gibi görünüyor. Benim açtığım bug report’lar da yıllardır işlenmiyor