Mga Pagkakaiba sa pagitan ng Clang at LLVM kumpara sa GCC

Kapag tiningnan ang mundo ng mga modernong compiler, ang mga pangalan Clang at LLVM Lumalabas ang mga ito kahit saan at kadalasang ginagamit nang palitan. Gayunpaman, sa likod ng mga akronim na ito ay nakasalalay ang mga natatanging konsepto na sulit na maunawaan, lalo na kung gusto mong masulit ang iyong sistema, ang iyong distribusyon ng Linux, o ang iyong mga proyektong C, C++, o Objective-C.

Sa pang-araw-araw na gawain, maraming developer ang mas sanay sa GCC, ngunit nagiging karaniwan na ang makatagpo ng mga kapaligirang nagbibigay-priyoridad Clang bilang frontend at LLVM bilang imprastrakturaAng paglipat mula sa isang compiler patungo sa isa pa ay hindi lamang usapin ng pagpapatakbo ng ibang binary: may mga nuances sa compatibility, mga optimization, mga default na opsyon, at production behavior na maaaring gumawa ng malaking pagkakaiba.

Ang unang bagay na dapat linawin ay Ang LLVM ay hindi isang iisang compilerAng LLVM ay hindi lamang isang tool o compilation library na nagsisilbing pundasyon para sa iba't ibang frontend, kabilang ang Clang. Kabilang sa iba pang mga bagay, ang LLVM ay kinabibilangan ng mga intermediate code optimizer, mga backend para sa pagbuo ng machine code para sa maraming arkitektura, at mga pamalit para sa mga klasikong tool tulad ng ar, nm, ranlib o kahit na mga linker tulad ng lld.

Si Clang, sa bahagi nito, ay ang harapan ng Mga wikang C, C++ at Objective-C, Objective-C++, CUDA at RenderScript sa loob ng ecosystem ng LLVM. Ang pangunahing tungkulin nito ay suriin ang source code, tiyakin na sumusunod ito sa pamantayan ng wika, gumawa ng malinaw na mga diagnostic at isalin ito sa intermediate representation (IR) ng LLVM, na pagkatapos ay ia-optimize at babaguhin sa executable code ng iba pang bahagi ng toolchain.

Kaugnay na artikulo:

Mga pagkakaiba sa pagitan ng mga pinaka ginagamit na programming language

Samakatuwid, kapag pinag-uusapan ng mga tao ang tungkol sa "paggamit ng Clang" sa isang sistema, ginagamit talaga nila Clang bilang front-end compiler at LLVM bilang back-endna may opsyon na umasa rin sa mga komplementaryong kagamitan ng LLVM (binutils, linker, runtime libraries, atbp.). Posible, halimbawa, na gamitin ang Clang bilang direktang kapalit ng GCC, ngunit patuloy na gamitin ang karaniwang library ng GCC C++, ang mga runtime nito, at, sa pangkalahatan, ang karamihan sa imprastraktura ng GNU.

Isang mahalagang punto ay, sa maraming sistema ng Linux, ang mga bahagi ng GCC (karaniwang C++ library, unwinder, OpenMP, mga sanitizer library, atbp.) ay nananatiling mga pangunahing bloke ng pagbuo ng sistemaGayunpaman, ang opsyon na bumuo ng isang toolchain na halos ganap na nakabatay sa LLVM ay unti-unting naitatag, na pumalit pa nga sa malaking bahagi ng mga binutil ng GNU, at iniiwan na lamang ang klasikong C library bilang isang halos hindi maiiwasang bahagi, na kadalasan ay... glibc.

Ugnayan sa pagitan ng Clang, LLVM at GCC

Kapag nalinaw na ang papel ng bawat isa, mahalagang maunawaan kung paano inihahambing ang Clang/LLVM at GCC bilang kumpletong toolchain. Parehong layunin ang hinahangad ng parehong proyekto: mag-compile ng mahusay at tamang code para sa isang malaking bilang ng mga arkitektura at platform, ngunit ginagawa nila ito sa iba't ibang panloob na disenyo at may iba't ibang mga desisyon tungkol sa mga default na halaga at mga extension ng wika.

