Hacker News Reader

Hacker News

Comment by codeshaunted | Hacker News Reader

Parent Full thread

codeshaunted

Is it still the case that the Linux kernel cannot be compiled using clang, or can you do that now?

View on HN

I believe clang has worked for years now.

Why would anyone bother with GCC then? :P

I believe GCC still wins by far on support for weird CPUs and embedded systems.

With LLVM I doubt this will remain true. LLVM makes custom code generation far too easy for GCC to remain viable imo.

I don't have much experience with writing a custom gcc backend, but my experience with LLVM is that its model ends up being a somewhat poor fit for smaller or weirder architectures. For example, LLVM has this annoying tendency to really aggressively promote the size of everything--if you have a 32-bit core with 64-bit memory indexing, LLVM tends to make anything that eventually becomes a memory index a 64-bit computation, even if it would be more efficient to keep everything as 32-bit.

Hm, is it so much easier to write an LLVM back-end than a GCC back-end? I haven't looked into GCC's code gen infrastructure that much, but I looked into making a new back-end to LLVM some time ago and it seemed extremely complex and entirely undocumented. All guidance I found on it basically amounted to, "copy an existing back-end and bang it against a rock until you've made it generate the machine code you need". And it certainly wasn't a case of having clean and simple enough code to make documentation unnecessary. It would honestly surprise me if GCC is more difficult to add a back-end to.

The problem is that "weird CPUs and embedded systems" are not mainstream platforms, nor do they have a lot of money behind them (particularly for open source development). Hence, there is little motivation and/or resources for anyone to develop a new backend for LLVM when a mature GCC backend already exists. Moreover, the LLVM developers are weary to accept new backends for niche platforms when there is no guarantee that they will be maintained in the future.

Exactly - often the GCC branch is barely maintained by whoever is selling the CPU/chip, and it is patches against a specific version that you must use, or it goes haywire.

At least with GCC they can sometimes merge the patches.

It's still a crapshoot.

GCC on xtensa adds extra instructions in several places.

GCC on Arm Cortex-M0 has awful register allocation, and M0 has half as many registers as most ARMs...

GCC still for Linux distributions using glibc or any other library with many "GCCisms". Also, I'm not sure whether or not Clang is ABI compatible enough for enterprise customers with some rather extreme backwards compatibility requirements. Still, I can imagine a future where glibc can be built with Clang, possibly even one where llvm-libc is "good enough" for many users.

Mainly because it was the default for so long, and Clang isn't so much better that distros really need to switch.

GCC is still marginally superior at both code size and performance in my experience.

The main thing I like about clang is it compiles byzantine c++ code much faster.

Some projects like llama.cpp it's like eating nails if you're not using clang.

So with projects like llamafile I usually end up using both compilers.

That's why my cosmocc toolchain comes with -mgcc and -mclang.

https://static.lwn.net/kerneldoc/kbuild/llvm.html

I do remember reading about LTO not working properly, you're either unable to link the kernel with LTO, or get a buggy binary which crashes at runtime. Doesn't look like much effort has been put into solving it, maybe it's just too large a task.

There are a few distros that use Clang as the system compiler (SerpentOS and Chimera Linux for two).

Reply on news.ycombinator.com