Linux 6.3 Drops Support For The Intel ICC Compiler

[phoronix]

Phoronix: Linux 6.3 Drops Support For The Intel ICC Compiler

On this last day of the Linux 6.3 kernel merge window, Linus Torvalds merged the patch dropping support for Intel (ICC) compiler support. Specifically this is Intel's long-standing ICC compiler now known as the "Intel C++ Compiler Classic" prior to its transition to being LLVM/Clang-based with the modern Intel DPC++ compiler...

https://www.phoronix.com/news/Linux-6.3-Drops-Intel-ICC

[Lbibass]

Doesn't really seem like a big loss.

[unwind-protect]

Was it actually generating faster code?

[kiffmet]

unwind-protect Probably not, atleast when not also applying graysky's compiler optimization patch, which can also be used with gcc and clang.

[ms178]

Was it actually generating faster code?

The few times I tried, it failed miserably to even compile the Kernel. I wonder if someone else got it to compile at all in recent times.

[JEBjames]

Michael

Typo in the url text link "talk of the Linxu kernel" should be ""talk of the Linux kernel".

[unwind-protect]

I wonder why Intel now bothers to make a LLVM-backed compiler. Their competitive advantage should be instruction scheduling in the backend, and they just gave up on making a backend.

Or maybe they have lots of changes in their version of the LLVM backend that upstream is not ready to integrate without more testing. But then why make their own frontend?

[aviallon]

I wonder why Intel now bothers to make a LLVM-backed compiler. Their competitive advantage should be instruction scheduling in the backend, and they just gave up on making a backend.

Or maybe they have lots of changes in their version of the LLVM backend that upstream is not ready to integrate without more testing. But then why make their own frontend?

I believe they are just slightly modifying the front-end and backend, eventually also adding some optimizations.

Their big win is profiting from _all_ the work already done on optimization passes, and the massive amount of backends already created for other architectures.

[jabl]

I wonder why Intel now bothers to make a LLVM-backed compiler. Their competitive advantage should be instruction scheduling in the backend, and they just gave up on making a backend.

Or maybe they have lots of changes in their version of the LLVM backend that upstream is not ready to integrate without more testing. But then why make their own frontend?

I'm quite sure they are not doing a new LLVM backend, more like they are adding a few proprietary tweaks here and there to the existing x86 backend. And in the middle-end I suspect they might have added some proprietary optimization passes ported over from their old compiler. Similar story on the frontend, they are using standard clang except they have a wrapper driver for it which understands some of their old icc command-line arguments etc. to make it easier for customers to transition. For the Fortran frontend, AFAIU they have ported their existing Fortran frontend from their old compiler to LLVM, as the LLVM flang frontend isn't mature enough yet.

Also IIRC they are keeping their old proprietary runtime libraries, like the OpenMP runtime (libiomp), and the vectorized math library (SVML). So I guess there's some changes required to their LLVM branch to call these libraries.

So the upsides to them are pretty clear, they are benefiting from a lot of shared work on LLVM, and are adding only a little bit of proprietary sauce on top. Also from a HR perspective, there's a lot of compiler engineers around with LLVM experience.

[pegasus]

I wonder why Intel now bothers to make a LLVM-backed compiler.

Because most of their compiler and math lib people were sitting in Russia and when relationships there soured, they had to scramble for alternatives.