Isa sa mga nakasaad na layunin ng proyektong Clang ay ang pagpapanatili ng Mataas na compatibility sa code na idinisenyo para sa GCCSa pagsasagawa, nangangahulugan ito na sa maraming distribusyon tulad ng Gentoo, maaari mong subukang gamitin ang Clang bilang default na compiler para sa malaking bahagi ng mga system package. Gayunpaman, ang ideyang ito ng "paggamit ng Clang sa buong system" ay itinuturing pa ring medyo eksperimental: ang ilang mga pakete ay nakasalalay sa mga partikular na extension ng GCC, ang iba ay nagpapalagay ng ilang mga pag-uugali mula sa mga default na opsyon ng GCC, at ang ilan, bagama't nag-compile sila, ay may mga problema sa runtime.

Kapag ang isang pandaigdigang paggamit ng Clang ay pinilit at may nasira, ang klasikong solusyon ay karaniwang tukuyin ang isang kapaligiran ng fallback gamit ang GCCSa kontekstong ito, ginagamit ang GCC para sa mga pakete na hindi gumagana nang maayos sa Clang o sa mga alternatibong library at runtime na ibinibigay ng LLVM. Ang magkahalong pamamaraang ito, na karaniwan sa Gentoo, ay ipinapatupad sa pamamagitan ng mga configuration sa /etc/portage/make.conf at mga environment file na partikular sa bawat compiler.

Isa pang aspeto kung saan sila nagkakaiba nang malaki ay ang paraan ng pagpapatupad nila ng Pag-optimize ng oras ng link (LTO)Ang Clang/LLVM ay bumuo ng sarili nilang pamamaraan, kung saan ang ThinLTO ang inirerekomendang mode, habang ang GCC ay gumagamit ng ibang disenyo para sa mga LTO phase nito. Sa pagsasagawa, nangangahulugan ito na ang pag-uugali, pagganap, at mga potensyal na pagkabigo sa LTO ay maaaring mag-iba nang malaki depende sa compiler na ginamit.

Mga pangunahing pagkakaiba kumpara sa GCC

Kabilang sa mga pinakakapansin-pansing pagkakaiba na nakakaapekto sa pang-araw-araw na paggamit ay ang mga extension ng wika na sinusuportahan ng bawat compiler. Sinisikap ng Clang na maging tugma sa malaking bahagi ng ecosystem ng GCC, ngunit Hindi nito sinusuportahan ang ilang partikular na extension na partikular sa GCC., tulad ng mga nested function. Ito, sa partikular, ang isa sa mga dahilan kung bakit nahirapan si Clang sa pag-compile ng mga kritikal na pakete tulad ng sys-libs/glibcGayunpaman, may mga gawain na isinasagawa upang gawing mas tugma ang glibc sa mga alternatibong kagamitan.

Mayroon ding mga pagkakaiba sa mga flag na may kaugnayan sa paghawak ng mga operasyong floating-point. Aktibo ang GCC bilang default. -ftrapping-math, habang ginagamit ni Clang bilang default -fno-trapping-mathAng pagkakaibang ito ay nagpapahiwatig na ang pag-uugali patungo sa ilang mga floating-point exception ay maaaring mag-iba sa pagitan ng mga compiler kung ang developer ay hindi malinaw na tumutukoy kung paano nila gustong hawakan ang mga kasong ito sa kanilang proyekto.

Ang isa pang mahalagang punto ay kung paano nila pinangangasiwaan ang semantic interposition. Pinapagana ito ng GCC bilang default. -fsemantic-interpositionPinapayagan nito ang paglalagay ng mga simbolo sa mga shared library ayon sa mga panuntunan sa pag-uugnay ng ELF, ngunit maaari nitong limitahan ang ilang interprocedural optimization. Sa kabilang banda, ang Clang ay nagsasagawa ng inter-function optimization bilang default at nag-aalok ng opsyon -fno-semantic-interposition upang higit pang magamit ang mga pag-optimize na ito kapag pinapayagan ito ng code at hindi batay sa klasikong interposisyon.

