Różnice między Clang i LLVM a GCC

Kiedy przyjrzymy się światu nowoczesnych kompilatorów, zauważymy nazwy Clang i LLVM Pojawiają się wszędzie i często są używane zamiennie. Jednak za tymi akronimami kryją się odrębne koncepcje, które warto zrozumieć, zwłaszcza jeśli chcesz w pełni wykorzystać możliwości swojego systemu, dystrybucji Linuksa lub projektów w C, C++ lub Objective-C.

W codziennej praktyce wielu programistów jest bardziej przyzwyczajonych do GCC, ale coraz częściej spotyka się środowiska, które priorytetowo traktują Clang jako front-end i LLVM jako infrastrukturaPrzełączanie się z jednego kompilatora na inny nie polega jedynie na uruchomieniu innego pliku binarnego: istnieją niuanse dotyczące kompatybilności, optymalizacji, domyślnych opcji i zachowania produkcyjnego, które mogą mieć decydujące znaczenie.

Pierwszą rzeczą, którą należy wyjaśnić, jest to, że LLVM nie jest pojedynczym kompilatoremLLVM to nie tylko narzędzie lub biblioteka kompilacyjna stanowiąca fundament dla różnych front-endów, w tym Clanga. LLVM zawiera między innymi pośrednie optymalizatory kodu, back-endy do generowania kodu maszynowego dla wielu architektur oraz zamienniki klasycznych narzędzi, takich jak: ar, nm, ranlib lub nawet łączniki takie jak lld.

Clang ze swojej strony jest front-end Języki C, C++ i Objective-C, Objective-C++, CUDA i RenderScript w ekosystemie LLVM. Jego główną funkcją jest analiza kodu źródłowego, weryfikacja jego zgodności ze standardem języka, generowanie przejrzystych diagnoz i tłumaczenie go na pośrednią reprezentację (IR) LLVM, która następnie jest optymalizowana i przekształcana w kod wykonywalny przez resztę łańcucha narzędzi.

Podobne artykuł:

Różnice między najczęściej używanymi językami programowania

Dlatego, gdy ludzie mówią o „używaniu Clanga” w systemie, w rzeczywistości używają Clang jako kompilator front-end i LLVM jako back-endz możliwością korzystania również z uzupełniających narzędzi LLVM (binutils, linkera, bibliotek uruchomieniowych itp.). Możliwe jest na przykład użycie Clanga jako bezpośredniego zamiennika GCC, ale nadal korzystanie ze standardowej biblioteki GCC C++, jej środowisk uruchomieniowych i, ogólnie rzecz biorąc, znacznej części infrastruktury GNU.

Ważnym punktem jest to, że w wielu systemach Linux komponenty GCC (standardowa biblioteka C++, unwinder, OpenMP, biblioteki sanitizer itp.) są nadal podstawowe elementy składowe systemuMimo to opcja zbudowania zestawu narzędzi opartego niemal całkowicie na LLVM stopniowo zyskała na popularności, zastępując nawet znaczną część binutils GNU i pozostawiając jedynie klasyczną bibliotekę C jako praktycznie nieunikniony komponent, który zwykle jest glibc.

Relacje między Clang, LLVM i GCC

Po wyjaśnieniu roli każdego z nich, ważne jest zrozumienie, jak Clang/LLVM i GCC wypadają w porównaniu jako kompletne łańcuchy narzędzi. Oba projekty realizują podobny cel: kompiluj wydajny i poprawny kod dla wielu architektur i platform, ale wykorzystują one różne wewnętrzne rozwiązania i podejmują różne decyzje dotyczące wartości domyślnych i rozszerzeń językowych.

Jednym z deklarowanych celów projektu Clang jest utrzymanie Wysoka zgodność z kodem zaprojektowanym dla GCCW praktyce oznacza to, że w wielu dystrybucjach, takich jak Gentoo, można spróbować użyć Clanga jako domyślnego kompilatora dla dużej części pakietów systemowych. Jednak ta koncepcja „używania Clanga w całym systemie” jest nadal uznawana za nieco eksperymentalną: niektóre pakiety zależą od bardzo specyficznych rozszerzeń GCC, inne przyjmują pewne zachowania z domyślnych opcji GCC, a niektóre, mimo że się kompilują, mają problemy w czasie wykonywania.

