Introducing GNU Compiler Collection (GCC) and Clang/Low Level Virtual Machine (LLVM); comparing the performance of both C/C++ compilers
Visual C++, GNU Compiler Collection (GCC), and Clang/Low Level Virtual Machine (LLVM) are three mainstream C/C++ compilers in the industry. Visual C++ tillhandahåller grafiska användargränssnitt (GUI) och är lätt att felsöka, men det är inte lämpligt för Linux-plattformar. Därför jämför detta dokument främst GCC med Clang/LLVM.
GCC är ett program språk kompilator utvecklad av GNU. Det är en uppsättning fri programvara släppt under GNU General Public License (GPL) och GNU Lesser General Public License (LGPL). Det är en officiell kompilator för GNU-och Linux-systemen och en huvudkompilator för att sammanställa och skapa andra UNIX-operativsystem.
LLVM innehåller en serie modulariserade kompilatorkomponenter och verktygskedjor. Det kan optimera programspråk och länkar under kompilering, körtid och ledig tid och generera kod. LLVM kan fungera som bakgrund för kompilatorer på flera språk. Clang är en C, C++, Objective-C eller Objective-C++ kompilator som sammanställs i C++ baserat på LLVM och släpptes under Apache 2.0-licensen. Clang används främst för att ge prestanda överlägsen GCC.genom långsiktig utveckling och iteration har GCC, Clang och LLVM blivit mogna kompilatorer i branschen. Vilken kompilator är då bättre? Vilken ska vi använda för att sammanställa och bygga program och system?
betydelsen av en bra kompilator
moderna processorer har alla superscalar och långa rörledningar och komplexa interna strukturer, och de stöder vektorförlängningsenheter i den komplexa Instruktionsuppsättningsdatorn (CISC) eller reducerad Instruktionsuppsättningsdator (RISC) arkitektur. För många program som innehåller allmänna datorintensiva kärnor kan programmerare använda vektorförlängningskommandon för att förbättra programmets exekveringsprestanda avsevärt. Till exempel i matris-och vektoroperationer används de kombinerade multiplikations-och additionskommandona för att förbättra prestanda och noggrannhet. Bitmaskkommandon används för grenbearbetning i vektoroperationer. Men för att uppnå högsta prestanda måste programmerare och kompilatorer fortfarande lägga mycket arbete på att hantera uppgifter med komplexa minnesåtkomstlägen och icke-standardiserade kärnor.dessutom abstraherar standarder för moderna avancerade språk ständigt detaljerna i underliggande hårdvara och datastrukturer för att generera allmän kod som är mer logisk och matematisk istället för specifika bruksanvisningar och minnesåtkomstvägar. C++ – standarder blir alltmer uttrycksfulla och abstrakta. Python är populärt eftersom det är mer läsbart och uttrycksfullt, även på bekostnad av en lägre körhastighet. Högre uttrycksförmåga ökar kompilatorns börda för att generera bra monteringskod från de komplexa strukturer som sammanställts av programmerare. Kompilatorn måste vara smartare och arbeta hårdare för att maximera prestanda genom att använda koden. Inte alla kompilatorer kan göra detta. När vi väljer en kompilator måste vi först överväga om samma kodsegment kan generera effektivare monteringskommandon.
förutom att generera högpresterande körbara program måste moderna kompilatorer också ha hög prestanda själva. Ett stort mjukvaruprojekt i C++ kan innehålla hundratals till tusentals enskilda översättningsenheter. Varje översättningsenhet kan innehålla tusentals kodrader. C++ – kod kan också använda ett stort antal mallbaserade programmeringstekniker. Dessa tekniker kräver att kompilatorn överför relevant information flera gånger för att generera en målfil. Sammanställningen av stora C++ – projekt kan ta flera timmar, och flera ömsesidigt beroende förändringar måste lämnas in samtidigt under utvecklingen. Varje inlämning kräver utvecklare att kompilera de flesta kodbibliotek. Därför är snabbare kompilatorer (byggverktyg) kritiska för att uppnå hög produktivitet för stora team.
När det gäller språkförlängning ger moderna datorsystem med flera kärnor, vektorbehandlingsfunktioner och acceleratorer kapacitet som är överlägsen de naturliga egenskaperna hos vanliga programmeringsspråk. Därför kan specifika högpresterande beräkningsramar (HPC), såsom OpenMP och OpenACC, fylla detta gap. Dessa ramar tillhandahåller API: er (application program interfaces) som programmerare kan använda för att uttrycka parallellism i kod. Kompilatorn och motsvarande runtime-bibliotek måste kartlägga parallellkoden till processorarkitekturen. Många HPC-projekt är beroende av OpenMP-och OpenACC-standarder, som utökas av utvecklare och hårdvarutillverkare. Därför måste kompilatorerna hålla jämna steg med utvecklingen av språkförlängningsstandarder.
Sammanfattningsvis tillåter en bra kompilator oss att fokusera på programmeringsprocessen, snarare än att kämpa mot sina brister. Det kan stödja de senaste språkstandarderna, generera optimerade kommandon från den mest abstrakta koden och kompilera källkoden på kortare tid.
GCC Development History
innan du lär dig GCC måste du först förstå GNU-projektet. Richard Stallman lanserade GNU-projektet 1984 för att bygga ett UNIX-liknande program med öppen källkod. GNU-operativsystemet har inte utvecklats mycket över tiden. Det har dock inkuberat många utmärkta och användbara programverktyg med öppen källkod, som Make, Sed, Emacs, Glibc, GDB och GCC också. Dessa GNU open source-program och Linuxkärnor utgör tillsammans GNU / Linux-systemet. I början tillhandahöll GCC stabila och pålitliga kompilatorer, baserade på C-programmeringsspråket, för GNU-systemet. Dess fullständiga namn är GNU C Compiler. Senare stöddes fler språk (som Fortran, Obj-C och Ada), och GCC: s fullständiga namn ändrades till GNU Compiler Collection.
GCC – 1.0 släpptes av Richard Stallman 1987, för mer än trettio år sedan. Ur mjukvaruperspektivet är det väldigt gammalt. Någon samlade in GCC: s utvecklingsrekord mellan 1989 och 2012 och producerade en trettio minuters animerad video (GNU Compiler Collection dev history 1989-2012), vilket intuitivt demonstrerade GCC: s utvecklingsprocess. Vi kan lära oss om GCC: s utvecklingshistoria från dess versioner:
- GCC-1.0: släppt av Richard Stallman 1987.
- GCC-2.0: släpptes 1992 och stödde C++. Senare delades GCC-samhället eftersom Richard Stallman definierade GCC som en pålitlig C-kompilator av GNU-systemet och trodde att GCC vid den tiden var tillräckligt för GNU-systemet och utvecklingsfokus bör flyttas från GCC till själva GNU-systemet. Andra stora utvecklare hoppades kunna fortsätta förbättra GCC och göra mer radikala utvecklingar och förbättringar i olika aspekter. Dessa aktiva utvecklare lämnade GCC-samhället 1997 och utvecklade EGCS-gaffeln.
- GCC-3.0: uppenbarligen hade utvecklare i allmänhet en stark önskan om bra kompilatorer. EGCS-gaffeln utvecklades smidigt och blev erkänd av fler och fler utvecklare. Så småningom användes EGCS som den nya GCC-ryggraden och GCC-3.0 släpptes 2001. Det delade samhället slogs igen igen, men Richard Stallmans inflytande hade försvagats i viss utsträckning. Dessutom hade GCC Industrial Committee börjat bestämma utvecklingsriktningen för GCC.
- GCC-4.0: släpptes 2005. Denna version integrerades i Tree Serial Storage Architecture (SSA), och GCC utvecklades till en modern kompilator.
- GCC-5.0: släpptes 2015. Senare justerades GCC-versionspolicyn och en större version släpptes varje år. En oväntad fördel är att versionsnumret motsvarar året. Till exempel släpptes GCC-7 2017 och GCC-9 släpptes 2019.
nu har GCC-utvecklingen gått in i”modern chronicle”. Inför LLVM: s konkurrenstryck har GCC-samhället aktivt gjort många justeringar, till exempel att påskynda sammanställningen och förbättra sammanställningen varningsinformation. Under de senaste 30 åren har GCC utvecklats från en utmanare i kompilatorindustrin till en vanlig kompilator för Linux-system, och står nu inför LLVM: s utmaning. Lyckligtvis gör GCC-samhället justeringar för att påskynda utvecklingen av GCC. Vi kan förvänta oss att konkurrensen mellan de två kompileringsteknikerna fortsätter att ge mjukvaruutvecklare bättre kompilatorer.
utvecklingshistoria för Clang och LLVM
LLVM härstammar från forskningen av Chris Lattner på UUIC 2000. Chris Lattner ville skapa en dynamisk kompileringsteknik för alla statiska och dynamiska språk. LLVM är en typ av öppen källkodsprogramvara som utvecklats under BSD-licensen. Den ursprungliga versionen 1.0 släpptes 2003. 2005, Apple Inc. anlitade Chris Lattner och hans team för att utveckla programmeringsspråk och kompilatorer för Apple-datorer, varefter utvecklingen av LLVM gick in i snabbfilen. Från och med LLVM 2.5 släpptes två mindre LLVM-versioner varje år (vanligtvis i mars och September). I November 2011 släpptes LLVM 3.0 för att bli standard Xcode-kompilatorn. XCode 5 började använda Clang och LLVM 5.0 som standard. Versionspolicyn justerades för LLVM 5.0 och senare versioner, och två stora versioner släpps varje år. Den nuvarande stabila versionen är 8.0.
namnet på LLVM förkortades först från virtuell maskin på låg nivå. Eftersom detta projekt inte är begränsat till skapandet av en virtuell maskin, är förkortningen LLVM ofta ifrågasatt. Efter att LLVM utvecklades blev det en samlingsbeteckning för många kompileringsverktyg och lågnivåverktygstekniker, vilket gjorde namnet mindre lämpligt. Utvecklare bestämde sig för att överge betydelsen bakom denna förkortning. Nu har LLVM blivit det officiella varumärket, tillämpligt på alla projekt under LLVM, inklusive LLVM Intermediate Representation (LLVM IR), LLVM debugging tools och LLVM C++ standardbibliotek. LLVM kan användas som en traditionell kompilator, JIT-kompilator, assembler, debugger, statiskt analysverktyg och för andra funktioner relaterade till programmeringsspråk.under 2012 vann LLVM software system award of Association for Computing Machinery (ACM), tillsammans med traditionella system som UNIX, WWW, TCP/IP, Tex och Java. LLVM förenklar implementeringen av nya programmeringsspråk verktygskedjor. Under de senaste åren har många nya programmeringsspråk som Swift, Rust och Julia använt LLVM som deras samlingsram. Dessutom har LLVM blivit standardkompilatorn för Mac OS X, iOS, FreeBSD och Android-system.
Clang
Clang är utformad för att ge en frontend kompilator som kan ersätta gcc. Apple Inc. (inklusive nästa senare) har använt GCC som officiell kompilator. GCC har alltid fungerat bra som en standardkompilator i Open source-communityn. Apple Inc. har sina egna krav på kompileringsverktyg. Å ena sidan, Apple Inc. lade till många nya funktioner för Objective – C-språket (eller till och med senare C-språket). GCC-Utvecklare accepterade dock inte dessa funktioner och tilldelade låg prioritet för att stödja dessa funktioner. Senare delades de helt enkelt in i två grenar för separat utveckling, och följaktligen GCC-versionen som släpptes av Apple Inc. är långt tidigare än den officiella versionen. Å andra sidan är GCC-koden mycket kopplad och svår att utvecklas separat. Dessutom fortsätter kodkvaliteten i senare versioner att minska. Men många funktioner som krävs av Apple Inc. (såsom förbättrad integrerad utvecklingsmiljö (IDE) support) måste ringa GCC som en modul, men GCC ger aldrig sådant stöd. Dessutom begränsar GCC Runtime Library-undantaget i grunden utvecklingen av LLVM GCC. Också begränsad av licensen, Apple Inc. kan inte använda LLVM för att ytterligare förbättra kodgenereringskvaliteten baserat på GCC. Därför Apple Inc. beslutade att skriva frontend Clang av C, C++ och Objective-C-språk från början för att helt ersätta GCC.
Som namnet antyder stöder Clang bara C, C++ och Objective-C. utvecklingen startade 2007 och C-kompilatorn slutfördes först. Clang för Objective – C cloud användas fullt ut för produktionsmiljön under 2009. Stöd för C++ utvecklades också snabbt. Clang 3.3 stöds fullt ut C++ 11, Clang 3.4 stöds fullt ut C++ 14 och Clang 5 stöds fullt ut C++ 17, och alla var betydligt före GCC vid den tiden.
Clang/LLVM och GCC Community
liksom andra programvarumiljöer med öppen källkod domineras GCC-communityn av fri mjukvaruentusiaster och hackare. I utvecklingsprocessen bildas GCC-gemenskapens förvaltnings-och deltagandemekanismer gradvis idag. För närvarande är GCC-samhället ett relativt stabilt och väldefinierat bekantskapssamhälle där varje person har tydliga roller och uppgifter: Richard Stallman och Free Software Foundation (FSF): även om det sällan är involverat i GCC community management, är Richard Stallman och FSF fortfarande fristående i licens-och juridiska frågor.
liksom andra open source-samhällen domineras den mogna GCC-gemenskapen inte längre av hackare. Kommersiella företag började spela viktiga roller i samhället, som att rekrytera utvecklare och sponsra utvecklingsmöten. För närvarande domineras GCC-gemenskapen av följande typer av kommersiella företag:
- systemleverantörer, främst inklusive RedHat och SUSE.
- chipleverantörer, främst inklusive Intel, ARM, AMD och IBM (PowerPC).
- specialiserade leverantörer, såsom CodeSourcery och verktygskedja tjänsteleverantörer som AdaCore baserat på ADA språket. CodeSourcery hade en lysande historia och rekryterade många kända utvecklare, men avböjde efter att den förvärvades av Mentor.
i det nuvarande GCC-samhället dominerar chipleverantörer backend-utveckling, medan systemleverantörer styr andra utvecklingsområden. När det gäller samhällsutveckling är GCC-koden för närvarande värd på sin egen SVN-server. Ett Git API tillhandahålls för att underlätta utveckling och inlämning. Patch review liknar den i Linux-Kärngemenskapen och använder formuläret för e-postlista. Som nämnts ovan är GCC-samhället ett relativt stabilt (eller stängt) bekantskapssamhälle. Gemenskapen har i princip 150 till 200 aktiva bidragsgivare varje år och håller en utvecklarkonferens i September varje år. I September 2019 kommer utvecklarkonferensen att hållas i Montreal, Kanada.
LLVM Community
LLVM community är en noob-vänlig kompilatorgemenskap. Det svarar snabbt på frågorna från nya användare och patch recensioner. Detta är också grunden och källan för efterföljande LLVM Foundation diskussioner och antagandet av LLVM Community Code of Conduct, och orsakar en rad politiskt korrekta diskussioner.
alla LLVM-projekt och problem diskuteras via e-postlistan DevExpress, och kodinlämning meddelas via e-postlistan commits. Alla buggar och funktionsändringar spåras genom fellistan. De inlämnade patcharna rekommenderas för huvudgrenarna. Stilen överensstämmer med LLVM-kodningsstandarder och kodgranskning utförs genom Phabricator. För närvarande har LLVM-kodförvaret migrerats till GitHub.
till skillnad från GCC-gemenskapen har LLVM-gemenskapen bara LLVM-Stiftelsen. LLVM-stiftelsen har åtta medlemmar. Förutom att hantera LLVM-samhällsfrågor måste varje medlem av LLVM-Stiftelsen vägleda LLVM-utvecklingsfrågor relaterade till teknik. För närvarande är presidenten Tanya Lattner, fru till Chris Lattner. Chris Lattner själv är också medlem i stiftelsen och har stark kontroll över LLVM-samhället och LLVM: s utvecklingsriktning.
kodgranskningspolicyn i LLVM-gemenskapen är i princip densamma som i GCC-gemenskapen. Skillnaden är att på grund av den snabba utvecklingen av LLVM har många bidragsgivare inte behörighet att begå åtkomst och måste skicka in sin kod via underhållarna. För närvarande har clang-och LLVM-samhällena mer än 1000 bidragsgivare varje år. Generellt hålls utvecklarkonferenser i April och oktober årligen. Utvecklarkonferensen i oktober 2019 kommer att hållas i San Jose, USA.
LLVM-licensen ändras från UIUC-licens till Apache 2.0-licens med LLVM-undantag. Det används främst för att lösa problemet att LLVM runtime library är baserat på MIT-licens och patenttillståndet som krävs för projektet är för omfattande. Under denna licens tillåter LLVM vem som helst att härleda kommersiella produkter från LLVM utan några begränsningar och kräver inte att några derivat tillhandahåller öppen källkod, vilket främjar den omfattande användningen av LLVM, inklusive:
- nedladdning eller användning av LLVM helt eller delvis för personliga, interna eller kommersiella ändamål. Möjligheten att ändra LLVM-kod utan att bidra tillbaka till projektet.
- skapandet av ett paket eller version som innehåller LLVM. Föreningen av LLVM med kod godkänd av alla andra stora open source-licenser (inklusive BSD, MIT, GPLv2 och GPLv3).
- när du distribuerar LLVM igen måste du behålla upphovsrättsmeddelandet. Du kan inte ta bort eller ersätta upphovsrättshuvudet. Den binära filen som innehåller LLVM måste innehålla upphovsrättsmeddelandet.
Prestandajämförelse mellan GCC och LLVM
arkitektur: x86_64
Processor: Intel (r) Xeon (r) Platinum 8163 CPU @ 2.50 GHz
L1 datacache: 32 KB
L2 cache: 1,024 KB
L3 cache: 33,792 KB
minne: 800 GB
operativsystem: Alibaba Group Enterprise Linux Server release 7.2 (Paladin)
kärna: 4.9.151–015.ali3000.alios7.x86_64
kompilator: Clang/LLVM 8.0 GCC8.3.1
Benchmark
SPEC CPU 2017 är en uppsättning CPU-delsystem testverktyg för att testa CPU, cache, minne och kompilator. Den innehåller 43 tester av fyra kategorier, inklusive SPECspeed 2017 INT och FP som testar heltalshastigheten och flytpunktens driftshastighet och SPECrate 2017 INT och FP som testar heltalskonkurrensfrekvensen och flyttalskonkurrensfrekvensen. Clang stöder inte Fortran-språket. Därför används i detta exempel C/C ++ -programmen i SPEC Speed test-uppsättningen för att testa prestandaskillnaden med en kärna mellan de binära program som genereras av Clang och GCC. Följande tabell visar SPEC CPU2017 C och C++ uppsättningar:
CINT2017 SpeedCFP2017 Speed600.perlbench_s619.lbm_s602.gcc_s644.nab_s605.mcf_s620.omnetpp_s623.xalancbmk_s625.x264_s631.deepsjeng_s641.leela_s657.xz_s
testmetoder
LLVM-LNT automation framework används för att utföra testet och jämföra prestanda. Den körs på samma sätt som runcpu av SPEC CPU. Innan LLVM-lnt körs rensas cache (echo 3 > /proc/sys/vm/drop_caches) och sedan körs testdatasetet. Därefter körs ref-datasetet tre gånger. Medelvärdet för de tre ref-testkörningsresultaten används som slutresultatet. För att minska prestandafluktuationer orsakade av CPU-migrering eller kontextswitch är processer som körs på testdatasetet och ref-datasetet bundna till en CPU-kärna med hjälp av CPU affinity-verktyget. För kompileringstidstestet använder denna metod tråd 1 för att bygga testprogrammet och jämföra testobjekten som har sammanställts under lång tid. Kompileringstiden inkluderar inte exekveringstiden för länkar. Det inkluderar bara den tid då alla källfiler i alla testprogram genereras.
jämförelse av Kompileringsprestanda
GCC-kompileringsprocessen är som följer: läs källfilen, förbehandla källfilen, konvertera den till en IR, optimera och generera en monteringsfil. Sedan genererar assembler en objektfil. Clang och LLVM litar inte på oberoende kompilatorer, men integrerar själv implementerade kompilatorer i backend. Processen att generera monteringsfiler utelämnas i processen att generera objektfiler. Objektfilen genereras direkt från IR. Dessutom, jämfört med GCC IR, är datastrukturen för LLVM IR mer kortfattad. Det upptar mindre minne under kompileringen och stöder snabbare traversal. Därför är Clang och LLVM fördelaktiga när det gäller Samlingstiden, vilket bevisas av de data som erhållits från SPEC-sammanställning, som visas i figuren nedan. Clang minskar kompileringstiden med en tråd med 5% till 10% jämfört med GCC. Därför erbjuder Clang fler fördelar för byggandet av stora projekt.
jämförelse av spec kompileringstid
jämförelse av exekveringsprestanda
de flesta molnarbetsbelastningar kräver att programmen kan köras i olika kluster. När du skapar dessa applikationer anger du inte maskinrelaterade parametrar. För att anpassa sig till den snabba iterationen som orsakas av efterfrågeförändringar måste arbetsbelastningar utanför lokalerna också vara felsökningsbara. Därför, förutom vissa stabila och vanliga bibliotek som möjliggör höga kompileringsoptimeringsnivåer, har arbetsbelastningen i sig en låg kompilerings-och optimeringsnivå (O2 eller lägre). För att uppfylla detta krav jämför detta dokument prestanda för olika kompilatorer vid O2-och O3-optimeringsnivåerna för Int-hastighetsprogram, som visas i följande figur:
prestandajämförelse av Spec cpu2017 int Speed
GCC har en prestandafördel på 1% till 4% jämfört med clang och llvm för de flesta program på O2-och O3-nivåerna och har i genomsnitt en prestandafördel på cirka 3% för spec cpu2017 int Speed. När det gäller 600.perlbench_s och 602.gcc_s/ O2, GCC har en stor prestandafördel (mer än 10%). Dessa två testobjekt har inga enastående hotspots och kan återspegla kompilatorns omfattande optimeringseffekt. Testresultaten visar att GCC alltid är fördelaktigt vid prestandaoptimering. Men för två AI-relaterade program, inklusive 631.deepsjeng_s och 641.leela_s, som nyligen lagts till SPEC-testet, clang och LLVM förbättrar prestanda med mer än 3% jämfört med GCC. Detta återspeglar också LLVM: s snabba framsteg när det gäller optimering. För 625. x264_s O2 optimering, LLVM förbättrar prestanda med 40% eftersom hotspot i fallet överensstämmer med de vektoriserade reglerna. Men Clang och LLVM optimerar vektorerna på O2-nivån, medan GCC optimerar vektorerna på O3-nivån. Förutom vektoriserade program förbättrar GCC inte prestandan på O3-nivån jämfört med den på O2-nivån. Med andra ord är programmen inte känsliga för GCC O3-optimering. Däremot förbättrar Clang och LLVM prestanda för vissa program (till exempel 600. perlbench_s och 602. gcc_s) på O3-nivån.
HPC-program, som FP Speed, körs vanligtvis på avancerade servrar. De har stabila kärnalgoritmer, höga krav på prestationsrelaterad vektorisering och parallellism och möjliggör höga optimeringsnivåer (O3 eller högre). Därför jämför detta dokument prestandan på optimeringsnivån O3 + march = native (skylake-avx512), som visas nedan:
prestandajämförelse av spec cpu2017 FP-hastighet
för de två FP-programmen kan gcc också förbättra prestanda med cirka 3%. Clang och LLVM är konservativa i loopoptimering och därmed inte fördelaktiga i prestanda. Polly-delprojektet från Clang och LLVM ger emellertid en loop-och datalokaliseringsoptimerare på hög nivå som har tillämpats i stor utsträckning inom maskininlärning, högpresterande datorer och heterogen Datoroptimering. Jag tror att Polly kan förbättra prestanda för program som innehåller hotspot-loopar som överensstämmer med vektorisering och parallellismregler. Jag kommer också att analysera Pollys prestanda i en serie riktmärken och arbetsbelastningar.
avslutande anmärkningar
Från benchmarking-testerna ovan kan vi se att Clang erbjuder fler fördelar för byggandet av stora projekt medan GCC alltid är fördelaktigt vid prestandaoptimering. Bla beror på din specifika applikation
förutom prestandajämförelse vill jag dela fördelarna och nackdelarna med GCC och Clang och LLVM:
fördelar med GCC
- GCC stöder mer traditionella språk än Clang och LLVM, som Ada, Fortran och Go.
- GCC stöder mer mindre populära arkitekturer och stödde RISC-V tidigare än Clang och LLVM.
- GCC stöder fler språktillägg och fler monteringsspråkfunktioner än Clang och LLVM. GCC är fortfarande det enda alternativet för att sammanställa Linux-kärnan. Även om forskning om kärnkompilering med hjälp av Clang och LLVM också rapporteras i branschen, kan kärnan inte kompileras utan att ändra källkoden och kompileringsparametrarna.
fördelar med Clang och LLVM
- nya språk använder LLVM-ramarna, som Swift, Rust, Julia och Ruby.
- Clang och LLVM uppfyller C-och C ++ – standarderna striktare än GCC. GNU Inline och andra problem under GCC uppgradering uppstår inte.
- Clang stöder också vissa tillägg, till exempel attribut för trådsäkerhetskontroll.
- Clang ger ytterligare användbara verktyg, såsom scan-build och clang statisk analysator för statisk analys, clang-format och clang-tidy för syntaxanalys, samt redaktör plug-in Clangd.
- Clang ger mer exakt och vänlig diagnostisk information, och belyser felmeddelanden, fellinjer, uppmaningar till fellinjer och reparationsförslag. Clang betraktar den diagnostiska informationen som en funktion. Den diagnostiska informationen började förbättras endast från GCC 5.0 och blev Mogen i GCC 8.
(originalartikel av Ma Jun