LLVM News Archives

Following the recent Hygon C86-4G CPU support added to the GCC 17 compiler, the open-source LLVM Clang compiler has similarly seen Hygon c86-4g-m4 / c86-4g-m6 / c86-4g-m7 CPU support merged.

The LLVM project will begin offering Zstd-compressed archives of their binaries in addition to the existing XZ-compressed releases. LLVM developers are finding Zstd working out great with "significantly reduced" download sizes.

A new proposal volleyed today among LLVM developers is for Multi-Thread Parallel Compilation "MTPC" for the ThinLTO link-time optimization code. This is great news for today's high core count CPUs when looking to compile very large LLVM modules.

Google engineers have been developing JSIR as a high-level intermediate representation (JSIR) for JavaScript that they are already using in production at the company code code analysis and transforming other code/bytecode to JavaScript as well as for deobfuscating JavaScript code.

A proposal was submitted today for launching the RISC-V Compiler Collaboration "RVCC" as an LLVM Incubator project to focus on compiler optimizations for better performance on RISC-V. But before getting too excited, there is already some opposition to the proposal.

Last year LLVM began landing their Distributed ThinLTO "DTLTO" support as an enhancement to their ThinLTO approach for link-time optimizations. An improvement merged this week to LLVM addresses a performance bottleneck discovered when adding files to the link.

A change merged to upstream LLVM Git yesterday for LLVM 23 is moving AMD's HIP to using the new/modern offload driver by default. This aligns with a prior change for NVIDIA CUDA and already in place for OpenMP offloading too.

LLVM/Clang 22.1 was released overnight as the first stable release of the LLVM 22 series. This is a nice, feature-packaged half-year update to this prominent open-source compiler stack with many great refinements.

We are nearing the stable release of LLVM 22 in hopefully two weeks. Out today is the third release candidate of LLVM 22.1 for soliciting more testing of this open-source compiler stack.

Following recent discussions over AI contributions to the LLVM open-source compiler project, they have come to an agreement on allowing AI/tool-assisted contributions but that there must be a human involved that is first looking over the code before opening any pull request and similar. Strictly AI-driven contributions without any human vetting will not be permitted.

LLVM/Clang 22 feature development ended overnight with the code now being branched and working toward a stable release likely by the end of February.

The LLVM/Clang compiler today introduced support for the Ampere Computing Ampere1C CPU core target.

LLVM developers and other stakeholders have begun debating the use of pre-compiled headers "PCH" as a means of speeding up the compiulation of the LLVM compiler infrastructure by 1.5x to 2x than with non-PCH builds.

Google's Propeller is a profile-guided, reflinking optimizer for large codebases. Propeller is built atop LLVM and can allow for whole-program optimizations. Google compiler engineers are now hoping to bring the Propeller tool into the upstream LLVM codebase.

In LLVM Git yesterday for next year's LLVM 22 release the Qualcomm Xqci RISC-V vendor extension is no longer deemed experimental.

Last week a request for comments (RFC) was issued around establishing an LLVM AI Tool Use Policy. The proposed policy would allow AI-assisted contributions to be made to this open-source compiler codebase but that there would need to be a "human in the loop" and the contributor versed enough to be able to answer questions during code review. Separately, yesterday a proposal was sent out for creating an AI-assisted fixer bot to help with Bazel build system breakage.

AMD software engineers continue making interesting contributions to the LLVM compiler stack around SPIR-V as the IR used by Vulkan and other Khronos APIs.

Google engineer Rahman Lavaee today announced their work on a prototype software implementation to automatically insert optimal code prefetches into binaries for faster performance, especially for the latest Intel Granite Rapids and AMD Turin processors with new prefetching instructions.

SYCLBIN has been proposed by a longtime Intel compiler expert as a new way for storing SYCL device code for use as part of their GPU/XPU programming ambitions.

For those preferring for the first point release to major new compiler releases before upgrading, LLVM 21.1.1 is out today along with the likes of Clang 21.1.1 for this widely-used open-source compiler stack.

LLVM 21.1 is out today as the first stable version of the LLVM 21 compiler stack. This half-year stable release to the open-source LLVM compiler software brings new hardware support, new language features, and a lot of other enhancements throughout this massive and widely-used codebase.

Similar to Clang-Tidy for tidying up C/C++ code using LLVM/Clang components, Flang-Tidy is in development as a tool for Fortran static analysis built upon LLVM's modern Flang compiler code. Flang-Tidy may be upstreamed in the future to LLVM while for now it's developed by TU Munich and Max Planck Computing.

For several years now Intel has been working on SYCL support within LLVM and various related efforts like the LLVM SPIR-V back-end as part of their oneAPI ambitions and Data Parallel C++ across their spectrum of hardware. The latest hitting upstream LLVM is libsycl as a SYCL run-time library.

The LLVM compiler toolchain has begun upstreaming support for Distributed ThinLTO "DTLTO" as a new means of handling ThinLTO compilations for leveraging link-time optimizations.

SFrame is the lightweight stack trace format that can overcome some of the performance obstacles for tracing ELF files compared to frame pointers. In addition to the SFrame support coming together in the GNU toolchain, the SFrame support for LLVM/Clang is beginning to reach upstream.

The first release candidate of LLVM 21.1 is now available for testing, which under their modern versioning scheme will represent the first stable version of the LLVM 21 compiler stack.

