LLVM News Archives

Following a proposal that began last month, Red Hat engineer Nikita Popov was nominated to become the new lead maintainer for LLVM. Following unaminous approval, as of last week in LLVM Git he's been appointed the official lead maintainer for this critical open-source compiler stack.

LLVM's modern Fortran compiler "flang-new" has now been renamed to "flang" for next year's LLVM 20 update.

LLVM 19.1 is out today as the first stable version of the LLVM 19 compiler stack including the Clang 19 C/C++ compiler.

ClangIR is a new IR for LLVM's Clang compiler built atop MLIR. Thanks to this year's Google Summer of Code, there has been progress on being able to compile GPU kernels using ClangIR as another improvement for heterogeneous programming with this open-source compiler stack.

The LLVM Fortran "Flang" compiler effort has been a long time coming over the years with this programming language continuing to be popular among some HPC codebases and other applications. The "Flang-New" compiler code has been maturing nicely and is looking like soon it could be possibly be renamed to Flang.

A three month old merge request finally landed in mainline LLVM Git this past week to deliver improvements initially for Intel Meteor Lake processors.

In-step with the GCC compiler beginning to see Intel AVX10.2 support patches, the LLVM Clang 20 Git code is already seeing initial AVX10.2 code merged for this open-source compiler.

LLVM 19.1-rc1 was released today as the first tagged development snapshot of LLVM 19 that is working its way toward the stable LLVM 19.1 version expected in September.

Following LLVM/Clang recently dropping support for AMD 3DNow! instructions, the open-source compiler stack is now pushing the MMX SIMD instruction set to a backseat. Moving forward the MMX intrinsics will not make use of MMX but rather be mapped to SSE2. This is all fine unless you are wanting to use this modern code compiler on an Intel Pentium MMX / Pentium II / Pentium III or AMD K6 / K7 processor from the late 90's.

As scheduled, LLVM Clang 19 was branched from mainline Git this morning and is now considered feature frozen ahead of its planned September release. LLVM Clang 20 in turn is now in development with the main Git branch.

The open-source LLVM compiler today dropped support for AMD's long forgotten 3DNow! instructions.

LLVM Clang 19 this morning landed initial support for the -std=c2y and -std=gnu2y options for targeting the next C programming language standard.

Merged on Friday to LLVM 19 Git is a generic MLIR to SPIR-V pass for lowering the Multi-Level Intermediate Representation down into SPIR-V as the intermediate representation consumed by OpenGL / OpenCL / Vulkan drivers.

Apple compiler engineers have contributed Apple M4 CPU support to the upstream LLVM/Clang compiler via the new -mcpu=apple-m4 target. Interestingly the Apple M4 is exposed as an ARMv8.7 derived design.

Merged today to LLVM Clang 19 Git is support for the #embed resource inclusion mechanism that is an approved C23 feature. This also makes Clang the first for supporting this pre-processor embed feature.

SPIR-V used by the likes of OpenGL, OpenCL, and Vulkan is a common intermediate representation (IR) / intermediate language for consumption by device drivers. With code now merged into LLVM, AMD has introduced the notion of vendor "flavored" SPIR-V for containing extra information pertinent to the GPU device/driver being targeted.

Similar to the GCC compiler dropping support for the Xeon Phi Knights Mill and Knights Landing accelerators a few days ago, Intel has also gone ahead and seen to the removal of Xeon Phi support for the LLVM/Clang 19 compiler.

Some that crave the absolute best possible performance sometimes build their software with the "-Ofast" optimization level that is a step above "-O3" but comes with the risk of potentially unsafe math. LLVM developers are now weighing whether to deprecate -Ofast to either remove it or have it just be an alias for the -O3 optimizations.

LLVM's BOLT is an amazing tool for optimizing the layout of binaries and in turn can lead to some mighty useful performance improvements. But now an Arm compiler engineer has taken to leveraging BOLT for creating a binary analysis tool to vet the correctness of security hardening options.

Out today is the big LLVM/Clang 18.1 release. Due to shifting to a new versioning scheme like GCC, today's LLVM 18.1 release is the first major stable release in the new series for what previously would have been called LLVM 18.0.

Merged to the LLVM compiler stack two years ago was the BOLT tool for optimizing the layout of generated binaries for offering even greater performance than the likes of Profile Guided Optimizations (PGO) alone. BOLT had been in development for years by Facebook/Meta engineers and has continued to be improved upon for enhancing the code layout of binaries to yield enhanced performance. Recently there's been renewed work on using BOLT to optimize Linux kernel images.

While the performance of LLVM/Clang is on-par with GCC these days on both x86_64 and AArch64 and the C/C++ support is very robust compared to many years ago, most Linux distributions continue using the GCC compiler and GNU toolchain by default. OpenMandriva is a well known Linux distribution that for several years has been a Clang-built Linux distribution while for three years now the Chimera Linux distribution has also been relying exclusively on an LLVM toolchain.

Following the recent branching of LLVM 18, LLVM 18.1-rc1 was released today as the first test candidate for this half-year update of this widely-used open-source compiler stack.