Gdy wymuszone zostanie globalne użycie Clanga i coś się zepsuje, klasycznym rozwiązaniem jest zwykle zdefiniowanie środowiska awaryjny przy użyciu GCCW tym kontekście GCC jest używany w przypadku pakietów, które nie działają dobrze z Clangiem lub alternatywnymi bibliotekami i środowiskami uruchomieniowymi udostępnianymi przez LLVM. To mieszane podejście, bardzo powszechne w Gentoo, jest implementowane poprzez konfiguracje w /etc/portage/make.conf i pliki środowiskowe specyficzne dla każdego kompilatora.

Innym aspektem, w którym znacząco się różnią, jest sposób wdrażania Optymalizacja czasu łącza (LTO)Clang/LLVM opracowały własne podejście, z zalecanym trybem ThinLTO, podczas gdy GCC stosuje inną konstrukcję faz LTO. W praktyce oznacza to, że zachowanie, wydajność i potencjalne awarie LTO mogą się znacznie różnić w zależności od używanego kompilatora.

Kluczowe różnice w porównaniu z GCC

Jedną z najbardziej znaczących różnic wpływających na codzienne użytkowanie są rozszerzenia językowe obsługiwane przez każdy kompilator. Clang dąży do zapewnienia kompatybilności z dużą częścią ekosystemu GCC, ale Nie obsługuje niektórych rozszerzeń specyficznych dla GCC., takich jak funkcje zagnieżdżone. To w szczególności jeden z powodów, dla których Clang miał trudności z kompilacją tak krytycznych pakietów, jak sys-libs/glibcTrwają jednak prace nad zwiększeniem kompatybilności glibc z alternatywnymi narzędziami.

Istnieją również różnice w flagach związanych z obsługą operacji zmiennoprzecinkowych. GCC jest domyślnie aktywny. -ftrapping-math, podczas gdy Clang domyślnie używa -fno-trapping-mathTa rozbieżność oznacza, że ​​zachowanie niektórych wyjątków zmiennoprzecinkowych może się różnić w zależności od kompilatora, jeśli programista nie zdefiniuje wyraźnie, w jaki sposób ma być obsługiwany ten przypadek w jego projekcie.

Kolejnym kluczowym punktem jest sposób, w jaki radzą sobie z interpozycją semantyczną. GCC domyślnie ją włącza. -fsemantic-interpositionPozwala to na wstawianie symboli w bibliotekach współdzielonych zgodnie z zasadami łączenia ELF, ale może to ograniczać niektóre optymalizacje międzyproceduralne. Clang z kolei domyślnie przeprowadza optymalizację międzyfunkcyjną i oferuje opcję -fno-semantic-interposition aby w dalszym ciągu wykorzystywać te optymalizacje, gdy kod na to pozwala i nie opiera się na klasycznej interpozycji.

Te różnice w projekcie mogą wydawać się subtelne, ale mają realny wpływ na sposób kompilacji i działania oprogramowania. Często zdarza się, że to, co „działa idealnie” z GCC, wymaga… zmiany flag lub kodu źródłowego aby kompilować i poprawnie działać z Clangiem i odwrotnie, zwłaszcza w projektach, które wykraczają poza granice standardu lub wymagają bardzo szczegółowych rozwiązań w zakresie łączenia.

Drobne, ale istotne różnice

Na poziomie domyślnych opcji kompilacji istnieją również mniej oczywiste niuanse, które warto znać. Na przykład GCC domyślnie używa tej opcji. -ffp-contract=fast, podczas gdy Clang przyjmuje wartość domyślną -ffp-contract=onKonfiguracja GCC jest nieco bardziej agresywna i umożliwia reorganizację lub optymalizację w sposób, który w pewnych scenariuszach wrażliwych na dane liczbowe jest nieco bardziej ryzykowny. Clang, z domyślnymi ustawieniami, jest zazwyczaj bardziej konserwatywny, co wielu uważa za bezpieczniejsze rozwiązanie, chyba że celem jest maksymalizacja wydajności.

Jeśli chodzi o wektoryzację, do wersji 12 GCC nie przeprowadzał optymalizacji wektorowej na poziomie -O2 lub niższyClang jednak aktywuje optymalizacje wektorowe na wszystkich poziomach powyżej -O1, z wyjątkiem -Ozgdzie jest ograniczony do wektoryzatora SLP. Chociaż rzadko powoduje to bezpośrednie problemy, wyjaśnia, dlaczego czasami ten sam kod otrzymuje różne wydajności w zależności od kompilatoranawet przy pozornie równoważnych flagach optymalizacyjnych.

