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

  • #11
    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
    Last edited by FireBurn; 09-12-2019, 01:17 PM.

    Comment


    • #12
      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.

      Comment


      • #13
        Originally posted by andyprough View Post
        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

        Comment


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

          Comment


          • #15
            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.

            Comment


            • #16
              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.

              Comment


              • #17
                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

                Comment


                • #18
                  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

                  Comment


                  • #19
                    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.

                    Comment


                    • #20
                      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

                      Comment

                      Working...
                      X