AMD/Intel Benchmarks: Building The Mainline Linux x86_64 Kernel With LLVM Clang

[FireBurn]

I've just tried builing agd5f's drm-next and didn't get any failures with clang-10 and ld.lld-10

I did however get the following warningsL

  CC      drivers/gpu/drm/amd/amdgpu/atom.o
drivers/gpu/drm/amd/amdgpu/atom.o: warning: objtool: atom_op_move() falls through to next function atom_op_and()
CC      drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_hwss.o
drivers/gpu/drm/amd/amdgpu/../display/dc/dce110/dce110_opp_csc_v.o: warning: objtool: dce110_opp_v_set_csc_default()+0x2ba: can't find switch jump table
  CC      drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.o
  CC      drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_ddc.o
drivers/gpu/drm/amd/amdgpu/../display/dc/dce110/dce110_mem_input_v.o: warning: objtool: dce_mem_input_v_program_pte_vm()+0x254: can't find switch jump table
  CC      drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.o

And this is the diff to the Makefile I used:

diff --git a/Makefile b/Makefile
index 23cdf1f41364..e0fa6fc10f40 100644
--- a/Makefile
+++ b/Makefile
@@ -400,8 +400,8 @@ HOST_LFS_CFLAGS := $(shell getconf LFS_CFLAGS 2>/dev/null)
 HOST_LFS_LDFLAGS := $(shell getconf LFS_LDFLAGS 2>/dev/null)
 HOST_LFS_LIBS := $(shell getconf LFS_LIBS 2>/dev/null)

-HOSTCC       = gcc
-HOSTCXX      = g++
+HOSTCC       = clang
+HOSTCXX      = clang++
 KBUILD_HOSTCFLAGS   := -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 \
                -fomit-frame-pointer -std=gnu89 $(HOST_LFS_CFLAGS) \
                $(HOSTCFLAGS)
@@ -410,15 +410,15 @@ KBUILD_HOSTLDFLAGS  := $(HOST_LFS_LDFLAGS) $(HOSTLDFLAGS)
 KBUILD_HOSTLDLIBS   := $(HOST_LFS_LIBS) $(HOSTLDLIBS)

 # Make variables (CC, etc...)
-AS             = $(CROSS_COMPILE)as
-LD             = $(CROSS_COMPILE)ld
-CC             = $(CROSS_COMPILE)gcc
+AS             = $(CROSS_COMPILE)llvm-as
+LD             = $(CROSS_COMPILE)ld.lld
+CC             = $(CROSS_COMPILE)clang
 CPP            = $(CC) -E
-AR             = $(CROSS_COMPILE)ar
-NM             = $(CROSS_COMPILE)nm
-STRIP          = $(CROSS_COMPILE)strip
-OBJCOPY                = $(CROSS_COMPILE)objcopy
-OBJDUMP                = $(CROSS_COMPILE)objdump
+AR             = $(CROSS_COMPILE)llvm-ar
+NM             = $(CROSS_COMPILE)llvm-nm
+STRIP          = $(CROSS_COMPILE)llvm-strip
+OBJCOPY                = $(CROSS_COMPILE)llvm-objcopy
+OBJDUMP                = $(CROSS_COMPILE)llvm-objdump
 PAHOLE         = pahole
 LEX            = flex
 YACC           = bison

There were also these warnings:

  LD      arch/x86/realmode/rm/realmode.elf
ld.lld: warning: cannot find entry symbol _start; defaulting to 0x1000


mm/hugetlb.c:3967:40: warning: expression does not compute the number of elements in this array; element type is 'unsigned long', not 'u32' (aka 'unsigned int') [-Wsizeof-array-div]
        hash = jhash2((u32 *)&key, sizeof(key)/sizeof(u32), 0);
                                          ~~~ ^
mm/hugetlb.c:3961:16: note: array 'key' declared here
        unsigned long key[2];
                      ^

