Perbedaan antara Clang dan LLVM dibandingkan dengan GCC

Ketika kita menelaah dunia kompilator modern, nama-nama tersebut Clang dan LLVM Singkatan-singkatan ini muncul di mana-mana dan sering digunakan secara bergantian. Namun, di balik akronim-akronim ini terdapat konsep-konsep berbeda yang patut dipahami, terutama jika Anda ingin mendapatkan hasil maksimal dari sistem Anda, distribusi Linux Anda, atau proyek C, C++, atau Objective-C Anda.

Dalam praktik sehari-hari, banyak pengembang lebih terbiasa dengan GCC, tetapi semakin umum untuk menemukan lingkungan yang memprioritaskan Clang sebagai frontend dan LLVM sebagai infrastruktur.Beralih dari satu kompiler ke kompiler lain bukan hanya soal menjalankan biner yang berbeda: ada nuansa dalam kompatibilitas, optimasi, opsi default, dan perilaku produksi yang dapat membuat perbedaan besar.

Hal pertama yang perlu diklarifikasi adalah bahwa LLVM bukanlah sebuah kompiler tunggal.LLVM bukan hanya sekadar alat atau pustaka kompilasi yang berfungsi sebagai dasar untuk berbagai frontend, termasuk Clang. Di antara hal-hal lain, LLVM mencakup pengoptimal kode perantara, backend untuk menghasilkan kode mesin untuk banyak arsitektur, dan pengganti untuk alat-alat klasik seperti ar, nm, ranlib atau bahkan penghubung seperti lld.

Clang, pada gilirannya, adalah bagian depan dari Bahasa C, C++ dan Objective-CObjective-C++, CUDA dan RenderScript Dalam ekosistem LLVM, fungsi utamanya adalah menganalisis kode sumber, memeriksa apakah kode tersebut sesuai dengan standar bahasa, menghasilkan diagnostik yang jelas, dan menerjemahkannya ke dalam representasi perantara (IR) LLVM, yang kemudian akan dioptimalkan dan diubah menjadi kode yang dapat dieksekusi oleh bagian lain dari toolchain.

Artikel terkait:

Perbedaan antara bahasa pemrograman yang paling banyak digunakan

Oleh karena itu, ketika orang berbicara tentang "menggunakan Clang" dalam suatu sistem, sebenarnya mereka sedang menggunakan Clang sebagai kompiler front-end dan LLVM sebagai back-end.dengan opsi untuk juga mengandalkan utilitas pelengkap LLVM (binutils, linker, pustaka runtime, dll.). Misalnya, dimungkinkan untuk menggunakan Clang sebagai pengganti langsung GCC, tetapi tetap menggunakan pustaka standar C++ GCC, runtime-nya, dan, secara umum, sebagian besar infrastruktur GNU.

Satu poin penting adalah bahwa, di banyak sistem Linux, komponen GCC (pustaka C++ standar, unwinder, OpenMP, pustaka sanitizer, dll.) masih blok bangunan dasar sistemMeskipun demikian, opsi untuk membangun toolchain yang hampir seluruhnya berbasis LLVM secara bertahap menjadi mapan, bahkan menggantikan sebagian besar GNU binutils, dan hanya menyisakan pustaka C klasik sebagai komponen yang praktis tak terhindarkan, yang biasanya glibc.

Hubungan antara Clang, LLVM, dan GCC

Setelah peran masing-masing diklarifikasi, penting untuk memahami bagaimana Clang/LLVM dan GCC dibandingkan sebagai rangkaian alat yang lengkap. Kedua proyek ini mengejar tujuan yang serupa: menyusun kode yang efisien dan benar untuk sejumlah besar arsitektur dan platform, tetapi mereka melakukannya dengan desain internal yang berbeda dan dengan keputusan yang berbeda mengenai nilai default dan ekstensi bahasa.

Salah satu tujuan yang dinyatakan dari proyek Clang adalah untuk memelihara sebuah Kompatibilitas tinggi dengan kode yang dirancang untuk GCCDalam praktiknya, ini berarti bahwa di banyak distribusi seperti Gentoo, Anda dapat mencoba menggunakan Clang sebagai kompiler default untuk sebagian besar paket sistem. Namun, gagasan "menggunakan Clang secara sistematis" ini masih dianggap agak eksperimental: beberapa paket bergantung pada ekstensi GCC yang sangat spesifik, yang lain mengasumsikan perilaku tertentu dari opsi default GCC, dan beberapa, meskipun berhasil dikompilasi, memiliki masalah saat dijalankan.