Ang mga pagkakaiba sa disenyo na ito ay maaaring mukhang banayad, ngunit mayroon silang tunay na epekto sa kung paano nagko-compile at kumikilos ang software. Karaniwan para sa kung ano ang "gumagana nang perpekto" sa GCC na mangailangan ng... mga pagsasaayos sa mga flag o sa source code upang mag-compile at tumakbo nang tama gamit ang Clang at vice versa, lalo na sa mga proyektong lumalampas sa mga limitasyon ng pamantayan o umaasa sa mga pinong detalye ng pag-link.

Maliliit ngunit mahalagang mga pagkakaiba

Sa antas ng mga default na opsyon sa pagbuo, mayroon ding mga hindi gaanong halatang detalye na mahalagang malaman. Halimbawa, ginagamit ng GCC ang opsyon bilang default. -ffp-contract=fast, habang kinukuha ng Clang ang default na halaga -ffp-contract=onAng configuration ng GCC ay medyo mas agresibo at maaaring mag-reorder o mag-optimize sa mga paraan na, sa ilang mga senaryo na sensitibo sa numero, ay medyo mas mapanganib. Ang Clang, kasama ang mga default na setting nito, ay may posibilidad na maging mas konserbatibo, na itinuturing ng marami na mas ligtas na pag-uugali maliban kung ang layunin ay tahasang i-maximize ang performance.

Tungkol sa vectorization, hanggang sa bersyon 12, ang GCC ay hindi nagsagawa ng mga vector optimization sa antas -O2 o mas mababaGayunpaman, pinapagana ng Clang ang mga vector optimization sa lahat ng antas sa itaas. -O1, maliban sa -Ozkung saan ito ay limitado sa SLP vectorizer. Bagama't bihirang magdulot ito ng mga direktang problema, ipinapaliwanag nito kung bakit minsan ang parehong code ay nakukuha iba't ibang ani depende sa compilerkahit na may tila katumbas na mga flag ng optimization.

Ang mga yugto ng LTO ay isa pang aspeto kung saan magkaiba ang dalawang proyekto. Ang mga yugto ng LTO ng GCC at Clang ay itinuturing na gumagana sa magkaibang paraan. ibang-ibaNangangahulugan ito na ang mga paketeng mahusay na nagko-compile at gumagana sa LTO sa ilalim ng GCC ay maaaring hindi gumana sa Clang, at gayundin sa Clang. Walang pangkalahatang tuntunin: sa maraming pagkakataon, ito ay usapin ng pagsubok, mga partikular na bug, at mga partikularidad ng bawat proyekto.

Bukod pa rito, may maliliit na praktikal na detalye, tulad ng katotohanan na ang Clang, sa integrasyon nito sa ilang mga distribusyon, Huwag direktang i-install sa /usr/binngunit sa mga partikular na ruta na idinagdag sa environment variable PATHNakakaapekto ito sa mga kagamitan tulad ng sudo, na gumagamit ng PATH Ito mismo ay "pinaputi" at pinagsama-sama sa binary, kaya kapag lumitaw ang isang bagong bersyon ng Clang, maaaring hindi ito magagamit mula sa sudo hanggang sa muling i-compile o muling i-configure ang privilege tool.

Pag-install at pag-configure gamit ang Clang/LLVM

Sa mga distribusyon tulad ng Gentoo, ang Clang at ang iba pang mga bahagi ng LLVM ay kinokontrol sa pamamagitan ng MGA flag ng USE at mga partikular na baryabol tulad ng LLVM_TARGETSAng huling ito ang tumutukoy kung aling mga arkitektura ang ginagamit para sa pagbuo ng mga LLVM backend, isang bagay na mahalaga kung gusto mong suportahan ang maraming CPU o device.

Para i-install ang Clang, karaniwan mong ginagamit ang package manager, at kapag nasa iyong system na ito, maaari mo itong i-configure upang magsilbing pangunahing compiler para sa ilang partikular na pakete o sa buong mundo. Sa Gentoo, ang karaniwang paraan para itakda ang Clang bilang default na compiler ay ang pagbabago ng mga variable. CC y CXX sa file /etc/portage/make.conf, na itinuturo ang mga ito sa mga Clang executable at sa katumbas nitong C++.

