Results 1 to 10 of 40

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

Threaded View

  1. #12
    Join Date
    Jun 2012
    Posts
    304

    Default

    Quote Originally Posted by stiiixy View Post
    I think you'r emissing a critical piece of the logic of your own argument. If AMD DIDN'T try out LVM, they would have never know, and now the whole world knows a little bit more that, at least an older version, LLVM isn't the be all and end all of compilation and GCC pretty much is for the time being.
    From what I understood, it has been clear enough from the very beginning that LLVM isn't great when it comes to generating VLIW code. Because it's more or less generic while VLIWs are awfully custom things with very specific requirements on commands stream generation. Something that LLVM never took into account on design and implementation phases. The result is quite predictable: guys wasted a lot of efforts to just get LLVM anyhow working at all and while LLVM isn't great at code optimization on it's own, on VLIW it seems to be completely awful. Old custom code generator STILL performs better. While nobody wasted so many time working on it.

    As for me it looks like decisions/design phase fault: guys used LLVM due to buzz around, failing to understand it's a troublesome way. It's not even LLVM fault on it's own. It's VLIW and it requires custom approach. LLVM knows nothing about VLIW existence and does not really helps to deal with things like this. Instead it makes things more complicated (as it's generic solution intended to handle dozen of unneeded scenarios), raises bar for those who wants to enter development, requires upstream syncs, etc, etc and ... and at the end of day it FAILS TO PROVIDE REASONABLE PERFORMANCE (and why anybody needs 3D driver with crappy performance, huh?). You see, Vadim has managed to seriously improve FPS on custom code generator because it's simple. If there was LLVM on it's place it would be unlikely as it reqires far more time to get same results.

    And the worst of all: it could be evaluated qickly. It's fairly predictable. Sure, AMD currently haves awful management issues, but this partucular stubborness is just hard to explain. They literally WASTED YEARS without anyhow usable outcome which can provide user-visible values. What about efforts to results ratio? And why some quite inactive dev could come, quickly improve OLD code and beat all this LLVM idiocy to the hell in terns of performance? Without wasting years of hard work, spending months on waiting upstream, etc. It's just a drastic demonstration of what happens when someone decides to "improve these damn user-visible results" rather than "use LLVM" (or whatever else crap you have).

    Let's just make some quote:
    I spent some time last year studying the LLVM infrastructure and R600
    LLVM backend and trying to improve it, but after all I came to the
    conclusion that for me it might be easier to implement all that I wanted
    in the custom backend.
    Or, for those interested, you can read the whole thread on http://lists.freedesktop.org/archive...ry/034547.html and all reply messages. That's a really amazing history on how LLVM fetishism could make development suboptimal and fruitless. I think it will be yet another shameful page of AMD engineering. When they had chance and missed it due to incredibly silly reasons.

    P.S. ah, they mumble LLVM needed for opencl. But looks like if they fail to understand that nobody needs SLOW opencl implementation. It's just pointless. Either you can roll out OPTIMIZED implementation or you would waste potential of hardware and lose the market.
    Last edited by 0xBADCODE; 03-10-2013 at 05:46 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •