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

[ms178]

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

There were patches for the awk warnings on the LKML and as you noticed they were not Clang specific. If I remember correctly, the others are already known problems: https://github.com/ClangBuiltLinux/linux/issues

The AMDGPU warnings sound familiar, also the realmode.elf / LLD problem. I am not sure about the hugetlb error. Please file issues at the Github repo above if you can't find them.

[mroche]

If any distro decides to compile everything with Clang because GPLv3 is supposedly bad, I'll laugh at them, and consider writing mails to companies that can tivotize their work.

Compiling with Clang has nothing to do with GPL. Clang still uses the host C/C++ libraries, so those are what would have to be replaced. Clang is a frontend for using libstdc++ (GPL) or other options like the LLVM's project libc++/libc++abi which are not GPL. All the license on Clang does is allow application developers, like those of IDE's, the ability to ship Clang along with the app and extend it's dev toolset without having to release those changes. It has no bearing on just using it for compiling.

Choosing to not use GNU libraries and utilities is not a strictly GPL licensing issue. There are other reasons for not using them, such as size/bloat and cross-platform compatibility/consistency. And in some situations Clang will compile faster and have more performant binaries than GCC, though that's application/load dependent.

Cheers,
Mike

[mroche]

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

Nice, some projects in that list I haven’t heard of. And I hear you on the time, it’s always difficult to allocate. My plan was for at least the following:

• muslc
• llvm (llvm-binutils), clang
• libc++, libedit
• zsh

Still looking into options for coreutils and an init system (might just go with systemd [I know], but it’s what I know). Busybox might be a good choice. I’d still like to use RPM/[dnf/zypper] for packages, but I’m open to other options.

Cheers,
Mike

Congratulations to Clang developers, I guess. Their pipe dream has become a reality. Now they can sit in a corner and whine whenever someone breaks their builds. I'll stick with the GNU compiler, thank you very much.

If any distro decides to compile everything with Clang because GPLv3 is supposedly bad, I'll laugh at them, and consider writing mails to companies that can tivotize their work.

[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

[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.

[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

[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...2783c6f9520a0e

[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.

[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.