Announcement

Collapse
No announcement yet.

Building Gentoo Linux With LLVM/Clang

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

  • Building Gentoo Linux With LLVM/Clang

    Phoronix: Building Gentoo Linux With LLVM/Clang

    Following this weekend's news about Link-Time Optimization support for the Linux kernel, in the discussion that spawned, building the Linux kernel with the LLVM/Clang compiler was once again brought up...

    http://www.phoronix.com/vr.php?view=MTE2NDE

  • #2
    any advantage?

    Gerntoo user here. Does it provide any advantage to use LLVM/Clang yet?
    Anybody?

    Comment


    • #3
      Benchmarks

      Cool!
      Linux on x86-64 now apparently compiles with LLVM according to that website.

      I look forward to seeing benchmarks of the Linux kernel compiled with GCC and LLVM.
      Even if I am convinced that GCC will perform much faster.

      It is still nice, because it allegedly improves code quality.

      Are much patches needed to compile the Linux kernel under LLVM/Clang?

      Comment


      • #4
        Originally posted by dimko View Post
        Gerntoo user here. Does it provide any advantage to use LLVM/Clang yet?
        Anybody?
        Yes and no. The resulting binaries are comparably fast; sometimes faster and sometimes slower than gcc. As an end user you're unlikely to notice the difference except in some rare edge cases.

        What is different is that clang compiles faster than gcc - if you build from source with portage it should save you a fair bit of time. It also produces much better error messages and warnings, which is rather nice if you're a developer. Finally, it's always smart to make sure you've got alternatives - if any political/personal/legal/technical issues show up for either compiler, there's a fallback (and the work done to make the code compile on both is probably beneficial if a third compiler shows up.)

        Comment


        • #5
          Third compiler

          I hope a third (and forth) compiler shows up.

          * Intel C Compiler
          * Open64
          * TCC
          * PCC

          Comment


          • #6
            With all the problems Linux has both on desktop and server side, someone should now please explain to me why is migrating to clang such an important and high priority task.

            This is all a political bullshit story, someone doesn't like the GNU GPL license anymore.

            Comment


            • #7
              Who is migrating?

              Comment


              • #8
                Originally posted by bulletxt View Post
                With all the problems Linux has both on desktop and server side, someone should now please explain to me why is migrating to clang such an important and high priority task.

                This is all a political bullshit story, someone doesn't like the GNU GPL license anymore.
                It goes something like this:

                1: Compile Linux with LLVM/CLANG/ICC/etc.
                2: Look for things that are faster than what GCC produces.
                3: Figure out 'why' they are faster.
                4: Implement what you have discovered (in step 3) in GCC.

                The end result is a faster linux binary produced by GCC.

                F

                Comment


                • #9
                  Originally posted by bulletxt View Post
                  With all the problems Linux has both on desktop and server side, someone should now please explain to me why is migrating to clang such an important and high priority task.

                  This is all a political bullshit story, someone doesn't like the GNU GPL license anymore.
                  If in the future, will be able to compile to VM like LLVM does, we will not need to target only one processor with one binary. For example Android must use LLVM for Java and C++ and stop be a Java toy under patent attack. Another example is that if closed source programs and games, are compiled with LLVM, then will be compatible with all processors. Some one has to develop the way.

                  Comment


                  • #10
                    Originally posted by dnebdal View Post
                    Yes and no. The resulting binaries are comparably fast; sometimes faster and sometimes slower than gcc. As an end user you're unlikely to notice the difference except in some rare edge cases.
                    Binaries are usually much slower with llvm. As an end user why would anyone bother to use llvm and make his life harder?

                    Comment


                    • #11
                      Originally posted by artivision View Post
                      If in the future, will be able to compile to VM like LLVM does, we will not need to target only one processor with one binary. For example Android must use LLVM for Java and C++ and stop be a Java toy under patent attack. Another example is that if closed source programs and games, are compiled with LLVM, then will be compatible with all processors. Some one has to develop the way.
                      LLVM does not compile to a VM or interpreter. It is a compiler that compiles to machine code just like GCC.
                      People do not target one processor with one binary, with GCC you can download a binary that works on every processor. I think you mean architecture. Such as x86 and ARM. There are many x86 processors, some from intel, some from AMD, but one x86 binary works on all chips (unless you use processor specific CFLAGS but nobody does that in distributed binaries).

                      As for patents against android, that is not related to Java. There was a law suit from Oracle against Google about Java, but Google won.

                      Another example is that if closed source programs and games, are compiled with LLVM, then will be compatible with all processors. Some one has to develop the way.
                      Again every compiler does this already. When you download software from the internet, it works on your machine right? It not compiled for you specific processor, but just x86.

                      As for one binary for every architecture, (like x86, ARM, PPC, MIPS), that can be done with GCC. GCC supports ARM and x86, so a port is just a recompile right? Wrong, many programs use bits of assembly for very intensive parts (many games and graphics engines). Also it isn't always as easy a just a recompile.

                      What you are describing is an interpreted language like python. The interpreter has been ported to many architectures and bytecode will run on the interpeter the same way as if it was on x86 or ARM. Compiling C++ like this is stupid as it defeats the whole purpose. Interpreters and VMs kill performance.
                      Actually what you describe just produces bytecode for a VM. There are no binaries.

                      Comment


                      • #12
                        Originally posted by uid313 View Post
                        Cool!
                        Linux on x86-64 now apparently compiles with LLVM according to that website.

                        <...snip...>

                        Are much patches needed to compile the Linux kernel under LLVM/Clang?
                        Why even ask this, when you have already visited the website, which provides details, including where to grab the tools/patches required? if you are really that curious, wouldn't it makes sense to have a look? ; git clone http://git.linuxfoundation.org/llvm-setup.git

                        this git branch takes 2 seconds to download, and shows you what patches are required (not only for the kernel, but also Clang and LLVM). it also provides a README that explains how to use llvm-setup for building an Clang/LLVM-compiled kernel....as for patches required;

                        51 patches for x86_64 (itself)
                        7 patches for LLVM
                        2 patches for Clang

                        plus other scripts / tools such as wrappers to allow clang/LLVM to substitute for GCC (not unlike the initial patches from LinuxDNA for Intel's C compiler, ICC - from a few years ago).... Now, i would imagine the second you tried to compile a more custom kernel, ie: patched for other things ...or started enabling features that have been disabled in their 'test' configs ~ you would probably run into a lot of other problems.

                        Comment


                        • #13
                          Fixing hardcoded CFLAGS is something Gentoo puts effort into anyway since it can cause other problems.

                          Comment


                          • #14
                            Originally posted by n3wu53r View Post
                            LLVM does not compile to a VM or interpreter. It is a compiler that compiles to machine code just like GCC.
                            People do not target one processor with one binary, with GCC you can download a binary that works on every processor. I think you mean architecture. Such as x86 and ARM. There are many x86 processors, some from intel, some from AMD, but one x86 binary works on all chips (unless you use processor specific CFLAGS but nobody does that in distributed binaries).

                            As for patents against android, that is not related to Java. There was a law suit from Oracle against Google about Java, but Google won.


                            Again every compiler does this already. When you download software from the internet, it works on your machine right? It not compiled for you specific processor, but just x86.

                            As for one binary for every architecture, (like x86, ARM, PPC, MIPS), that can be done with GCC. GCC supports ARM and x86, so a port is just a recompile right? Wrong, many programs use bits of assembly for very intensive parts (many games and graphics engines). Also it isn't always as easy a just a recompile.

                            What you are describing is an interpreted language like python. The interpreter has been ported to many architectures and bytecode will run on the interpeter the same way as if it was on x86 or ARM. Compiling C++ like this is stupid as it defeats the whole purpose. Interpreters and VMs kill performance.
                            Actually what you describe just produces bytecode for a VM. There are no binaries.
                            exactly right, im still looping "what the F" in my head when i readed the OP message but i think you explained this well enough

                            Comment


                            • #15
                              Originally posted by n3wu53r View Post
                              As for one binary for every architecture, (like x86, ARM, PPC, MIPS), that can be done with GCC. GCC supports ARM and x86, so a port is just a recompile right? Wrong, many programs use bits of assembly for very intensive parts (many games and graphics engines). Also it isn't always as easy a just a recompile.
                              I have found that most software is written entirely in C/CPP/etc, and platform specific assembly is written during the optimization phase. This does not typically prevent a recompilation for a different target arch, but the resulting binary is usually much, much slower, as arch specific optimizations are no longer utilized. I believe ffmpeg to be a good example of this.

                              The spirit of your post is entirely correct though. It is often not a simple matter of specifying a new arch.


                              F

                              Comment

                              Working...
                              X