Ketika penggunaan Clang secara global dipaksakan dan terjadi kesalahan, solusi klasiknya biasanya adalah mendefinisikan lingkungan dari menggunakan GCC sebagai alternatifDalam konteks ini, GCC digunakan untuk paket-paket yang tidak berfungsi dengan baik dengan Clang atau dengan pustaka dan runtime alternatif yang disediakan oleh LLVM. Pendekatan campuran ini, yang sangat umum di Gentoo, diimplementasikan melalui konfigurasi di /etc/portage/make.conf dan file lingkungan khusus untuk setiap kompiler.

Aspek lain yang membedakan mereka secara signifikan adalah cara mereka menerapkannya. Optimasi waktu tautan (LTO)Clang/LLVM telah mengembangkan pendekatan mereka sendiri, dengan ThinLTO sebagai mode yang direkomendasikan, sementara GCC menggunakan desain yang berbeda untuk fase LTO-nya. Dalam praktiknya, ini berarti bahwa perilaku, kinerja, dan potensi kegagalan dengan LTO dapat sangat bervariasi tergantung pada kompiler yang digunakan.

Perbedaan utama dibandingkan dengan negara-negara GCC

Salah satu perbedaan paling mencolok yang memengaruhi penggunaan sehari-hari adalah ekstensi bahasa yang didukung oleh setiap kompiler. Clang berupaya untuk kompatibel dengan sebagian besar ekosistem GCC, tetapi Ini tidak mendukung ekstensi khusus GCC tertentu., seperti fungsi bersarang. Hal ini khususnya merupakan salah satu alasan mengapa Clang mengalami kesulitan dalam mengkompilasi paket-paket penting seperti sys-libs/glibcNamun, upaya sedang dilakukan untuk membuat glibc lebih kompatibel dengan alat alternatif.

Terdapat juga perbedaan pada flag yang terkait dengan penanganan operasi floating-point. GCC aktif secara default. -ftrapping-math, sedangkan Clang menggunakan secara default -fno-trapping-mathPerbedaan ini menyiratkan bahwa perilaku terhadap pengecualian floating-point tertentu dapat bervariasi antar kompiler jika pengembang tidak secara eksplisit mendefinisikan bagaimana mereka ingin kasus-kasus ini ditangani dalam proyek mereka.

Poin penting lainnya adalah bagaimana mereka menangani interposisi semantik. GCC mengaktifkannya secara default. -fsemantic-interpositionHal ini memungkinkan penyisipan simbol di seluruh pustaka bersama sesuai dengan aturan penautan ELF, tetapi dapat membatasi beberapa optimasi antarprosedural. Clang, di sisi lain, melakukan optimasi antar-fungsi secara default dan menawarkan opsi tersebut. -fno-semantic-interposition untuk memanfaatkan lebih lanjut optimasi ini ketika kode mengizinkannya dan tidak didasarkan pada interposisi klasik.

Perbedaan desain ini mungkin tampak halus, tetapi memiliki dampak nyata pada cara perangkat lunak dikompilasi dan berperilaku. Seringkali, apa yang "berjalan sempurna" dengan GCC membutuhkan... penyesuaian pada flag atau pada kode sumber agar dapat dikompilasi dan dijalankan dengan benar menggunakan Clang dan sebaliknya, terutama dalam proyek-proyek yang mendorong batasan standar atau bergantung pada detail yang sangat halus dari proses penautan.

Perbedaan kecil namun relevan

Pada tingkat opsi build default, ada juga nuansa yang kurang jelas namun perlu diketahui. Misalnya, GCC menggunakan opsi tersebut secara default. -ffp-contract=fast, sedangkan Clang menggunakan nilai default. -ffp-contract=onKonfigurasi GCC agak lebih agresif dan dapat mengatur ulang atau mengoptimalkan dengan cara yang, dalam skenario tertentu yang sensitif secara numerik, sedikit lebih berisiko. Clang, dengan pengaturan default-nya, cenderung lebih konservatif, yang oleh banyak orang dianggap sebagai perilaku yang lebih aman kecuali jika tujuannya secara eksplisit untuk memaksimalkan kinerja.

Mengenai vektorisasi, hingga versi 12, GCC tidak melakukan optimasi vektor pada level tersebut. -O2 atau lebih rendahNamun, Clang mengaktifkan optimasi vektor di semua level di atasnya. -O1kecuali dalam -Ozdi mana hal itu terbatas pada vektorisasi SLP. Meskipun ini jarang menyebabkan masalah langsung, ini menjelaskan mengapa terkadang kode yang sama mendapatkan Hasil yang berbeda tergantung pada kompiler.bahkan dengan flag optimasi yang tampaknya setara.

