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

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

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

    The LLVM 9.0 release is running a few weeks behind schedule but should be out in the days ahead along with other LLVM sub-project releases like Clang 9.0. Here's a look at what's on tap for this half-year update to the LLVM compiler infrastructure...

    http://www.phoronix.com/scan.php?pag...g-9.0-Features

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

    Leave a comment:


  • bridgman
    replied
    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; 09-11-2019, 03:21 AM.

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


  • R41N3R
    replied
    Hope that ACO will allow Mesa to dependent less from LLVM soon!

    Leave a comment:


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

    Leave a comment:


  • discordian
    replied
    Originally posted by GrayShade View Post

    No. It's GNU/Linux because you're using the GNU userspace tools like coreutils and find.
    Then I am using busybox/Linux on several systems already

    Leave a comment:

Working...
X