Announcement

Collapse
No announcement yet.

LLVM Still Working On Linux Kernel Support

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

  • LLVM Still Working On Linux Kernel Support

    Phoronix: LLVM Still Working On Linux Kernel Support

    A group of developers remain hard at work on the LLVMLinux project to build the mainline Linux kernel on x86 and ARM with the Clang compiler...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    What is the point behind this? Are we expecting some performance improvement by switching to LLVM?

    Comment


    • #3
      Originally posted by sarmad View Post
      What is the point behind this? Are we expecting some performance improvement by switching to LLVM?
      1) Possibly faster performance
      2) Possibly faster compile times
      3) Having another compiler building the kernel is a constant sanity check to make sure that the code works under things other than GCC
      4) Better integration into IDEs for those that like to use IDEs.
      5) LLVM has great static analysis tools for code debugging
      6) LLVM has a utility that can run and check code against common coding mistakes / errors and report back against them
      7) There's an interesting idea posed to where you could build the kernel and stop at LLVM IR, then during install JIT compile the kernel against the user's hardware, giving them an automatically optimized version of the kernel.
      7a) I'm not positive that it would work, this is just an idea I had sprung off from the idea above-- compile the kernel to LLVM IR then check at compile time whether the user had a 32bit or 64bit (or eventually a 128bit) CPU and go from there, therefore we wouldnt have to create separate images
      8) Another idea was that you could compile modules to LLVM IR that were optimized for battery life vs performance, then JIT compile them on AC events and reload the modules. So if you unplugged the AC adapter your laptop would really quickly recompile driver modules to be power-efficient optimized instead of performance optimized, then do it again once you plugged back in.
      All opinions are my own not those of my employer if you know who they are.

      Comment


      • #4
        Originally posted by Ericg View Post
        1) Possibly faster performance
        2) Possibly faster compile times
        3) Having another compiler building the kernel is a constant sanity check to make sure that the code works under things other than GCC
        4) Better integration into IDEs for those that like to use IDEs.
        5) LLVM has great static analysis tools for code debugging
        6) LLVM has a utility that can run and check code against common coding mistakes / errors and report back against them
        7) There's an interesting idea posed to where you could build the kernel and stop at LLVM IR, then during install JIT compile the kernel against the user's hardware, giving them an automatically optimized version of the kernel.
        7a) I'm not positive that it would work, this is just an idea I had sprung off from the idea above-- compile the kernel to LLVM IR then check at compile time whether the user had a 32bit or 64bit (or eventually a 128bit) CPU and go from there, therefore we wouldnt have to create separate images
        8) Another idea was that you could compile modules to LLVM IR that were optimized for battery life vs performance, then JIT compile them on AC events and reload the modules. So if you unplugged the AC adapter your laptop would really quickly recompile driver modules to be power-efficient optimized instead of performance optimized, then do it again once you plugged back in.
        That was theory, 8 years old claims. It LLVM so bad that can not do single goal all that years, except single selected corner cases? Coverity as plenty of other static tools have much better NOT compiling features and quality.

        Another idea, stop Apple's proprietary LLVM PR about ideas, show real working everyday tested examples, thanks.

        Comment


        • #5
          Originally posted by storm_st View Post
          That was theory, 8 years old claims. It LLVM so bad that can not do single goal all that years, except single selected corner cases? Coverity as plenty of other static tools have much better NOT compiling features and quality.

          Another idea, stop Apple's proprietary LLVM PR about ideas, show real working everyday tested examples, thanks.
          I had wondered where the GCC fanboys had run off to, here I thought you kiddies would be in school right now... Oh well, another one to add to the ignore list
          All opinions are my own not those of my employer if you know who they are.

          Comment


          • #6
            Originally posted by Ericg View Post
            I had wondered where the GCC fanboys had run off to, here I thought you kiddies would be in school right now... Oh well, another one to add to the ignore list
            Sure, everybody who say bad about sacred thin polished glamour Apple are poor fanboys. LLVM worse than GCC at main goal, compiling code from text to machine instruction. Why you lie about superiority of that proprietary shit as everybody can run that clang and see?

            Comment


            • #7
              Great question!

              sarmad

              What is the point behind this? Are we expecting some performance improvement by switching to LLVM?

              If you are a user of free software (in this case GCC), then there is no benefit. In fact, there is a great detriment to relying on an application that can be pulled out from underneath your feet. The only possible benefit to a user is the possibility of LLVM being slightly faster then GCC sometime in the future. And do not believe the "but LLVMs error messages are better" because they are likely not - http://gcc.gnu.org/wiki/ClangDiagnosticsComparison

              There are however lots of businesses with a vested interest in making their applications work with proprietory LLVM plugins only, so they have complete control over who can build their application.

              In other words, the benefit to using LLVMs MIT licence only arises if you are a business.

              Comment


              • #8
                Originally posted by Ericg View Post
                8) Another idea was that you could compile modules to LLVM IR that were optimized for battery life vs performance, then JIT compile them on AC events and reload the modules. So if you unplugged the AC adapter your laptop would really quickly recompile driver modules to be power-efficient optimized instead of performance optimized, then do it again once you plugged back in.
                This is certainly an interesting concept although would probably be better if it compiled a performance and battery life version on first run and cached those, and used them as opposed to JITing on AC Event that way you burn through less energy.

                Comment


                • #9
                  Originally posted by Ericg View Post
                  I had wondered where the GCC fanboys had run off to, here I thought you kiddies would be in school right now... Oh well, another one to add to the ignore list
                  If their code in GCC is as incoherent as their second language skills in English, it's not a surprise how come LLVM is surpassing them.

                  Comment


                  • #10
                    GCC vs LLVM

                    As someone who actually uses both of these compilers at work, I can tell you there are a few reasons to use clang (LLVM).
                    1. Far better error and warning messages. The difference is quite stark, clang is miles ahead.
                    2. Fast compile times. Note, this is how long it takes to compile not how fast the resulting binaries are. This is very useful for when you are debugging and you need to recompile mutlitple times during the day.
                    3. Reduced memory usage for compiling.
                    4. Having two libre systems to check against helps ensure that the code meets the standard, not just the compiler.


                    For final compilation my project uses gcc because it targets the embedded architecture that we are using. But while while doing the test->check->test cycle clang is much nicer.

                    Comment

                    Working...
                    X