Announcement

Collapse
No announcement yet.

Building Linux With LLVM/Clang Excites The Embedded World

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

  • Building Linux With LLVM/Clang Excites The Embedded World

    Phoronix: Building Linux With LLVM/Clang Excites The Embedded World

    Building the Linux kernel with LLVM/Clang rather than GCC continues to be a big focus within the embedded Linux community...

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

  • #2
    Won't change the Linux FOSS nuts who will continue to bash Apple and not realize that without Apple Clang doesn't exist and much of LLVM is still in the research phase.

    Comment


    • #3
      Originally posted by Marc Driftmeyer View Post
      Won't change the Linux FOSS nuts who will continue to bash Apple and not realize that without Apple Clang doesn't exist and much of LLVM is still in the research phase.
      What does this even have to do with Apple?
      This is just about compiling Linux with another open source compiler.

      Comment


      • #4
        Originally posted by Ancurio View Post
        What does this even have to do with Apple?
        This is just about compiling Linux with another open source compiler.
        A lot of people hate and despise Clang simply because some engineers at Apple prototyped the original implementation (which Apple released as Open Source, though they were hardly required to do so; what was that about nothing being contributed back under permissive licenses?), Apple engineers continue to do much (not all) work on it, and Apple hired some of the lead LLVM folks, or because it has a reasonable-for-everyone license instead of the GPLv3. Never mind that Mesa uses it, Google uses it internally, and so on.

        Comment


        • #5
          Originally posted by elanthis View Post
          A lot of people hate and despise Clang simply because some engineers at Apple prototyped the original implementation (which Apple released as Open Source, though they were hardly required to do so; what was that about nothing being contributed back under permissive licenses?), Apple engineers continue to do much (not all) work on it, and Apple hired some of the lead LLVM folks, or because it has a reasonable-for-everyone license instead of the GPLv3. Never mind that Mesa uses it, Google uses it internally, and so on.
          Yeah, elanthis which his proprietary bullshit. The sanest license is GPL which is proven, because it's the most popular one (and I don't give a shit if it's reasonable for crapple). Contribution to llvm is also much lower compared to GCC, so you can just stop your bullshit right here. When comes to your examples it's nothing compared to GCC, but as a troll you're aware of this. You were proven lying many times, maggot.

          Comment


          • #6
            Originally posted by Marc Driftmeyer View Post
            Won't change the Linux FOSS nuts who will continue to bash Apple and not realize that without Apple Clang doesn't exist and much of LLVM is still in the research phase.
            There are many reasons to bash crapple. Why don't you go to crapple and say them to stop saying FUD about Linux? Or perhaps, tell some crapple fanboys to stop bashing it. We don't need Clang at all, but if it's here it can be useful. Crapple should be thankful for GCC.

            Comment


            • #7
              Originally posted by Pawlerson View Post
              Yeah, elanthis which his proprietary bullshit. The sanest license is GPL which is proven, because it's the most popular one (and I don't give a shit if it's reasonable for crapple). Contribution to llvm is also much lower compared to GCC, so you can just stop your bullshit right here. When comes to your examples it's nothing compared to GCC, but as a troll you're aware of this. You were proven lying many times, maggot.
              The sanest OS is windows which is proven, because it's the most popular one.
              I hope I don't have to say more...

              And talking of LLVM being the holy CRAP - I hope you are aware of gallium using llvm. Open source graphics drivers (besides intel ones) would not be where they are if there wasn't LLVM.

              // edit:
              and my ignore list grows and grows...

              Comment


              • #8
                Originally posted by schmalzler View Post
                And talking of LLVM being the holy CRAP - I hope you are aware of gallium using llvm. Open source graphics drivers (besides intel ones) would not be where they are if there wasn't LLVM.
                This is quite wrong. While llvmpipe is helpful for testing, it's hardly essential. LLVM is (on Radeons) only used by default on hardware that lacks vertex units, ie old mobile hw. Even there it only sped things up, the vertex pipeline ran there before LLVM.

                The shader compiler for later radeons is disabled by default, and still much inferior to the self-made set.


                So in total, no, the free stack would be at the same level would LLVM never have existed.

                Comment


                • #9
                  Let's guess

                  Let's guess: those qualcomm guys want to be able to close source of toolchain, right? So they could supply binary-only toolchains. I see no other valid points to mess with LLVM for building Linux. And hopefully this initiative will die by horrible death since there is no worse thing in the world than closed source binary-only toolchain you can't rebuild for using in OS of your choice.

                  Comment


                  • #10
                    Originally posted by curaga View Post
                    So in total, no, the free stack would be at the same level would LLVM never have existed.
                    Furthermore, Vadim Girlin has seriously quistioned attempts to use LLVM in opensource Radeon driver. He has made some neat patches which are drastically improve Unigine-based demos. He credited ability to make them to simplicity of existing code generator and expressed serious doubt if he could do same optimization for LLVM which requires much more learning on how things are working in this monster, etc. In fact this dev admitted that dealing with LLVM took a lot of efforts while result was not great. As far as I understood, LLVM isn't really great when it comes to handling VLIWs and it not just sucks at optimizing VLIW code, it sucks so much that in fact it hardly makes things anyhow better at all. It's whole a crapload of work to make it generate just VALID code, not to mention optimizing it. I.e. it looks like it's easier to tweak existing code generator to adequate state than get LLVM here.

                    In fact AMD guys seems to perform very suboptimal strategies in futile attempts to save dev's efforts or so.
                    - AMD guys chosen Gallium (to save some dev efforts?). So their driver is a real CPU hog. Intel chosen their own custom implementation. And their driver is *much* better when it comes to CPU usage.
                    - AMD guys chosen LLVM (to save some dev efforts again?). And got incredibly slow performance while wasting awfully lot of time to get things running, communicate upstream, fix LLVM for their uncommon arch, push changes here, etc. Without *any* user-visible improvements at all!!! In fact, LLVM backend seems to perform very poorly. It's slow and bugged. And so many time wasted on that crap. Intel on other hand created their own driver. And it performs really well. And they don't have wait for LLVM guys to accept stuff upstream, release new version, blah-blah-blah. It's f....ly amazing how AMD devs could waste such a crapload of time without virtually any user-visible results. So I think Vadim haves a point when he questions why the hell all this LLVM idiocy goes on.

                    Maybe AMD guys should really learn some lessons from their competitor? Competitor seems to perform project management much better at this point.
                    Last edited by 0xBADCODE; 03-10-2013, 06:21 AM.

                    Comment

                    Working...
                    X