Tahapan LTO (Land Transfer Operations) adalah area lain di mana kedua proyek tersebut berbeda. Tahapan LTO dari GCC dan Clang dianggap beroperasi dengan cara yang berbeda. sangat berbedaIni berarti bahwa paket yang dapat dikompilasi dan berfungsi dengan baik dengan LTO di bawah GCC mungkin tidak demikian dengan Clang, dan sebaliknya. Tidak ada aturan umum: dalam banyak kasus, ini bergantung pada pengujian, bug spesifik, dan kekhasan setiap proyek.

Selain itu, ada detail praktis kecil, seperti fakta bahwa Clang, dalam integrasinya dengan distribusi tertentu, Jangan memasang langsung di /usr/bintetapi pada rute spesifik yang ditambahkan ke variabel lingkungan PATHHal ini memengaruhi alat-alat seperti sudo, yang menggunakan PATH Kode tersebut sendiri "dibersihkan" dan dikompilasi ke dalam biner, sehingga ketika versi Clang yang baru muncul, kode tersebut mungkin tidak tersedia dari sudo sampai alat hak akses tersebut dikompilasi ulang atau dikonfigurasi ulang.

Instalasi dan konfigurasi dengan Clang/LLVM

Pada distribusi seperti Gentoo, Clang dan komponen LLVM lainnya dikendalikan melalui Gunakan bendera dan variabel spesifik seperti LLVM_TARGETSYang terakhir ini menentukan arsitektur mana yang digunakan untuk membangun backend LLVM, sesuatu yang sangat penting jika Anda ingin mendukung banyak CPU atau perangkat.

Untuk menginstal Clang, Anda biasanya menggunakan pengelola paket, dan setelah terpasang di sistem Anda, Anda dapat mengkonfigurasinya untuk bertindak sebagai kompiler utama untuk paket tertentu atau secara global. Di Gentoo, cara umum untuk mengatur Clang sebagai kompiler default adalah dengan memodifikasi variabel. CC y CXX di dalam file /etc/portage/make.conf, mengarahkan mereka ke file eksekusi Clang dan padanannya dalam C++.

Strategi lain yang sangat fleksibel adalah menggunakan file lingkungan di /etc/portage/envdi mana "profil" kompiler berbasis Clang dan profil lain berbasis GCC didefinisikan. Ini memungkinkan penugasan profil kompiler melalui file tersebut. /etc/portage/package.env, compiler yang berbeda untuk setiap paketSebagai contoh, gunakan Clang untuk sebagian besar sistem, tetapi paksa penggunaan GCC pada paket yang bermasalah atau sangat sensitif.

Ada beberapa detail historis yang perlu dipertimbangkan. Sebelum versi 14.0.0, Clang Saya tidak punya pilihan. default-pie mirip dengan negara-negara GCCIni memerlukan penyertaan manual. -fPIC en CFLAGS y -pie en LDFLAGS untuk menghasilkan file executable dengan penempatan independen. Pada versi modern, hal ini telah disederhanakan, tetapi jika Anda berasal dari konfigurasi yang lebih lama, ada baiknya untuk meninjau dan membersihkan referensi usang dalam variabel flag.

Bagaimanapun juga, bahkan jika Anda membangun sistem yang sangat berfokus pada Clang dan LLVM, Anda tetap akan membutuhkannya. GCC untuk paket tertentu seperti glibc atau wine. Beberapa distribusi memiliki pelacak bug yang mengkompilasi semua paket yang gagal dikompilasi dengan Clang, membantu memutuskan kapan harus menggunakan kompiler GNU.

Lingkungan cadangan dan pilihan kompiler

Saat menggunakan profil eksperimental berbasis LLVM (tidak sama dengan sekadar menginstal Clang), keterbatasan muncul pada lingkungan cadangan. Lingkungan "cadangan GCC" yang umum mungkin tidak berfungsi sebagaimana mestinya jika seluruh tumpukan diatur untuk menggunakan, misalnya, libc++ sebagai pustaka standar C++Dalam kasus tersebut, bendera seperti -stdlib=libc++ ketika GCC diaktifkan dalam lingkungan darurat tersebut, dan bahkan saat itu pun perilakunya mungkin tidak sesuai harapan.

Ide praktisnya adalah untuk menciptakan di /etc/portage/env misalnya, file konfigurasi. compiler-gcc, mendefinisikan variabel lingkungan yang diperlukan untuk kompilasi dengan GCC. Kemudian, di /etc/portage/package.envPaket-paket yang harus menggunakan lingkungan ini akan ditetapkan. Pola ini diulang dengan kombinasi yang berbeda: Clang tanpa LTO, Clang dengan LTO, GCC tanpa LTO, GCC dengan LTO, dan lain sebagainya.

