QBE - Backend Compiler: Versi 1.3

• Optimasi performa besar telah ditambahkan, sehingga QBE 1.3 mencatat lebih dari 63% performa compiler komersial pada coremark vanilla, dan meningkat 33% dibanding qbe-1.2 pada rangkaian pengujian Hare
• QBE 1.3 adalah rilis terbesar sejak 1.0, mencakup sekitar 7k baris tambahan dan penghapusan 1.5k baris
• Optimasi baru mencakup GVN/GCM, optimasi loop, eliminasi if, penyederhanaan CFG, dan lain-lain, tetapi hanya beberapa pass yang sudah tervalidasi yang dipertahankan
• Inlining dikecualikan dari set optimasi kali ini karena ada masalah ketidakcocokan dengan model kompilasi streaming per fungsi milik QBE
• Pada varian coremark yang meng-inline ee_isdigit dan mengganti crcu8 dengan implementasi tanpa percabangan yang lebih sederhana, QBE mencapai 70% performa dibanding gcc -O2, yang menjadi targetnya
• Alat OCaml baru mgen mengompilasi pola IL bergaya lispy menjadi kode pencocokan C, sehingga dapat menggantikan atau menyederhanakan logika pemilihan instruksi yang sebelumnya ditulis manual
• mgen mencari pola IL dalam blok komentar khusus lalu menyisipkan kode C tepat di bawahnya, dan contoh penggunaan saat ini ada di isel.c
• Pencocokan DAG instruksi mengikuti pendekatan penomoran yang mirip dengan cara kerja compiler Plan9 C karya Ken Thompson, dan juga menghasilkan matcher bytecode sederhana yang diinterpretasikan oleh runmatch()
• Dukungan Windows ABI telah ditambahkan, sehingga kompilasi untuk target Windows kini dimungkinkan dengan memberikan -t amd64_win
• Assembler yang dihasilkan QBE masih memakai sintaks AT&T, dan disarankan untuk mengompilasikannya dengan assembler mingw
• Dukungan kode independen posisi telah ditingkatkan sehingga pada sebagian besar target dapat melakukan linking ke shared object dengan lebih mulus dan membuat shared object
• Flag konstanta dinamis extern baru (DYNCONST) memungkinkan representasi akses tidak langsung pada level IL untuk simbol global seperti variabel pustaka dinamis

[GN⁺]

Komentar Lobste.rs

• Saya sedang membuat OS kecil bergaya TRIPOS/Amiga Exec sebagai proyek hobi jangka panjang
  Tidak ada perlindungan memori, peta memorinya datar, dan pengiriman pesan pun pada dasarnya hanya sebatas meneruskan pointer
  Untuk membuat sistem seperti ini bisa self-hosting, compiler kecil yang bisa menghasilkan PIE/PIC jauh lebih praktis. Library bergaya Amiga tentu harus berupa PIC, dan juga enak karena saat menaruh executable di suatu tempat pada peta memori bersama, tidak perlu banyak patch saat load time
  GCC dan Clang bisa melakukannya, tetapi terlalu besar. Terakhir saya cek, TCC belum bisa PIC, jadi saya perlu melihat QBE lebih jauh

  • Compiler C saya bisa menghasilkan PIC, jadi mungkin menarik: https://codeberg.org/lsof/antcc/
    Semoga ini tidak terdengar seperti promosi diri. Saya memang sangat menyukai dunia compiler kecil, dan masih butuh lebih banyak pengujian
  • Saya juga sedang membuat Ashet OS, OS dengan peta memori datar, semuanya PIE, dan system call berupa pemanggilan fungsi
    Sudah cukup jauh perkembangannya, dan mendukung beberapa platform
    Sepertinya akan sulit mencapai self-hosting dalam waktu dekat. Saya butuh pembuatan kode Thumb-2, dan secara praktis satu-satunya cara untuk menjalankannya adalah menulis compiler sendiri. Ada juga batasan bahwa RAM yang tersedia hanya 8MB, di luar kode kernel
    Saya memakai format executable sendiri, .ashex, yang dibuat dengan mengonversi file ELF. Dalam proses ini, format tersebut pada dasarnya memakai section khusus yang hanya berisi satu lompatan absolut, lalu app loader menulis ulang itu menjadi alamat system call yang sebenarnya
    Tantangan sistem memori datar adalah mendukung shared object dengan rapi. Agar kode bisa dibagikan di antara aplikasi yang berbeda, diperlukan dukungan compiler supaya semua akses simbol dinamis dilakukan melalui variabel yang disimpan di register

• Saya sangat senang ada kata kunci extern yang baru
  Ini tidak disebutkan di catatan rilis, tetapi ternyata juga bekerja bersama thread, sehingga memungkinkan initial-exec TLS. Ini diperlukan saat mengakses variabel global thread-local yang didefinisikan di shared library lain, dan dibutuhkan oleh ctype.h di FreeBSD
  extern juga diperlukan untuk mengakses variabel global biasa di shared library pada platform seperti macOS atau Haiku, misalnya stderr. Sekarang compiler berbasis QBE bisa mendukung jauh lebih banyak sistem operasi dan use case
  Saya juga sangat berterima kasih atas peningkatan performa dari Roland. Benar-benar pekerjaan yang luar biasa

• Kalau saya membacanya dengan benar, apakah ini berarti sudah ada dukungan Windows resmi?
  Bukankah ini salah satu keterbatasan besar QBE, baik secara historis maupun sampai sekarang? Senang sekali melihatnya

• Apakah tujuan proyek ini tumpang tindih dengan Cranelift? Saya kurang mendapat gambaran kapan sebaiknya memakai QBE

  • QBE itu semacam “OpenBSD”-nya dunia backend compiler. Filosofinya adalah kesederhanaan dan minimalisme, dan menurut penjelasan resminya, tujuannya adalah “memberikan 70% performa compiler optimisasi kelas industri dengan 10% kode”
    Pesaing nyatanya memang Cranelift dan LLVM
    Sayangnya, dulu kebanyakan dipakai di bahasa hobi atau implementasi compiler. Misalnya myrddin, yang dulu tampak seperti bahasa keluarga C baru, sekarang tampaknya sudah mati, sementara cproc masih hidup sebagai implementasi compiler C hobi
    Meski begitu, sejak Hare mengadopsi QBE, ada alasan untuk optimis. Jawaban untuk pertanyaan ini ada di sini: https://harelang.org/documentation/faq.html#why-qbe-instead-of-llvm
  • Menurut saya targetnya tumpang tindih bukan hanya dengan Cranelift, tetapi juga LLVM
    Saya tidak terlalu mendalaminya, tetapi ada banyak materi perbandingan. Sejauh yang saya tahu, QBE memang mengarah menjadi backend yang jauh lebih sederhana dibanding dua yang lain

• Pendekatan menggunakan DSL kecil untuk menghasilkan matcher pemilihan instruksi itu sangat keren