Fazy ​​LTO to kolejny obszar, w którym oba projekty się rozchodzą. Uważa się, że fazy LTO GCC i Clang działają w odmienny sposób. drastycznie różneOznacza to, że pakiety, które kompilują się i zachowują poprawnie w LTO w GCC, mogą nie kompilować się poprawnie w Clang i odwrotnie. Nie ma jednej, ogólnej reguły: w wielu przypadkach jest to kwestia testów, konkretnych błędów i specyfiki każdego projektu.

Ponadto istnieją drobne szczegóły praktyczne, takie jak fakt, że Clang, w swojej integracji z pewnymi dystrybucjami, Nie instalować bezpośrednio na /usr/binale w określonych trasach, które są dodawane do zmiennej środowiskowej PATHDotyczy to takich narzędzi jak: sudo, którzy używają PATH Sam w sobie jest „wybielony” i skompilowany do pliku binarnego, więc gdy pojawi się nowa wersja Clang, może nie być dostępna sudo dopóki narzędzie uprawnień nie zostanie ponownie skompilowane lub skonfigurowane.

Instalacja i konfiguracja z Clang/LLVM

W dystrybucjach takich jak Gentoo, Clang i pozostałe komponenty LLVM są kontrolowane za pomocą Użyj flag i zmienne specyficzne, takie jak LLVM_TARGETSOstatni parametr określa, dla jakich architektur stworzono zaplecze LLVM, co jest szczególnie ważne, jeśli chcesz obsługiwać wiele procesorów lub urządzeń.

Aby zainstalować Clanga, zazwyczaj korzysta się z menedżera pakietów. Po zainstalowaniu go w systemie można go skonfigurować jako główny kompilator dla określonych pakietów lub globalnie. W Gentoo typowym sposobem ustawienia Clanga jako domyślnego kompilatora jest modyfikacja zmiennych CC y CXX w pliku /etc/portage/make.conf, wskazując im pliki wykonywalne Clang i ich odpowiedniki w C++.

Inną bardzo elastyczną strategią jest wykorzystanie plików środowiskowych w /etc/portage/envgdzie zdefiniowano „profil” kompilatora oparty na Clang i inny na GCC. Pozwala to na przypisanie profili kompilatora za pośrednictwem pliku. /etc/portage/package.env, różne kompilatory na pakietNa przykład, użyj Clanga dla większości systemu, ale wymuś GCC w przypadku problematycznych lub wyjątkowo wrażliwych pakietów.

Należy wziąć pod uwagę szczegóły historyczne. Przed wersją 14.0.0 Clang Nie miałem wyboru default-pie podobny do GCCWymagane jest ręczne dołączenie -fPIC en CFLAGS y -pie en LDFLAGS Generowanie plików wykonywalnych z niezależnym pozycjonowaniem. W nowszych wersjach zostało to uproszczone, ale jeśli korzystasz ze starszych konfiguracji, warto przejrzeć i usunąć przestarzałe odwołania w zmiennych flag.

W każdym razie, nawet jeśli zbudujesz system mocno skoncentrowany na Clang i LLVM, nadal będziesz potrzebować GCC dla niektórych pakietów takich jak glibc czy wine. Niektóre dystrybucje prowadzą systemy śledzenia błędów, które kompilują wszystkie pakiety, których nie udało się skompilować w Clang, pomagając w ten sposób zdecydować, kiedy skorzystać z kompilatora GNU.

Środowiska zapasowe i wybór kompilatora

Podczas korzystania z eksperymentalnych profili zorientowanych na LLVM (co nie jest tym samym, co zwykła instalacja Clanga) pojawiają się ograniczenia związane ze środowiskami awaryjnymi. Typowe środowisko „awaryjne GCC” może nie działać prawidłowo, jeśli cały stos jest skonfigurowany do korzystania z, na przykład, libc++ jako standardowa biblioteka C++W takich przypadkach flagi takie jak: -stdlib=libc++ gdy GCC zostanie wywołane w środowisku awaryjnym, nawet wtedy zachowanie może nie być zgodne z oczekiwaniami.

Praktycznym pomysłem jest stworzenie w /etc/portage/env na przykład plik konfiguracyjny compiler-gccdefiniując zmienne środowiskowe niezbędne do kompilacji za pomocą GCC. Następnie w /etc/portage/package.envPrzypisane są pakiety, które muszą korzystać z tego środowiska. Ten schemat powtarza się w różnych kombinacjach: Clang bez LTO, Clang z LTO, GCC bez LTO, GCC z LTO itd.