Oleh karena itu, ketika sebuah paket gagal dengan Clang (karena ekstensi GCC, masalah LTO, ketergantungan silang, dll.), cukup dengan Tambahkan ke daftar paket yang dikompilasi dengan lingkungan lain.Hal ini membuat koeksistensi Clang dan GCC cukup mudah dikelola, asalkan Anda disiplin dalam memelihara file konfigurasi tersebut.

Pada tingkat yang lebih "manusiawi", banyak pengguna bertanya-tanya kompiler mana yang akan dipilih oleh skrip konfigurasi ketika keduanya terinstal. Biasanya, sistem build mengikuti aturan yang jelas: ia melihat variabel lingkungan seperti CC y CXXPeriksa compiler mana yang tersedia di PATHdan dalam beberapa kasus memprioritaskan nama-nama tertentu seperti gcc o clangOleh karena itu, "preferensi" bukanlah sesuatu yang ajaib: hal itu ditentukan oleh konfigurasi sistem dan parameter yang ditentukan oleh pengguna.

Penggunaan tingkat lanjut Clang/LLVM: LTO, PGO, dan lainnya

Clang terintegrasi dengan sangat baik dengan teknik optimasi tingkat lanjut seperti LTO (Link Time Optimization) dan PGO (Profile Guided Optimization). Dalam kasus LTO, kompiler menghasilkan bitcode LLVM alih-alih kode objek tradisional dan menunda sebagian besar optimasi ke fase penautan.

Clang mendukung dua jenis LTO utama. Di satu sisi, LTO selesaiyang menganalisis seluruh unit tautan sekaligus; ini adalah pendekatan klasik, mirip dengan GCC, tetapi saat ini tidak lagi direkomendasikan sebagai pilihan pertama. Di sisi lain, ada TipisLTOdi mana unit tautan dipindai dan dibagi menjadi beberapa bagian. Setiap bagian hanya berisi kode yang relevan dengan cakupannya, mengurangi konsumsi memori, mempercepat kompilasi, dan meningkatkan paralelisme tanpa mengorbankan terlalu banyak kinerja.

Dalam praktiknya, untuk mengaktifkan ThinLTO digunakan sebuah flag seperti -flto=thin dalam variabel kompilasi. Jika Anda ingin menggunakan LTO lengkap, cukup ganti dengan -fltotanpa perbedaan kompatibilitas yang signifikan antara kedua mode tersebut. Namun, perlu diingat bahwa jika paket tersebut clang-common Ini belum dibangun dengan menggunakan flag USE. default-lld, maka perlu ditambahkan -fuse-ld=lld a LDFLAGS sehingga linker LLVM digunakan.

Anda juga dapat menggunakan alat binutils LLVM, seperti llvm-ar, llvm-nm y llvm-ranlibkhususnya saat bekerja dengan bitcode yang dihasilkan LTO. Ini adalah alternatif yang dirancang khusus untuk memahami format tersebut, meskipun pengalaman praktis bervariasi tergantung pada proyek dan tidak selalu menawarkan peningkatan yang jelas dibandingkan alat standar.

Terkait PGO, ekosistem LLVM menyediakan komponen-komponen seperti: clang-runtime dengan bendera USE sanitize y compiler-rt-sanitizers dengan bendera seperti profile u orcMengaktifkan flag USE pgo Pada tingkat global atau paket, informasi eksekusi program secara real-time dapat dikumpulkan dan diberikan kepada kompiler dengan profil-profil ini, sehingga kompiler dapat mengoptimalkan jalur kode yang sering dieksekusi berdasarkan penggunaan aktual.

Selain hal-hal di atas, Clang bekerja sangat baik dengan sistem caching seperti ccacheSetelah Clang terinstal, proyek-proyek ini biasanya bekerja hampir secara otomatis, mempercepat kompilasi ulang. Dan di bidang yang lebih khusus, proyek-proyek seperti Baling-balingPropeller adalah pendekatan PGO yang dirancang untuk mengatasi masalah pada alat seperti Bolt, khususnya konsumsi memori. Propeller bergantung pada Clang dan membutuhkan dependensi seperti... app-arch/zstd dengan bendera USE static-libs, selain itu juga merupakan kompilasi dari sumber yang cukup spesifik.

Masalah umum dan cara mengatasinya menggunakan Clang