One of the early changes for the LLVM 22 compiler stack now in development is completing the removal of support for Google's Native Client "NaCl".

The LLVM 21 compiler stack was branched today as release preparations get underway for shipping this next half-year compiler release as stable in late August or early September. In turn that now opens up LLVM 22 for development.

AMD compiler engineer Joseph Huber is the one who ported DOOM to run on GPUs atop ROCm + LLVM libc as part of taking standard C/C++ code to run on GPUs and more recently has also been pursuing Flang/Fortran support atop GPUs. The latest in this ongoing quest is implementing efficient malloc support for memory allocation support on GPUs via the LLVM libc library.

Researchers from the Technical University of Munich (TUM) have announced TPDE as a fast and adaptable compiler back-end framework. The code is now open-source and they are talking up some very wild compile time improvements... Compiling code for x86_64 and AArch64 with TPDE can be ten to twenty times faster than using the LLVM Clang compiler.

The SpacemiT-X60 RISC-V SoC can enjoy some very healthy performance improvements with scheduler definitions now merged for the LLVM/Clang 21 compiler.

Earlier this week IBM announced the z17 mainframes powered by Tellum I processors. But months prior we've seen IBM patches for an "arch15" target for SystemZ within the open-source compilers that we expected was z17. IBM has now confirmed such and has begun updating the open-source compilers to acknowledge this z17 compiler support.

An AMD engineer has landed experimental support within the LLVM codebase for building Flang-RT on GPUs. Flang-RT being the run-time for LLVM's modern Fortran "Flang" compiler and in turn this effort working to allow more Fortran code to easily run on GPUs with capable LLVM back-ends.

Coming out this week was an updated AVX10 whitepaper from Intel with the surprising decision that 512-bit floating point and integer support is no longer considered optional for AVX10.2. AVX10.2 now mandates 128 / 256 / 512-bit support and in turn also dropped the 256-bit embedded rounding support with the focus on 512-bit. The LLVM/Clang compiler had seen its AVX10 support designed around Intel's original AVX10 design assumptions and thus now is being modified to address these changes.

With the newly-released LLVM 20.1 compiler stack among the many changes throughout the massive codebase is renaming the "flang-new" compiler just to "flang". This new Flang compiler front-end has matured quite well over the years to providing robust and reliable Fortran language support within the confines of the LLVM toolchain.

LLVM 20.1 was just tagged in Git as the first stable version of the LLVM 20 compiler stack including sub-projects like the Clang 20 C/C++ Compiler.

Posted to the Linux kernel mailing list this week were two competing solutions for new LLVM Clang capability / thread safety analysis to the Linux kernel. Two developers had separately been working on implementations for the Linux kernel to make use of Clang's "-Wthread-safety" functionality. Ultimately the upstream kernel will likely settle upon the superior or unified solution while already making use of these new checks is uncovering Linux kernel bugs.

The first release candidate working towards the stable release of LLVM 20 is now available for testing.

The LLVM 20 compiler stack saw its code branched from the mainline Git codebase last night as release preparations begin for what will be LLVM 20.1 as the inaugural stable release.

Following a call by Intel developers last month for making the SPIR-V back-end an official target within LLVM as a promotion to its existing "experimental" backend status, the change has now been made ahead of the upcoming LLVM 20 release.

Merged this week into the LLVM compiler codebase is initial support for "arch15" within the SystemZ back-end. Arch15 likely correlates to the IBM z17 mainframes with Telum II processors.

Sony engineers are proposing that the LLVM Clang compiler changes its default C++ mode from C++17 to C++20. This coincides with Sony planning to soon upgrade their PlayStation 5 compiler downstream to C++20 by default.

LLVM development has peaked in recent years at around 37k commits per year for this huge, innovative open-source compiler stack. It was another very exciting year for this leading open-source compiler stack.

Back in early 2023 an Xtensa back-end was added to LLVM for the Cadence Tensilica Xtensa IP. Xtensa is used for DSPs, micro-controllers, and this 32-bit RISC architecture is also used for other hardware like data processing engines. Two years after the LLVM back-end was introduced, the Clang C/C++ compiler has added Xtensa target support.

An interesting "request for comments" proposal I have been meaning to write about since last month is in-development work developing "Safe C++" as an extension to the LLVM Clang compiler and making use of the new, in-development ClangIR.

Merged this week to the LLVM Git codebase ahead of next year's LLVM 20 release is a simple telemetry framework.

The LLVM compiler stack offers a number of sanitizers like the AddressSanitizer, MemorySanitizer, UndefinedBehaviorSanitizer, and others for detecting different coding issues like data races, memory addressing issues, use of uninitialized memory, and more. The newest sanitizer addition to LLVM mainline is TySan as a Type Sanitizer.

Back at the 2024 LLVM Developers' Meeting was an interesting presentation by AMD engineer Joseph Huber for how they have been exploring running common, standard C/C++ code directly on GPUs without having to be adapted for any GPU language / programming dialects or other adaptations.

For those wishing to kick off the new week with some interesting technical videos and are into compiler tech, the video recordings from the 2024 LLVM Developers' Meeting are now online.

Adding to the interesting code building up for next spring's release of the LLVM 20 compiler stack is having the Tenstorrent TT-Ascalon D8 as the newest RISC-V processor target.