| |||||||||||||
The Design of LLVM (Dr. Dobb's)The Design of LLVM (Dr. Dobb's)Posted May 30, 2012 17:01 UTC (Wed) by dashesy (subscriber, #74652)In reply to: The Design of LLVM (Dr. Dobb's) by djc Parent article: The Design of LLVM (Dr. Dobb's) Thanks for the pointer. LLVM was very well written. I just started reading a few other chapters, and it is a very interesting read!
(Log in to post comments)
The Design of LLVM (Dr. Dobb's) Posted May 30, 2012 18:16 UTC (Wed) by wahern (subscriber, #37304) [Link]
There's usually a gap between how an author sees his project in his mind's eye, and the project in reality. Lattner is no different. He clearly has a slightly exaggerated sense of LLVM's virtues and GCC's vices, and a diminished sense of LLVM's vices and GCC's virtues. I'm not trying to equivocate LLVM and GCC, but if you read the substance of his descriptions closely, there's less of a gap than his adjectives and qualifiers suggest.
So rather than judge the code by reading an article, judge the code by reading the code.
The Design of LLVM (Dr. Dobb's) Posted May 30, 2012 21:52 UTC (Wed) by daglwn (subscriber, #65432) [Link]
This is exactly right. LLVM's use of a fully descriptive IR, ability to write that IR out to files and process it via piped commands is nothing new. This has been done in the research environment for a couple of decades, at least.
LLVM is well-designed, no doubt, and its modular nature helps tremendously when putting a project together. But it is not the first modular compiler nor the first to put compiler components into libraries.
LLVM is certainly not perfect. I would change quite a bit of the software engineering, actually. But overall, it is the most useful open source compiler tool set out there.
The Design of LLVM (Dr. Dobb's) Posted May 31, 2012 4:00 UTC (Thu) by rsidd (subscriber, #2582) [Link] I would change quite a bit of the software engineering, actually. So might Lattner if he were starting from scratch. But clearly they got a lot right, and now the benefits of fundamental changes are probably not worth the pain. There is a difference between a research compiler and a compiler that is used by several production platforms and dozens of serious projects. LLVM may not be the first modular compiler but it is the first to have a real-world impact.
The Design of LLVM (Dr. Dobb's) Posted May 31, 2012 14:31 UTC (Thu) by daglwn (subscriber, #65432) [Link]
> So might Lattner if he were starting from scratch.
Some, yes, but not much as he has been asked about it before.
The leadership has no problem completely replacing or removing APIs so stability is not a problem. Users simply have to bear the pain. Pain does not seem to be a concern of the project. And that's fine. I completely understand why they choose to operate that way. I wouldn't want to be locked into a set of APIs either.
Certainly they did get a lot right. As for real-world impact, I suspect that something like MSVC is pretty modular and that Microsoft uses that to its advantage in Visual Studio. Of course we can't prove that.
The Design of LLVM (Dr. Dobb's) Posted May 31, 2012 8:09 UTC (Thu) by mlopezibanez (guest, #66088) [Link]
So what are LLVM's vices?
The criticism of GCC (and GDB, GAS and the whole GNU toolchain) in that article seems entirely fair, and Chris didn't even comment on the front ends or the development aspects.
The Design of LLVM (Dr. Dobb's) Posted May 31, 2012 14:45 UTC (Thu) by daglwn (subscriber, #65432) [Link]
> So what are LLVM's vices?
I hesitate to respond because I don't want to seem like I'm dumping on LLVM. I use it every single day at work and it's a lovely thing. The community is great and the advancement is quick.
That said, here are a few things I would improve:
- Getting code merged upstream is pert near impossible. It takes forever to get code reviewed, patches are dropped all the time, etc. Many people have noted this but there doesn't seem to be a willingness to change processes to address it.
- Cathedral model of development. This is a matter of taste but I think people generally prefer the bazaar model.
- The class interfaces are WAY too extensive. Designers tend to throw everything and the kitchen sink into classes. Most of the interfaces should be freestanding functions. That would simplify the API.
- There are still scaling issues. This has been improved over the years but LLVM can still fall to its knees on very large codes.
- Refusal to use common libraries. There's a lot of NIH and reinventing of the wheel. LLVM has entire headers devoted to reproducing stuff available in Boost and the standard library. I'm not sure why that's so other than an overinflated fear of templates. There's a whole regular expression engine in there.
- Bare pointers. With today's C++ this just shouldn't happen.
The Design of LLVM (Dr. Dobb's) Posted May 31, 2012 17:48 UTC (Thu) by hharrison (subscriber, #39162) [Link]
>- Getting code merged upstream is pert near impossible. It takes forever to get code reviewed, patches are dropped all the time, etc. Many people have noted this but there doesn't seem to be a willingness to change processes to address it.
> >- Cathedral model of development. This is a matter of taste but I think people generally prefer the bazaar model.
Refusal to use anything but SVN...not sure if that's cause or effect in this case.
|
|||||||||||||