Dalam lingkungan di mana Clang bertindak sebagai kompiler utama, kesalahan yang paling umum cenderung berkelompok menjadi beberapa pola khas. Contoh pertama yang jelas adalah... kesalahan kompilasi saat menggunakan LTOJika sebuah paket dikompilasi dengan -flto Dan jika kesalahan berulang muncul di log Portage, solusi praktisnya adalah menonaktifkan LTO untuk paket spesifik tersebut menggunakan lingkungan seperti compiler-clang tanpa LTO.

Terkadang, meskipun LTO dinonaktifkan dalam paket yang bermasalah, masalah tetap berlanjut karena... Pustaka dependen lainnya dikompilasi dengan LTO dan mengalami kerusakan.Contoh klasiknya adalah ketika sebuah paket seperti boehm-gc Hal itu terjadi karena ketergantungannya. libatomic_ops Ini dikompilasi dengan LTO dan menghasilkan perilaku yang tidak terduga. Dalam kasus ini, dependensi tanpa LTO juga harus dibangun ulang, dan harus dipastikan bahwa kedua paket dikompilasi dengan lingkungan yang konsisten.

Jenis masalah umum lainnya terjadi ketika kode sumber menggunakan ekstensi GNU tanpa menentukan standar yang benar melalui bendera -std=GCC biasanya mengizinkan banyak penggunaan ini tanpa memerlukan standar khusus, sementara Clang menonaktifkan beberapa ekstensi yang lebih jarang ini kecuali dinyatakan secara eksplisit. Jika sebuah paket bergantung pada ekstensi ini, paket tersebut harus dikompilasi dengan flag seperti -std=gnu89, -std=gnu99 o -std=gnu++98, sesuai dengan bahasa dan standar yang diharapkan.

Salah satu gejala khas dari masalah ini adalah melihat beberapa definisi fungsi sebaris dalam log kompilasi. Ini karena Clang, secara default, menggunakan aturan inline C99, yang tidak cocok dengan kode yang dirancang untuk gnu89Dalam skenario tersebut, memaksa -std=gnu89 Ini biasanya sudah cukup; jika tidak, selalu ada opsi untuk mengkompilasi paket yang bertentangan dengan GCC menggunakan salah satu lingkungan cadangan.

Keraguan juga sering muncul ketika sistem menunjukkan kesalahan seperti sudo: clang: command not foundYang terjadi di sana adalah Clang telah diinstal di jalur yang ditambahkan ke PATH dari pengguna, tetapi sudo memiliki PATH internalnya sendiriJalur yang ditentukan selama proses kompilasi biner tidak akan menyertakan jalur Clang sampai sudo dikompilasi ulang atau konfigurasinya disesuaikan. Oleh karena itu, sudo tidak akan menemukan Clang, meskipun pengguna biasa dapat menjalankannya tanpa masalah.

Bagi mereka yang menggunakan Gentoo atau distribusi lain dengan pelacakan bug yang detail, referensi utama untuk masalah Clang biasanya adalah... pelacak bug khusus Di sinilah semua bug yang diketahui pada paket yang tidak dapat dikompilasi atau dijalankan dengan benar menggunakan toolchain ini dipusatkan. Jika bug baru ditemukan, pengguna didorong untuk membuat laporan dan agar bug tersebut dikunci di pelacak bug umum, sehingga komunitas dapat memperbaikinya atau mendokumentasikan solusi mereka.

Jika Anda membandingkan semua bagian ini, Anda dapat melihat bahwa tandem Clang + LLVM Ia menawarkan ekosistem yang sangat kuat, fleksibel, dan modern, tetapi tetap berdampingan erat dengan GCC di banyak sistem, terutama pada tingkat yang sensitif seperti pustaka C atau paket-paket yang sangat lama. Memahami perbedaan mereka, bagaimana mereka saling melengkapi, dan penyesuaian apa yang diperlukan pada flag, LTO, atau standar bahasa membuat peralihan di antara keduanya tidak lagi menjadi lompatan ke dalam ketidakpastian dan lebih menjadi alat yang berharga saat menyiapkan lingkungan pengembangan atau sistem Linux kustom Anda.

Isaac

Penulis yang bersemangat tentang dunia byte dan teknologi secara umum. Saya suka berbagi ilmu melalui tulisan, dan itulah yang akan saya lakukan di blog ini, menunjukkan kepada Anda semua hal paling menarik tentang gadget, perangkat lunak, perangkat keras, tren teknologi, dan banyak lagi. Tujuan saya adalah membantu Anda menavigasi dunia digital dengan cara yang sederhana dan menghibur.