Ang isa pang napaka-flexible na estratehiya ay ang paggamit ng mga environment file sa /etc/portage/envkung saan ang isang "profile" ng compiler batay sa Clang at isa pa sa GCC ay tinukoy. Pinapayagan nito ang pagtatalaga ng mga profile ng compiler sa pamamagitan ng file. /etc/portage/package.env, iba't ibang compiler bawat paketeHalimbawa, gamitin ang Clang para sa halos buong sistema, ngunit pilitin ang GCC sa mga problematiko o lubhang sensitibong pakete.

May mga detalyeng pangkasaysayan na dapat isaalang-alang. Bago ang bersyon 14.0.0, ang Clang Wala akong pagpipilian default-pie katulad ng sa GCCKinakailangan ang manu-manong pagsasama na ito -fPIC en CFLAGS y -pie en LDFLAGS para makabuo ng mga executable na may independent positioning. Sa mga modernong bersyon, pinasimple na ito, ngunit kung galing ka sa mga mas lumang configuration, mainam na suriin at linisin ang mga hindi na ginagamit na reference sa mga flags variable.

Sa anumang kaso, kahit na bumuo ka ng isang sistemang nakatuon nang husto sa Clang at LLVM, kakailanganin mo pa rin GCC para sa ilang partikular na pakete tulad ng glibc o wine. Ang ilang distribusyon ay nagpapanatili ng mga bug tracker na nagko-compile ng lahat ng mga pakete na hindi nakaka-compile gamit ang Clang, na tumutulong sa pagpapasya kung kailan gagamit ng GNU compiler.

Mga fallback na kapaligiran at pagpili ng compiler

Kapag gumagamit ng mga experimental na LLVM-centric profile (hindi katulad ng simpleng pag-install ng Clang), may mga limitasyong lumilitaw sa mga fallback environment. Ang isang tipikal na "GCC fallback" environment ay maaaring hindi gumana nang maayos kung ang buong stack ay naka-set up para gamitin, halimbawa, libc++ bilang isang karaniwang library ng C++Sa mga kasong iyon, ang mga watawat tulad ng -stdlib=libc++ kapag ginamit ang GCC sa emergency na kapaligirang iyon, at kahit na noon, maaaring hindi maging gaya ng inaasahan ang kilos.

Ang praktikal na ideya ay ang paglikha ng /etc/portage/env isang file ng pagsasaayos, halimbawa compiler-gcc, pagtukoy sa mga environment variable na kinakailangan para makapag-compile gamit ang GCC. Pagkatapos, sa /etc/portage/package.envAng mga pakete na dapat gumamit ng environment na ito ay itinalaga. Ang pattern na ito ay inuulit gamit ang iba't ibang kombinasyon: Clang na walang LTO, Clang na may LTO, GCC na walang LTO, GCC na may LTO, atbp.

Kaya, kapag ang isang pakete ay nabigo sa Clang (dahil sa mga extension ng GCC, mga problema sa LTO, mga cross-dependency, atbp.), sapat na ito na Idagdag ito sa listahan ng mga pakete na na-compile gamit ang ibang environmentDahil dito, magiging madali ang pagsasama ng Clang at GCC, basta't disiplinado ka sa pagpapanatili ng mga configuration file na iyon.

Sa mas "pantaong" antas, maraming gumagamit ang nagtataka kung aling compiler ang pipiliin ng isang configuration script kapag pareho itong na-install. Kadalasan, ang build system ay sumusunod sa malinaw na mga patakaran: tinitingnan nito ang mga environment variable tulad ng CC y CXXSuriin kung aling mga compiler ang magagamit sa PATHat sa ilang mga kaso ay inuuna ang mga partikular na pangalan tulad ng gcc o clangSamakatuwid, ang "kagustuhan" ay hindi mahika: ito ay natutukoy ng configuration ng system at ng mga parameter na tinukoy ng user.

Mas masusing paggamit ng Clang/LLVM: LTO, PGO at marami pang iba

Napakahusay na nakikisama ang Clang sa mga advanced na pamamaraan sa pag-optimize tulad ng LTO (Link Time Optimization) at PGO (Profile Guided Optimization). Sa kaso ng LTO, ang compiler ay bumubuo ng LLVM bitcode sa halip na tradisyonal na object code at ipinagpapaliban ang karamihan sa mga pag-optimize sa linking phase.

