During the last LLVM developers'meeting, several Apple engineers made some presentations about their work on different aspects of LLVM. One of them explains the work on "clang", a new C front-end, which will also support C++ and Objective C. Chris Lattner also discussed the use of LLVM in Leopard Open GL. Slides and videos available. Additionally, LLVM 2.0 was released recently.
To read all comments associated with this story, please click here.
Member since:2007-01-30
Member since:2007-02-22
The only platform I have that Quicktime has been ported to is Windows XP, and my experience with Windows-based Quicktime is that it's very slow, a memory-hog, too buggy, full of advertisements for other Apple products (I hear it's got much worse after iTunes and the iProduct revolution), and I don't get the same quality as with other file formats the same size. One of the last crashes I had with Windows was the boot after I installed Quicktime; I uninstalled it in Safe Mode, and my computer booted again.
I'm told it's none of these things on a Mac. Too bad my only Mac is a SE/30...
Member since:2005-11-12
Member since:2006-01-17
Think of a compiler as a pipeline. You stick human-readable source code in one end, and machine code comes out the other.
Conventionally, this pipeline is divided up into a number of stages, which are often grouped into three parts, the "front end", "back end", and "middle end" (it's a stupid term, I know). The front end is responsible for lexing and parsing the program text into an abstract syntax tree, and then converting that syntax tree into some lower-level representation for analysis. The back end converts that lower-level representation into machine code.
In between, the code is in a language-agnostic and machine-agnostic format. In other words, the code can be optimized with absolutely no regard to the source language or the target architecture. As a result, any optimization on this middle format can instantly be taken advantage of by any language front-end or any machine back-end.
There are a number of useful formats that can be used for this middle stage, but the best we have now is called SSA, for "static single assignment". In SSA, each variable name is used exactly once. Whenever a variable is assigned multiple times, it is subscripted, and any reference to that version of the variable carries the same subscript. This has the effect of making it explicit exactly which expressions depend on which, and so optimizing code in this form is relatively straightforward.
The idea behind LLVM was "lifetime program optimization". Conventional compilers (including GCC) optimize program modules, but go no further. LLVM is made to extend this not only to link-time (which some compilers do already), but to install-time, run-time, and even idle-time. After all, every computer has a slightly different configuration, and why shouldn't programs be able to optimize themselves with this information?
Thus, LLVM is a combination of two things. First, it's an SSA language, which is clean, type-safe, and completely specified, in contrast to GCC's intermediate representations (there are three that I know of). And second, it's an optimizing framework and code generator. All LLVM-based optimizers read in and write out LLVM code; the code generation (which mostly consists of translating instruction names and allocating registers) happens at the very end.
So, in effect, LLVM is a compiler "middle" and back-end. It's the second half of that compiler pipeline; you feed it in intermediate code, and it gives you heavily-optimized machine code.
Of course, if you want to compile C programs, you need to convert your C code into LLVM. That's the job of a front-end. So the LLVM guys took the GCC front-end and rewrote it to generate LLVM code instead of GIMPLE. The combination of that front-end and the LLVM back-end makes a complete compiler.
Unfortunately, while GCC is excellent software, it's showing signs of age. For one, the code base is just a huge mess, which isn't really a surprise when you consider that it's 20 years old. For another, it was written before compiler programmers realized how awesome SSA is; GCC has only used SSA (in the form of GIMPLE) since v4 came out in 2005. And finally, the C/C++ parser converts code into the language-agnostic GENERIC form, which is kind of useless for an IDE that wants to refactor code.
LLVM took care of all of the backend problems, and the goal of clang is to take care of the front-end problems. clang's architecture is very straightforward; first, lex and parse C/C++ code into an abstract syntax tree, which other software can access; second, convert that syntax tree into LLVM code without bothering with any other intermediate representations. This has a number of useful effects; for example, because there are so many fewer intermediate stages, clang/LLVM uses far less memory than gcc (and thus can more effectively apply whole-program optimization to larger programs). But most importantly, because it generates a language-specific abstract syntax tree, you can use the front-end anywhere that you need to analyze C/C++ code, and you can be guaranteed that you'll be analyzing code in exactly the same way as the compiler.
Member since:2007-02-22
Member since:2005-07-06
Per the link on the linked page, the videos are also available on YouTube.
http://www.youtube.com/view_play_list?p=AA11ACE45D6B0E4C
Member since:
2007-02-22
Seriously; I can't understand it. I tried to look it up, and all the information I could find out about it was very obfuscated, without giving a clear idea of what it did or where it came from.
(It doesn't help that the video presentations in the site linked were only provided in Quicktime format, either...)
The closest thing to an inkling I got was that it's a sort of cross-platform compiler, something that would compete with GCC, except that it incorporates GCC in it. Is this correct, or was that site far off?