Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • ms178
    replied
    Originally posted by FireBurn View Post
    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

    Code:
     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:

    Code:
    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:

    Code:
     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.

    Leave a comment:


  • mroche
    replied
    Originally posted by DoMiNeLa10 View Post
    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
    Last edited by mroche; 13 September 2019, 02:32 PM.

    Leave a comment:


  • mroche
    replied
    Originally posted by staalmannen View Post

    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

    Leave a comment:


  • Guest
    Guest replied
    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.

    Leave a comment:


  • staalmannen
    replied
    Originally posted by mroche View Post

    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

    Leave a comment:


  • Grinch
    replied
    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.

    Leave a comment:


  • mroche
    replied
    Originally posted by staalmannen View Post
    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

    Leave a comment:


  • latalante
    replied
    Originally posted by FireBurn View Post
    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

    Leave a comment:


  • andyprough
    replied
    Originally posted by FireBurn View Post

    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.

    Leave a comment:


  • HadrienG
    replied
    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.

    Leave a comment:

Working...
X