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

[staalmannen]

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

[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

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

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

[Michael]

Hardly much point running a full stack testsuite. There will minor differences only.
Individual synthetics on the kernel are much more useful at this point.
Stress-ng and friends?

That should point to interesting difference between the compilers which probably will lead to efforts that both have use for.

The full stack was useful for seeing e.g. the Blender instability. Stress-ng and friends were run, the notable results shown in the article, the other micro-benchmarks didn't end up showing much difference and thus weren't included in the article as part of the 97 tests run.

[milkylainen]

"the race was very close." yeah well, it's a kernel, where the CPU should spend the least amount of time in, written in C, being an glorified assembler fronted. What did we expect? ;-)

Actually I anticipated a whole different set of tests.
Running full software suites on the kernel isn't going to reveal much at all.
Individual core component synthetics will yield much more interesting results.

[milkylainen]

Hardly much point running a full stack testsuite. There will minor differences only.
Individual synthetics on the kernel are much more useful at this point.
Stress-ng and friends?

That should point to interesting difference between the compilers which probably will lead to efforts that both have use for.

[Michael]

AMDGPU issue to be fixed for Linux 5.4 - https://twitter.com/nathanchance/sta...81101344804864

[latalante]

It will be a long time before everything works as it should.
At the moment I am receiving this error with CONFIG_INIT_STACK_ALL.

Linux version 5.2.14 (clang version 10.0.0 (https://github.com/llvm/llvm-project/ 8288453f6aac05080b751b680455349e09d49825))
systemd[1]: File /usr/lib/systemd/system/systemd-journald.service:14 configures an IP firewall (IPAddressDeny=any), but the local system does not support BPF/cgroup based firewalling.
systemd[1]: Proceeding WITHOUT firewalling in effect! (This warning is only shown for the first loaded unit using IP firewalling.)

BPF works without hardening.
As for performance, it is comparable to gcc 9.2.0

[ms178]

Interesting results nonetheless even though the differences are not that high. They might be more pronounced with different optimization settings. And I hope they get AMDGPU to compile with Clang, as I need it.