W związku z tym, gdy pakiet nie powiedzie się w Clang (z powodu rozszerzeń GCC, problemów LTO, zależności krzyżowych itp.), wystarczy Dodaj go do listy pakietów kompilowanych w innym środowiskuDzięki temu współistnienie Clanga i GCC będzie całkiem łatwe, pod warunkiem, że zachowasz dyscyplinę w utrzymywaniu plików konfiguracyjnych.

Z bardziej „ludzkiego” punktu widzenia wielu użytkowników zastanawia się, który kompilator wybierze skrypt konfiguracyjny, gdy oba są zainstalowane. Zazwyczaj system kompilacji działa zgodnie z jasnymi zasadami: analizuje zmienne środowiskowe, takie jak: CC y CXXSprawdź, jakie kompilatory są dostępne w PATHa w niektórych przypadkach priorytetowo traktuje konkretne nazwy, takie jak gcc o clangDlatego „preferencje” nie są magiczne: określa je konfiguracja systemu i parametry zdefiniowane przez użytkownika.

Zaawansowane wykorzystanie Clang/LLVM: LTO, PGO i inne

Clang bardzo dobrze integruje się z zaawansowane techniki optymalizacji takie jak LTO (Link Time Optimization) i PGO (Profile Guided Optimization). W przypadku LTO kompilator generuje kod bitowy LLVM zamiast tradycyjnego kodu obiektowego i odkłada większość optymalizacji na fazę łączenia.

Clang obsługuje dwa główne typy LTO. Z jednej strony, LTO kompletnektóry analizuje całą jednostkę linku na raz; to klasyczne podejście, podobne do GCC, ale obecnie nie jest już zalecane jako pierwsza opcja. Z drugiej strony, istnieje CienkieLTOgdzie jednostka łącza jest skanowana i dzielona na wiele części. Każda część zawiera tylko kod odpowiadający jej zakresowi, co zmniejsza zużycie pamięci, przyspiesza kompilację i zwiększa paralelizm bez nadmiernego pogorszenia wydajności.

W praktyce do aktywacji ThinLTO stosuje się flagę taką jak: -flto=thin w zmiennych kompilacji. Jeśli chcesz użyć pełnego LTO, po prostu zastąp je -fltobez znaczących różnic w kompatybilności między tymi dwoma trybami. Warto jednak pamiętać, że jeśli pakiet clang-common Nie został zbudowany z flagą USE default-lld, konieczne będzie dodanie -fuse-ld=lld a LDFLAGS tak aby użyć łącznika LLVM.

Można również użyć narzędzi binutils LLVM, takich jak: llvm-ar, llvm-nm y llvm-ranlibzwłaszcza podczas pracy z kodem bitowym generowanym przez LTO. Są to alternatywy zaprojektowane specjalnie z myślą o zrozumieniu tego formatu, choć praktyczne doświadczenie różni się w zależności od projektu i nie zawsze oferują one wyraźne ulepszenia w stosunku do standardowych narzędzi.

W odniesieniu do PGO ekosystem LLVM zapewnia komponenty takie jak: clang-runtime z flagą USE sanitize y compiler-rt-sanitizers z flagami takimi jak profile u orcAktywacja flagi USE pgo Na poziomie globalnym lub na poziomie pakietu informacje o wykonywaniu programów w czasie rzeczywistym mogą być zbierane i przekazywane do kompilatora za pomocą tych profili, dzięki czemu może on optymalizować ścieżki aktywnego kodu na podstawie rzeczywistego wykorzystania.

Oprócz powyższego Clang bardzo dobrze współpracuje z systemami buforowania, takimi jak cachePo zainstalowaniu Clanga projekty te zazwyczaj działają niemal automatycznie, przyspieszając rekompilację. W bardziej wyspecjalizowanej dziedzinie, projekty takie jak ŚmigłoPropeller to podejście PGO zaprojektowane w celu rozwiązania problemów z narzędziami takimi jak Bolt, w szczególności dotyczących zużycia pamięci. Propeller opiera się na Clang i wymaga zależności, takich jak... app-arch/zstd z flagą USE static-libs, a także kompilację z dość konkretnego źródła.

Typowe problemy i sposoby radzenia sobie z nimi za pomocą Clang