Sinusuportahan ng Clang ang dalawang pangunahing uri ng LTO. Sa isang banda, ang Kumpleto na ang LTOna sumusuri sa buong link unit nang sabay-sabay; ito ang klasikong pamamaraan, katulad ng GCC, ngunit sa kasalukuyan ay hindi na ito inirerekomenda bilang unang opsyon. Sa kabilang banda, mayroong ThinLTOkung saan ang link unit ay ini-scan at hinahati sa maraming bahagi. Ang bawat bahagi ay naglalaman lamang ng code na may kaugnayan sa saklaw nito, na binabawasan ang pagkonsumo ng memorya, pinapabilis ang compilation, at pinapataas ang parallelism nang hindi isinasakripisyo ang labis na pagganap.

Sa pagsasagawa, upang i-activate ang ThinLTO, isang flag ang ginagamit tulad ng -flto=thin sa mga variable ng compilation. Kung gusto mong gamitin ang buong LTO, palitan lang ito ng -fltonang walang makabuluhang pagkakaiba sa pagiging tugma sa pagitan ng dalawang mode. Gayunpaman, mahalagang tandaan na kung ang pakete clang-common Hindi ito ginawa gamit ang bandila ng USE default-lld, kakailanganing idagdag -fuse-ld=lld a LDFLAGS para magamit ang LLVM linker.

Maaari mo ring gamitin ang mga tool na binutils ng LLVM, tulad ng llvm-ar, llvm-nm y llvm-ranliblalo na kapag gumagamit ng bitcode na binuo ng LTO. Ito ay mga alternatibong partikular na idinisenyo upang maunawaan ang format na iyon, bagama't ang praktikal na karanasan ay nag-iiba depende sa proyekto at hindi sila palaging nag-aalok ng malinaw na mga pagpapabuti kumpara sa mga karaniwang tool.

Tungkol sa PGO, ang LLVM ecosystem ay nagbibigay ng mga bahagi tulad ng clang-runtime may bandilang USE sanitize y compiler-rt-sanitizers na may mga bandila tulad ng profile u orcPag-activate ng USE flag pgo Sa antas ng pandaigdigan o pakete, ang impormasyon sa pagpapatupad ng programa sa real-time ay maaaring kolektahin at ipakain sa compiler gamit ang mga profile na ito, upang ma-optimize nito ang mga hot code path batay sa aktwal na paggamit.

Bukod sa mga nabanggit, mahusay na gumagana ang Clang sa mga caching system tulad ng ccacheKapag na-install na ang Clang, ang mga proyektong ito ay karaniwang halos awtomatikong gumagana, na nagpapabilis sa mga muling pagsasama-sama. At sa mas espesyalisadong larangan, ang mga proyektong tulad ng TagapagbunsodAng Propeller ay isang PGO na pamamaraan na idinisenyo upang tugunan ang mga problema sa mga tool tulad ng Bolt, lalo na ang pagkonsumo ng memorya. Ang Propeller ay umaasa sa Clang at nangangailangan ng mga dependency tulad ng... app-arch/zstd gamit ang bandila ng USE static-libs, bilang karagdagan sa isang koleksyon mula sa isang medyo espesipikong pinagmulan.

Mga karaniwang problema at kung paano haharapin ang mga ito gamit ang Clang

Sa mga kapaligiran kung saan ang Clang ang pangunahing compiler, ang mga pinakakaraniwang error ay may posibilidad na magsama-sama sa ilang tipikal na pattern. Ang isang malinaw na unang halimbawa ay ang mga error sa compilation kapag gumagamit ng LTOKung ang isang pakete ay na-compile gamit ang -flto At kung ang mga paulit-ulit na error ay lumalabas sa mga log ng Portage, isang praktikal na solusyon ay ang pag-disable ng LTO para sa partikular na paketeng iyon gamit ang isang kapaligirang tulad ng compiler-clang walang LTO.

Minsan, kahit na hindi pinagana ang LTO sa nabigong pakete, nagpapatuloy pa rin ang problema dahil Isa pang dependent library ang na-compile gamit ang LTO at hindi gumagana nang maayos.Isang klasikong halimbawa ay kapag ang isang pakete tulad ng boehm-gc Sumasabog ito dahil sa pagdepende nito libatomic_ops Ito ay kino-compile gamit ang LTO at lumilikha ng hindi inaasahang pag-uugali. Sa mga kasong ito, ang dependency na walang LTO ay dapat ding muling itayo, at dapat tiyakin na ang parehong mga pakete ay kino-compile gamit ang isang pare-parehong kapaligiran.