awk: ./arch/x86/tools/gen-insn-attr-x86.awk:260: warning: regexp escape sequence `\:' is not a known regexp operator
awk: ./arch/x86/tools/gen-insn-attr-x86.awk:350: (FILENAME=./arch/x86/lib/x86-opcode-map.txt FNR=41) warning: regexp escape sequence `\&' is not a known regexp operator

the awk one is present on a GCC build one too

[andyprough]

This is a milestone to be sure, but the fact that Apple/MS/Google and friends took 12 years to get around to fixing the problems associated with compiling this kernel makes me even less likely to trust them to correctly prioritize their work in the future. This is clearly a tool that is designed with their proprietary code and consumer products in mind along with those opensource projects that directly benefit Apple and Google. Libre software will always be an afterthought.

[FireBurn]

This is a milestone to be sure, but the fact that Apple/MS/Google and friends took 12 years to get around to fixing the problems associated with compiling this kernel makes me even less likely to trust them to correctly prioritize their work in the future. This is clearly a tool that is designed with their proprietary code and consumer products in mind along with those opensource projects that directly benefit Apple and Google. Libre software will always be an afterthought.

Took this long to get it compiling on x86_64, Google have been using it on ARM for a while. Apple don't use the linux kernel, neither do MS who'd probably use their own compiler anyway

[staalmannen]

Looking forward to a LLVM/musl-based gentoo flavour (clang, libc++,llvm-binutils)

[HadrienG]

It is not very surprising that performance is similar, given that Linux is one of those projects that go out of their way to defeat compiler optimizations in order to prevent the UB in their code from going wild.

Which kinds of makes sense, really, as much of that code was written before C even had a standard way to do low-level thread synchronization.

[andyprough]

Took this long to get it compiling on x86_64, Google have been using it on ARM for a while. Apple don't use the linux kernel, neither do MS who'd probably use their own compiler anyway

We agree on Apple and Google, who need clang for their own proprietary code-encumbered consumer devices. MS is moving Edge to a chromium base. My understanding is that chromium stopped compiling on MSVC awhile back. Correct me if I'm wrong.

[latalante]

Apple don't use the linux kernel[...]

This is not possible (absolutely not possible).
Millions of servers are needed for the operation of such a large corporation (including to maintain the services for iOS alone).

There are even single patches in the kernel from Apple.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e858faf556d4e14c750ba1e8852783c6f9520a0e

[mroche]

Looking forward to a LLVM/musl-based gentoo flavour (clang, libc++,llvm-binutils)

Actually a bit of a side project of mine. Planning on doing LFS (Linux From Scratch) as a side project a few times, and once I get the hang of it start switching things out for alternatives and see how it goes.

Cheers,
Mike

[Grinch]

Nice to see another compiler toolchain be able to compile the Linux kernel. I tried compiling the kernel using Clang/LLVM with the patches needed a couple of years ago, and while the kernel was built, booting from it just crashed. Now it actually runs, although with some problems that means it's not production ready.

Anyway, having two compiler toolchains able to build Linux means a better likelyhood of catching bugs since problems are more likely to manifest when put under different conditions. Also seeing where one compiler does a better job at optimizing than the other, gives information and incentive to improve, which benefits both toolchains.

The only slight drawback I can think of is perhaps that it will take a bit more time/resources to support two toolchains as opposed to one, assuming Clang/LLVM will be officially supported in the future, which I think it will be.

[staalmannen]

Actually a bit of a side project of mine. Planning on doing LFS (Linux From Scratch) as a side project a few times, and once I get the hang of it start switching things out for alternatives and see how it goes.

Cheers,
Mike

Cool. I was also toying with the idea of a very customized LFS with basically all alternatives

- musl instead of glibc
- Clang, libc++ instead of gcc/stdlibc++
- sbase/ubase instead of coreutils/linuxutils
- nbcurses instead of ncurses
- libedit instead of readline
- mksh instead of bash
- pkgsrc as package manager
- for init: s6, runit, openrc?

Just no time at the moment