Announcement

Collapse
No announcement yet.

The New Features Of LLVM 9.0 & Clang 9.0 - Includes Building The Linux x86_64 Kernel

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

  • #11
    Originally posted by xxmitsu View Post
    I am curious about the differences of a kernel built using llvm. Is it about the compile speed ? or is it generating a better code?
    Some people want to be consistent and compile everything with same compiler. GCC has until now been the only compiler you can use to build entire GNU/Linux.

    Comment


    • #12
      Hope that ACO will allow Mesa to dependent less from LLVM soon!

      Comment


      • #13
        Now all we need is to get musl-libc sufficiently ABI compatible with glibc so things like GOG.com games can run on it and I'll finally be able to give those "it's GNU/Linux" snobs a proper middle finger.

        Comment


        • #14
          Originally posted by ssokolow View Post
          Now all we need is to get musl-libc sufficiently ABI compatible with glibc so things like GOG.com games can run on it and I'll finally be able to give those "it's GNU/Linux" snobs a proper middle finger.
          Goals.

          Comment


          • #15
            Originally posted by xxmitsu View Post
            I am curious about the differences of a kernel built using llvm. Is it about the compile speed ? or is it generating a better code?
            I think it's more about choice (I don't think there would be any benefit to doing so at this time and there are bound to be bugs still pending). If the Linux kernel can build with Clang, then you might see distros that might ship LLVM only (and not gcc by default) some day.

            Comment


            • #16
              I’m pretty sure OpenMandriva will be the first fully llvm/clang distro.

              Comment


              • #17
                Originally posted by Madgemade
                If AMD mainlined all of their work on ROCm it would be pretty great. However that is never going to happen. Regressions are the norm in ROCm, Hawaii GPUs have been broken since 2018 and nothing is done. The kernel maintainers would be right to steer clear of the flurry of bug reports that would come with a mainlined ROCm.

                Until it gets patched up to a decent level it's (rightly) going to stay out of tree. I believe there are also some problems with proprietary blobs within ROCm, although that might have just been some utilities.
                Not sure what you mean by this. The only kernel code not upstreamed is a couple of compute-specific patches that are not acceptable upstream. One is a set of memory manager tweaks allowing a single application to use most of the system memory on an unpatched distro rather than being limited to <50%, and the other is support for RDMA adapters using the NVidia/Mellanox pinned memory API.

                LLVM changes also go upstream but the process is slower since LLVM release cycles are longer and changes are not as cleanly isolated to specific HW as they are for kernel drivers.

                For the rest of the ROCm stack there is no "upstream" to be out of other than our own Github repos, since those components are specific to ROCm.

                What proprietary blobs are you talking about ? The old HSA stack had a proprietary blob for the HSAIL finalizer, since it was based on our internal graphics shader compiler, but AFAIK all of the ROCm stack is open source.

                The main reason for having separate repos for kernel and compiler is that it allows us to run on a monthly release cycle rather than having to wait for the 3- and 6-month release cycles of kernel and LLVM.
                Last edited by bridgman; 11 September 2019, 03:21 AM.
                Test signature

                Comment


                • #18
                  Whether znver2 is to be supported in LLVM instead of clang? Seems architectures supporting is LLVM task, or not?

                  Comment

                  Working...
                  X