Being developed the past several years by the SYRMIA embedded software firm is Autocheck, an LLVM/Clang-based project to check C and C++ code to evaluate if it's suitable for running inside automobiles and other safety critical environments. Autocheck is now free and open-source for those wanting to help evaluate the safety of your C/C++ code.

Tom Stellard announced plans this past week for releasing the LLVM 18 compiler stack in early March.

Following discussions with upstream developers, LLVM is changing its versioning as part of the branch creation process to better distinguish mainline development builds of LLVM against those from stable (or soon to be stable) release branches.

As part of Intel's ongoing quest for maximizing the compute performance of their GPUs/accelerators, their compiler engineers have proposed introducing a XeGPU dialect for LLVM's MLIR.

Intel compiler engineers remain quite busy working not only on AVX10 family support but also plumbing in the Advanced Performance Extensions (APX) to be found with future Intel processors.

The LLVM project is now employing profile-guided optimizations (PGO) when building their x86_64 Microsoft Windows release packages. Making use of PGO is able to make their Clang build a stunning 22% faster.

As noted a few weeks back, NVIDIA is working to add OpenACC support to the upstream LLVM Clang compiler for this parallel computing standard. Today that work began landing in LLVM/Clang's development codebase.

A NVIDIA compiler engineer last week laid out the company's plans for implementing OpenACC 3.3 offloading support within the LLVM Clang compiler.

While most hardware vendors are relying on LLVM when it comes to offloading compute work to GPUs, AI accelerators, FPGAs, and similar heterogeneous compute environments, right now each vendor is basically creating their own LLVM offloading run-time among a lot of other duplicated -- and often downstream only -- code. The new "llvm/offload" project hopes to lead to better collaboration in this area.

Intel engineers are proposing that full support for the SYCL programming model be added to upstream LLVM. This is part of their broader oneAPI effort and embracing Khronos' SYCL standard for single-source C++ heterogeneous programming from CPUs to GPUs, FPGAs, and other accelerators.

Merged to LLVM 18 Git yesterday was the initial support for the OpenMP kernel language, an effort around having performance portable GPU codes as an alternative to the likes of the proprietary CUDA.

The LLVM 17 compiler stack has been released as stable as LLVM 17.0.1 -- a slight mistake leaving the 17.0.0-rc tag meant the original v17.0.0 tag was skipped. This LLVM 17.0.1 stable release along with sub-projects like the Clang 17 C/C++ compiler bring many new features and improvements.

LLVM/Clang developers have been working on C23 language support for some time already but to this point it's only been exposed when using the -std=c2x target or -std=gnu2x for the GNU dialect. However, with C2x having been finalized this summer as C23, the LLVM Clang 18 compiler will now honor the -std=c23 option.

The first release candidate of LLVM 17 is now available for testing as what will be the next half-year update to this innovative open-source compiler stack.

Going along with LLVM's recent additions around supporting new Intel instructions coming with future generation Core CPUs, the LLVM 18 Git development code has now landed support for actually honoring -march=arrowlake, -march=arrowlake-s, and -march=lunarlake targets.

Thanks to work carried out by Sony engineers and then offered for upstream, over the past few weeks support for a unified LTO bitcode front-end has materialized within the LLVM codebase.

Following GCC recently adding new x86 instructions for Intel Arrow Lake and Lunar Lake, the LLVM 17 open-source compiler has now received similar treatment.

In a move similar to GCC's implementation, LLVM Git landed this week initial support for fat LTO objects. This "-ffat-lto-objects" support will be found with the LLVM/Clang 17 release this autumn.

While the upstream LLVM/Clang compiler has been building the AArch64 and x86_64 mainline Linux kernel builds for quite some time, for those interested in China's LoongArch CPU architecture it's the latest target seeing work to enable compiling the Linux kernel under Clang.

The LLVM Clang 17 C/C++ compiler when shipping later this year will now use OpenMP 5.1 as the default version of this multi-processing programming API.

The LLVM Fortran compiler "Flang" has begun seeing NVIDIA CUDA support land in the upstream code-base.

Being merged into LLVM's libc library recently are an optimized memory copy function "memcpy" implementation for the RISC-V architecture.

With LLVM Clang's C++23 support coming together and the -std=c++23 option now exposed, LLVM Clang 17 Git has already added its initial options for specifying what will be C++26 / C++2C support.

Merged today to LLVM 17 Git is now recognizing -std=c++23 rather than just -std=c++2b for the Clang compiler now that C++23 has been deemed technically complete.

It's been two weeks already since the release of LLVM 16.0 as the latest shiny feature update to this widely-used, open-source compiler stack. LLVM release manager Tom Stellard today issued LLVM 16.0.1 as the first point release with a wide collection of fixes and other maintenance work to LLVM and its contained sub-projects.

Merged this weekend to the LLVM 17 development code-base is initial support for RISC-V's vector crypto extension ISA.

AMD has upstreamed a basic RPC (remote procedure call) mechanism for GPU use to LLVM's libc and wired it up for AMDGPU use.