Sebuah backend compiler baru bernama TPDE-LLVM telah dirilis sebagai open-source, menjanjikan peningkatan dramatis dalam waktu kompilasi sambil mempertahankan performa runtime yang serupa dengan backend -O0 standar LLVM . Proyek ini mengatasi salah satu keluhan paling persisten tentang LLVM : kecepatan kompilasi yang lambat, terutama untuk debug builds.
Peningkatan Kecepatan Mengesankan dengan Trade-offs
TPDE-LLVM menghadirkan kecepatan kompilasi yang 10-20 kali lebih cepat dibanding backend -O0 LLVM di berbagai benchmark. Pengujian pada SPEC CPU 2017 menunjukkan peningkatan yang konsisten, dengan beberapa program seperti omnetpp dan xalanc mengalami kompilasi lebih dari 20x lebih cepat. Namun, kecepatan ini datang dengan biaya ukuran kode yang sedikit lebih besar, biasanya 10-30% lebih besar dari output LLVM standar.
Komunitas menunjukkan reaksi beragam terhadap hasil ini. Sementara beberapa developer antusias dengan debug builds yang lebih cepat, yang lain menunjukkan keterbatasan penting. Backend ini saat ini hanya mendukung subset dari intermediate representation (IR) LLVM dan hanya menargetkan prosesor x86-64 dan AArch64.
IR (Intermediate Representation): Bahasa pemrograman tingkat rendah yang digunakan secara internal oleh compiler untuk merepresentasikan source code sebelum mengonversinya ke machine code.
Hasil Performa SPEC CPU 2017 (x86-64)
| Benchmark | Percepatan Waktu Kompilasi (-O0) | Rasio Ukuran Kode (-O0) | Percepatan Waktu Kompilasi (-O1) | Rasio Ukuran Kode (-O1) |
|---|---|---|---|---|
| 600.perl | 11.39x | 1.27x | 15.00x | 0.97x |
| 602.gcc | 12.54x | 1.32x | 17.55x | 1.01x |
| 605.mcf | 9.72x | 1.27x | 12.47x | 0.92x |
| 620.omnetpp | 21.46x | 1.24x | 26.49x | 1.03x |
| 623.xalanc | 18.99x | 1.24x | 24.80x | 0.98x |
| 625.x264 | 10.52x | 1.26x | 15.19x | 0.97x |
| 631.deepsjeng | 9.60x | 1.25x | 17.56x | 0.97x |
| 641.jeela | 21.44x | 1.24x | 18.36x | 0.95x |
| 657.x2 | 10.95x | 1.30x | 15.15x | 0.92x |
| Rata-rata Geometris | 13.34x | 1.27x | 17.58x | 0.97x |
Inovasi Teknis di Balik Kecepatan
Rahasia kecepatan TPDE-LLVM terletak pada pendekatan yang disederhanakan. Alih-alih sistem optimisasi multi-pass kompleks LLVM , TPDE menggunakan hanya tiga passes: pembersihan IR, analisis untuk loops dan variable lifetimes, serta code generation gabungan. Proses yang disederhanakan ini menangani lowering, register allocation, dan pembuatan machine code sekaligus.
Diskusi komunitas mengungkapkan bahwa pendekatan ini bekerja dengan baik untuk kode yang dihasilkan compiler pada umumnya dari Clang , dengan dukungan yang layak untuk Rust dan Flang juga. Namun, beberapa library Rust populer menggunakan tipe vektor khusus yang belum didukung, membatasi kegunaannya secara langsung untuk semua proyek.
Gambaran Arsitektur TPDE-LLVM
- Desain Tiga Tahap: Pembersihan/persiapan IR → Analisis (loop + liveness) → Codegen gabungan
- Target yang Didukung: Hanya x86-64 dan AArch64
- Dukungan LLVM-IR: Subset tipikal yang dihasilkan oleh Clang -O0/-O1
- Opsi Integrasi: Library (kompilasi JIT), alat mandiri, integrasi Clang (memerlukan patch)
- Keterbatasan Saat Ini: Tidak ada dukungan DWARF, alokasi register dasar, hanya platform ELF
Dampak Dunia Nyata dan Keterbatasan
Peningkatan performa terutama menguntungkan bagian backend dari kompilasi. Dalam proyek C/C++ tipikal menggunakan Clang , frontend (parsing source code) memakan 50-80% waktu kompilasi. Dengan TPDE-LLVM , ini melonjak menjadi lebih dari 98%, artinya peningkatan keseluruhan kurang dramatis dibanding angka backend yang disarankan.
Peningkatan 10-20x yang dijelaskan di sini belum bekerja untuk clang atau rustc, dan ketika sudah bisa, ini hanya akan mempercepat bagian backend. Meskipun demikian, ini tetap merupakan kemenangan luar biasa untuk compile times karena dua langkah lainnya dapat dioptimalkan secara independen.
Beberapa tantangan teknis masih tersisa. Sistem ini belum mendukung informasi debugging DWARF , menggunakan alokasi register dasar yang spills semuanya, dan tidak mendukung platform non-ELF. Para developer telah mengidentifikasi fitur LLVM-IR spesifik yang memperlambat kompilasi, termasuk constant expressions dalam fungsi dan struktur data berukuran arbitrer.
Bottleneck Performa LLVM-IR yang Teridentifikasi
Dampak Performa:
- ConstantExpr di dalam fungsi (memerlukan penulisan ulang menjadi instruksi)
- Nilai struct/array berukuran arbitrer (kompleksitas runtime kuadratik)
- PHINode::getIncomingValForBlock menyebabkan waktu kompilasi kuadratik untuk blok dengan >1k predecessor
Tantangan Implementasi:
- Akses langsung ke global thread-local (memerlukan generasi pemanggilan fungsi)
- Aritmatika bit-width arbitrer ( i268 dan lebar non-standar serupa)
- Masalah performa Live::successors memerlukan caching
Melihat ke Depan
Proyek ini merepresentasikan langkah signifikan menuju kompilasi yang lebih cepat, terutama berharga untuk workflow development di mana iterasi cepat lebih penting daripada performa runtime optimal. Meskipun tidak akan menggantikan backend optimisasi LLVM untuk release builds, TPDE-LLVM bisa menjadi alat penting bagi developer yang menghabiskan waktu signifikan menunggu debug builds untuk dikompilasi.
Rilis open-source memungkinkan komunitas yang lebih luas untuk bereksperimen dengan teknik-teknik ini dan berpotensi mengintegrasikannya ke dalam toolchain yang ada. Apakah ini mengarah pada adopsi luas atau mempengaruhi peningkatan dalam LLVM itu sendiri masih harus dilihat, tetapi ini tentu menunjukkan bahwa peningkatan kecepatan kompilasi dramatis dimungkinkan dengan pilihan arsitektur yang tepat.
Referensi: TPDE-LLVM: 10-20x Faster LLVM -00 Back-End