W środowiskach, w których Clang pełni rolę głównego kompilatora, najczęstsze błędy grupują się w kilka typowych wzorców. Pierwszym wyraźnym przykładem jest błędy kompilacji podczas korzystania z LTOJeśli pakiet jest kompilowany z -flto Jeśli w logach Portage pojawiają się powtarzające się błędy, praktycznym rozwiązaniem jest wyłączenie LTO dla danego pakietu przy użyciu środowiska takiego jak compiler-clang bez LTO.

Czasami, nawet jeśli LTO jest wyłączone w wadliwym pakiecie, problem nadal występuje, ponieważ Inna zależna biblioteka została skompilowana przy użyciu LTO i działa nieprawidłowoKlasycznym przykładem jest sytuacja, gdy pakiet taki jak boehm-gc Pęka z powodu swojej zależności libatomic_ops Jest kompilowany z użyciem LTO i generuje nieoczekiwane zachowanie. W takich przypadkach należy również odbudować zależność bez LTO i upewnić się, że oba pakiety są kompilowane w spójnym środowisku.

Innym częstym typem problemu jest sytuacja, gdy kod źródłowy używa Rozszerzenia GNU bez określenia prawidłowego standardu przez flagę -std=GCC zazwyczaj zezwala na wiele z tych zastosowań bez konieczności stosowania konkretnego standardu, podczas gdy Clang wyłącza niektóre z tych rzadszych rozszerzeń, chyba że wyraźnie zaznaczono inaczej. Jeśli pakiet wymaga tych rozszerzeń, musi zostać skompilowany z flagami takimi jak: -std=gnu89, -std=gnu99 o -std=gnu++98, stosownie do języka i oczekiwanego standardu.

Typowym objawem tego problemu jest widzenie wiele definicji funkcji wbudowanych w dziennikach kompilacji. Dzieje się tak, ponieważ Clang domyślnie używa reguł wbudowanych C99, które nie pasują dobrze do kodu przeznaczonego do gnu89W tym scenariuszu wymuszanie -std=gnu89 Zwykle to wystarcza; jeśli nie, zawsze istnieje możliwość skompilowania pakietu powodującego konflikt za pomocą GCC, korzystając z jednego ze środowisk zapasowych.

Wątpliwości często pojawiają się również wtedy, gdy system wskazuje błędy, takie jak: sudo: clang: command not foundDzieje się tak, ponieważ Clang został zainstalowany na ścieżce dodanej do PATH od użytkownika, ale sudo utrzymuje własną wewnętrzną ścieżkę PATHŚcieżka zdefiniowana podczas kompilacji binarnej nie będzie zawierać ścieżki Clang, dopóki sudo nie zostanie ponownie skompilowane lub jego konfiguracja nie zostanie zmieniona. W związku z tym sudo nie znajdzie Clang, chociaż zwykły użytkownik może go uruchomić bez problemów.

W przypadku użytkowników Gentoo lub innych dystrybucji ze szczegółowym śledzeniem błędów, głównym źródłem informacji o problemach Clang jest zazwyczaj konkretny system śledzenia błędów To tutaj gromadzone są wszystkie znane błędy w pakietach, które nie kompilują się lub nie działają poprawnie z tym zestawem narzędzi. W przypadku znalezienia nowego błędu, użytkownicy są zachęcani do utworzenia zgłoszenia i umieszczenia go w ogólnym systemie śledzenia błędów, aby społeczność mogła go naprawić lub udokumentować swoje rozwiązania.

Jeśli porównasz wszystkie te elementy, zobaczysz, że tandem Clang + LLVM Oferuje on bardzo wydajny, elastyczny i nowoczesny ekosystem, który w wielu systemach wciąż ściśle współistnieje z GCC, zwłaszcza na wrażliwych poziomach, takich jak biblioteka C czy bardzo stare pakiety. Zrozumienie różnic między nimi, ich wzajemnego uzupełniania się oraz wymaganych korekt w flagach, LTO czy standardach językowych sprawia, że ​​przełączanie się między nimi nie jest skokiem w nieznane, a cenniejszym narzędziem podczas konfigurowania środowiska programistycznego lub niestandardowego systemu Linux.

Isaac

Pisarz z pasją zajmujący się światem bajtów i technologii w ogóle. Uwielbiam dzielić się swoją wiedzą poprzez pisanie i właśnie to będę robić na tym blogu, pokazywać Ci wszystkie najciekawsze rzeczy o gadżetach, oprogramowaniu, sprzęcie, trendach technologicznych i nie tylko. Moim celem jest pomóc Ci poruszać się po cyfrowym świecie w prosty i zabawny sposób.