Isa pang karaniwang uri ng problema ang nangyayari kapag ginagamit ng source code ang Mga extension ng GNU nang hindi tinukoy ang tamang pamantayan sa pamamagitan ng bandila -std=Karaniwang pinapayagan ng GCC ang marami sa mga paggamit na ito nang hindi nangangailangan ng isang partikular na pamantayan, habang hindi pinapagana ng Clang ang ilan sa mga bihirang extension na ito maliban kung tahasang nakasaad. Kung ang isang pakete ay nakasalalay sa mga extension na ito, dapat itong i-compile gamit ang mga flag tulad ng -std=gnu89, -std=gnu99 o -std=gnu++98, ayon sa naaangkop na wika at sa inaasahang pamantayan.

Ang isang tipikal na sintomas ng problemang ito ay ang makita maraming kahulugan ng inline na function sa mga talaan ng compilation. Ito ay dahil ang Clang, bilang default, ay gumagamit ng mga C99 inline rule, na hindi maayos na tumutugma sa code na idinisenyo para sa gnu89Sa ganitong senaryo, pinipilit -std=gnu89 Karaniwan itong sapat; kung hindi, palaging may opsyon na i-compile ang magkasalungat na pakete gamit ang GCC gamit ang isa sa mga fallback environment.

Madalas ding nakikita ang mga pagdududa kapag ang sistema ay nagpapakita ng mga error tulad ng sudo: clang: command not foundAng nangyayari roon ay na-install na ang Clang sa isang path na idinagdag sa PATH mula sa gumagamit, ngunit pinapanatili ng sudo ang sarili nitong panloob na PATHAng path na tinukoy sa proseso ng binary compilation ay hindi magsasama ng Clang path hangga't hindi nare-compile ang sudo o naaayos ang configuration nito. Samakatuwid, hindi mahahanap ng sudo ang Clang, bagama't maaaring patakbuhin ito ng isang normal na user nang walang problema.

Para sa mga gumagamit ng Gentoo o iba pang distribusyon na may detalyadong pagsubaybay sa bug, ang pangunahing sanggunian para sa mga isyu sa Clang ay karaniwang isang partikular na tagasubaybay ng bug Dito nakasentro ang lahat ng kilalang bug sa mga pakete na hindi nako-compile o tumatakbo nang tama gamit ang toolchain na ito. Kung may matagpuang bagong bug, hinihikayat ang mga user na magbukas ng ulat at i-lock ito sa pangkalahatang bug tracker, para maayos ito ng komunidad o maidokumento ang kanilang mga solusyon.

Kung ikukumpara mo ang lahat ng mga piyesang ito, makikita mo na ang tandem Clang + LLVM Nag-aalok ito ng isang napakalakas, flexible, at modernong ecosystem, ngunit isa na nananatiling malapit na nabubuhay kasama ng GCC sa maraming sistema, lalo na sa mga sensitibong antas tulad ng C library o mga lumang pakete. Ang pag-unawa sa kanilang mga pagkakaiba, kung paano sila nagpupuno sa isa't isa, at kung anong mga pagsasaayos ang kinakailangan sa mga flag, LTO, o mga pamantayan ng wika ay ginagawang mas mahalaga ang paglipat sa pagitan ng mga ito at hindi gaanong isang malaking hakbang patungo sa hindi alam at mas mahalaga itong gamitin kapag nagse-set up ng iyong development environment o custom na Linux system.

Isaac

Masigasig na manunulat tungkol sa mundo ng mga byte at teknolohiya sa pangkalahatan. Gustung-gusto kong ibahagi ang aking kaalaman sa pamamagitan ng pagsusulat, at iyon ang gagawin ko sa blog na ito, ipakita sa iyo ang lahat ng mga pinaka-kagiliw-giliw na bagay tungkol sa mga gadget, software, hardware, teknolohikal na uso, at higit pa. Ang layunin ko ay tulungan kang mag-navigate sa digital na mundo sa simple at nakakaaliw na paraan.