Otwartoźródłowy projekt infrastruktury kompilatorów i zestawu narzędzi LLVM zaliczył lekkie opóźnienie w cyklu wydawniczym. Wersja 10 była planowana do wydania pod koniec lutego, lecz 4 marca opublikowano Release Candidate 3, jakie względem poprzednika urosło o 95 zmian wprowadzonych do głównej gałęzi kodu. Premiera LLVM 10 jest spodziewana w ciągu nadchodzących dni, a starsze rodowodem GCC 10 przewidywane jest na przestrzeni kilku następnych tygodni. Na chwilę obecną, na Bugzilli LLVM pozostają otwarte tylko trzy błędy blokujące wzmiankowane wydanie.

Zobacz też: Apple zmienia powłokę w macOS-ie. Wybiera ZSH, aby tylko uniknąć GPL

Przeczytaj również: Standard C++20 został sfinalizowany. Zwięzłe omówienie popularniejszych nowości

LLVM zostało zaimplementowane przy użyciu języka C++, z myślą dokonywania licznych optymalizacji dla procesów kompilacji, konsolidacji i wykonywania binariów. Oryginalnie był przeznaczony dla języków programowania C i C++, lecz wraz z upływem czasu wzbogacono go o liczne front-endy dla zupełnie różnych wobec siebie języków programowania (LLVM stanowi dla nich warstwę pośredniczącą).

Spotkanie developerów LLVM

Ponadto w dniach 6-7 kwietnia 2020 roku odbędzie się w Paryżu spotkanie deweloperów LLVM. Jednakże każdy zainteresowany rozwojem LLVM może przybyć, po uprzedniej rejestracji.Tego typu mityngi odbywają się dwa razy do roku dzięki działalności Fundacji LLVM. Przewidziano szeroki program odczytów technicznych.

Wybrane nowe funkcje LLVM 10:

1. Clang (front-end kompilatora języków z rodziny C) uruchamiał kompilację w podprosecie ("clang -cc1"). Od teraz domyślnie odbywa się to w procesie ("in-process"). Użycie flagi -fno-integrated-cc przywróci poprzedenie zachowanie. Flagi -v i -### wyświetlą na ekranie "(in-process)" kiedy kompilacja odbędzie się właśnie w procesie. Oprócz tego Clang obsługuje już koncepty (rozszerzenie dla funkcji szablonów), znane ze standardu C++20, a w celu ich włączenia należy użyć flagi -std=c++2a. Pełna obsługa standardu C++20 najprawdopodobniej pojawi się w LLVM 11.
2. Zmieniono domyślne zachowanie dla AVX-512 (rozszerzenia listy rozkazów modelu programowego procesorów x86). Od teraz aktualnym zachowaniem będzie flaga -mprefer-vector-width=256 bowiem bez nałożenia limitu na AVX-512 może dojść do obniżenia taktowania procesora., z powodu wzrostu temperatury procesora. Poprzedni sposób można przywrócić flagą -mprefer-vector-width=512. Analogiczną zmianę wprowadziły kompilatory GCC i ICC, skoro pośród obecnej generacji procesorów obsługujących AVX-512, niższy zegar może przekreślić zyski wynikającej z 512-bitowej szerokości rejestrów.
3. Dodano scheduler Znver2 dla procesorów z rodziny AMD Zen2. Tę optymalizację włączyć można za pomocą flagi -march=znver2.
4. LLVM odtąd obsługuje procesory Cortex-A65, Cortex-A65AE, Neoverse E1 i Neoverse N1.Wprowadzono poprawki dla alternatywnego interfejsu z wierszem poleceń clang-cl, jaki to jest kompatybilny z kompilatorem Visual C++ (cl.exe). W efekcie można zbudować złożony kod dla Windowsa na platformie AArch64, choćby Chromium czy framework Electron. Zoptymalizowano generowanie kodu dla ARMv8.1-M i dodano autowektoryzację MVE (M-Profilowe Rozszerzenie Wektorowe - M-Profile Vector Extension).
5. Wprowadzono także szereg usprawnień (optymalizacja generowanego kodu, nowe platformy sprzętowe, poprawki błędów) dla pozostałych architektur CPU jak MIPS, PowerPC i RISC-V. W przypadku MIPSa wprowadzono m.in obsługę procesorów Octeon+. Na PowerPC włączono wektoryzację dla procedur matematycznych przy użyciu biblioteki MASSV (Mathematical Acceleration SubSystem). W przypadku RISC-V poza szeregiem istotnych ulepszeń umożliwiających wsparcie tej platformy, to położono podwaliny do włączenia optymalizacji LTO w przyszłych wydaniach LLVM.
6. Dodano wsparcie dla MLIR (Multi-Level Intermediate Representation). Jest to warstwa pośrednicząca, zdefiniowana dla uczenia maszynowego i w zamyśle ma stanowić wspólny format między modelami uczenia maszynowego, a frameworkami typu TensorFlow. W tym kontekście zunifikowana infrastruktura jest niezbędna, aby osiągnąć złożone obliczeniowo przetwarzanie modeli uczenia maszynowego. MLIR jest powszechnie wykorzystywany m.in. w Google.

Logika powyższego wyboru, spośród nowych funkcji LLVM, podyktowana została potrzebą ukazania skali złożoności projektu LLVM, tyle że jest to niewielki ułomek spośród długiej listy zmian, skoro LLVM cechuje się modularną budową, niespotykaną wcześniej pośród architektur kompilatorów, toteż poszczególne elementy mogą funkcjonować niezależnie od infrastruktury LLVM, jako samodzielne programy. Przypominać ma to bardziej zestaw bibliotek a nie plików wykonywalnych. Clang, opisany wyżej komponent LLVM, pozostaje domyślnym kompilatorem dla FreeBSD i macOSa (od wersji Xcode 3.2).