Intel throws in the towel on the processors that killed the first Aurora supercomputer — Knights Mill and Knights Landing support removed from LLVM

(Image credit: Argonne National Laboratory)

What once was considered the future of high-performance computing (HPC) in the Aurora supercomputer is now being forgotten. Intel has removed support for its Xeon Phi Knights Mill and Knights Landing accelerators from the LLVM/Clang 19 compiler, which essentially means the end of support for any kind of the MIC architecture once meant to power the Exascale-class Aurora supercomputer, reports Phoronix.

The Knights Mill processors faced numerous delays and reportedly didn't meet performance targets, ultimately resulting in the cancellation of the first revision of the Aurora supercomputer after several years of delays. The DoE later changed the design of Aurora to employ Intel's Sapphire Rapids and Ponte Vecchio compute GPUs and faced yet more delays and performance issues primarily due to problems with Intel's Sapphire Rapids CPUs and Ponte Vecchio compute GPUs. These hardware issues, along with cooling system malfunctions and other stability problems, still prevent Aurora from achieving its full potential. However, the system is now on track for full deployment sometime this year, a whopping nine years since Aurora was first announced. 

"Intel has officially announced these products’ EOL on about Aug. 2017," a statement published by Phoronix says. "Even for now, clang/llvm’s supports on these products are incomplete. For example, knm targets has AVX5124FMAPS instructions, while its intrinsic and assembly support is missing. And it is weird that avx5124fmaps is still listed at llvm/include/llvm/TargetParser/X86TargetParser.def." 

This follows recent news that the GCC compiler dropped support for Intel's Xeon Phi accelerators, perhaps because of Intel's own cease of support by hardware in general. The deprecation began earlier this year with LLVM/Clang 18, and the complete removal will occur with the LLVM 19 release in September. 

Other contributing factors included the previous removals of support in ICC and ICX compilers, which also emitted errors when encountering these accelerators. Intel emphasized that the removal would reduce maintenance efforts, simplifying the development and support processes for current and future compiler versions. 

According to Phoronix, the process of removing support for Xeon Phi began with LLVM/Clang 18, where it was marked as deprecated. This aligns with GCC's approach, which deprecated Xeon Phi in version 14 and removed it in version 15. Intel's decision to eliminate support in LLVM/Clang 19 reflects a broader trend across compilers as the company plans to focus on exact AI and HPC programs. 

This marks the end of a long road for the Larrabee-inspired Xeon Phi products, which Intel officially stopped producing back in 2019

Anton Shilov
Freelance News Writer

Anton Shilov is a Freelance News Writer at Tom’s Hardware US. Over the past couple of decades, he has covered everything from CPUs and GPUs to supercomputers and from modern process technologies and latest fab tools to high-tech industry trends.

  • bit_user
    The headline said:
    Intel throws in the towel ...
    Makes it sound like this is a recent decision. They already discontinued that product line by like 2018 and only kept software support around to fulfill support obligations for existing customers. The warranty terms on most of their datacenter products seem to be 5 years, which would put this withdrawl of support pretty much right on time (since you could still buy Xeon Phi for a while after they announced EOL).

    In case anyone forgot, the discontinuation of Xeon Phi marked their pivot to more classical GPU-like architectures for HPC (i.e. Ponte Vecchio):
    The main problem with those is how absurdly ambitious they were, as if Intel was intent on taking the lead within a single generation. However, in the time it took them to ship it in volume, their competitors got at least 2 generations out the door and Intel ended up having to cancel Ponte Vecchio's immediate successor. Then, with Falcon Shores, they appear to be seriously backtracking on complexity, not unlike how Emerald Rapids is far simpler (at the die/packaging level) than Sapphire Rapids (which also faced massive delays).

    Anyway, I digress... I do appreciate what Intel has done with oneAPI (which I've used on my humble iGPU) and I hope they stay in the GPU compute game. IMO, it was already clear that x86 couldn't directly compete with dGPUs like 10 years ago, but that's what Xeon Phi was trying to do.