Sebuah backend pengkompil baharu yang dipanggil TPDE-LLVM telah dikeluarkan sebagai sumber terbuka, menjanjikan untuk meningkatkan masa kompilasi secara dramatik sambil mengekalkan prestasi runtime yang serupa dengan backend -O0 standard LLVM . Projek ini menangani salah satu aduan yang paling berterusan dalam pembangunan perisian moden: masa kompilasi yang perlahan yang menjejaskan produktiviti pembangun.
Peningkatan Kelajuan Kompilasi yang Revolusioner
TPDE-LLVM menyampaikan kelajuan kompilasi yang 10-20 kali lebih pantas daripada backend -O0 LLVM merentasi pelbagai penanda aras daripada suite SPEC CPU 2017 . Keputusan yang paling mengagumkan menunjukkan peningkatan kelajuan melebihi 26x untuk beban kerja tertentu seperti omnetpp dan xalanc . Ini mewakili satu kejayaan besar dalam teknologi kompilasi, kerana pendekatan tradisional untuk mempercepatkan LLVM telah menghasilkan peningkatan yang jauh lebih kecil.
Backend ini mencapai keputusan tersebut melalui pendekatan tiga-pass yang diperkemas: pembersihan dan penyediaan IR , analisis untuk gelung dan kepentingan pemboleh ubah, dan pass penjanaan kod gabungan yang mengendalikan penurunan, peruntukan daftar, dan pengekodan kod mesin secara serentak. Reka bentuk ini menghapuskan sebahagian besar overhed yang terdapat dalam seni bina pengkompil tradisional.
IR (Intermediate Representation): Bahasa pengaturcaraan peringkat rendah yang digunakan secara dalaman oleh pengkompil Peruntukan daftar: Proses menetapkan pemboleh ubah program kepada daftar pemproses
Keputusan Benchmark SPEC CPU 2017 (x86-64)
| Benchmark | Peningkatan Kelajuan Kompilasi (-O0 IR) | Nisbah Saiz Kod (-O0 IR) |
|---|---|---|
| 600.perl | 11.39x | 1.27x |
| 602.gcc | 12.54x | 1.32x |
| 605.mcf | 9.72x | 1.27x |
| 620.omnetpp | 21.46x | 1.24x |
| 623.xalanc | 18.99x | 1.24x |
| 625.x264 | 10.52x | 1.26x |
| 631.deepsjeng | 9.60x | 1.25x |
| 641.leela | 21.44x | 1.24x |
| 657.xz | 10.95x | 1.30x |
| Min Geometri | 13.34x | 1.27x |
Respons Komuniti dan Potensi Penggunaan
Komuniti pengkompil telah menunjukkan minat yang ketara terhadap pendekatan TPDE-LLVM , dengan sesetengah pembangun menyatakan kejutan terhadap kekurangan penggunaan meluas teknik-teknik ini. Teknologi ini nampaknya menawarkan kelebihan yang jelas berbanding penyelesaian sedia ada seperti Cranelift dan backend WebAssembly , membawa kepada persoalan mengapa projek pengkompil arus perdana tidak bergegas untuk memasukkan kaedah yang serupa.
Satu bidang yang menarik minat khusus ialah kompilasi WebAssembly , di mana pembangun sedang mempertimbangkan TPDE-LLVM sebagai pengganti berpotensi untuk penyelesaian kompilasi pantas sedia ada. Keupayaan backend untuk berfungsi sebagai perpustakaan menjadikannya sesuai untuk senario kompilasi just-in-time, membuka kemungkinan baharu untuk penjanaan kod runtime.
Batasan Semasa dan Pembangunan Masa Depan
TPDE-LLVM pada masa ini hanya menyokong seni bina x86-64 dan AArch64 serta melaksanakan subset ciri-ciri perwakilan perantaraan LLVM . Para pembangun mengakui bahawa walaupun backend berfungsi dengan baik dengan kod C dan C++ biasa yang dijana oleh Clang , ia mempunyai batasan dengan ciri bahasa yang lebih eksotik dan sesetengah kod Rust yang menggunakan jenis vektor bukan standard.
Peta jalan projek termasuk menambah sokongan penyahpepijatan melalui pelaksanaan format DWARF dan meningkatkan peruntukan daftar melebihi pendekatan spill everything semasa. Platform tambahan dan model kod mungkin ditambah jika terdapat permintaan komuniti yang mencukupi.
Had Semasa dan Ciri-ciri yang Tidak Disokong
- Sokongan bahasa: Berfungsi dengan baik untuk kod Clang C/C++ biasa, sokongan separa untuk Flang , keserasian terhad untuk Rust
- Ciri-ciri yang hilang: Banyak ciri LLVM-IR belum dilaksanakan lagi
- Operasi vektor: Jenis vektor haram tidak disokong (menjejaskan beberapa crate Rust )
- Peruntukan daftar: Pada masa ini menggunakan pendekatan "tumpahkan segala-galanya"
- Penyahpepijatan: Sokongan DWARF dalam peringkat prototaip
- Had platform: ELF sahaja, model kod small-PIC sahaja
Cabaran Teknikal dan Peningkatan LLVM
Proses pembangunan mendedahkan beberapa kesesakan prestasi dalam infrastruktur LLVM yang mempengaruhi kelajuan kompilasi. Isu seperti iterasi pengganti yang perlahan untuk penyata switch dan operasi masa kuadratik untuk blok dengan banyak pendahulu memerlukan penyelesaian kreatif. Menariknya, kira-kira 90% masa kompilasi dalam alat mereka dihabiskan untuk menghurai bitcode berbanding penjanaan kod sebenar.
Pasukan TPDE-LLVM juga telah menyumbang untuk menjadikan LLVM standard lebih pantas, mencapai peningkatan kelajuan 18% dalam versi terkini. Walau bagaimanapun, mereka percaya bahawa mencapai peningkatan kelajuan dramatik yang ditunjukkan oleh pendekatan mereka memerlukan perubahan asas kepada seni bina LLVM yang melampaui pengoptimuman bertahap.