My name is Chris Lattner. I am the LLVM Architect here at Apple. We're doing a lot of exciting things at LLVM, and so, I hope, that's what you're interested in because that's what we're going to learn about. So, let's talk about compilers at Apple. So, for a long time, Apple has been using GCC. And GCC has been an important part of the platform and it has done a lot for us. But increasingly, GCC has become problematic and it's struggling to do things we needed to do.

Modern design is lacking and a lot of problems are happening in that space. And fortunately, LLVM is a great solution for that problem. Apple has been investing heavily in it driving it forward, and today, we're going to talk about that. One aspect of this is we don't get to talk about a lot of the other great tools in the tool chain. So, there's a lot of other good things that are in, for example, the Xcode 4 release.

One thing I want to point out is that the linker in Xcode 4 is twice as fast as the linker in Xcode 3, and we won't get to see that. But if you're building big apps, that's actually a pretty good win.

So, I'm going to talk a lot about LLVM.

So, what is this LLVM thing, if you don't know already? Well, LLVM is a technology project. We're building compilers and low-level tools. And the number one thing we care about is building great tools. Well, great in how-- great in what way, right. There's a lot of interesting technology in compilers. And compilers are typically built as large monolithic pieces of software, right.

When you build an operating system, you build a large application, there's this new-found theory that instead of building a large monolithic application, breaking it down into multiple libraries that can be reused is a good thing. And it turns out that it applies not just to applications, but also to compilers and tools. And so, one of the major differences of LLVM from pretty much any other compiler out there is that it's very modular, right. Well, as an end user, that doesn't really benefit you, right.

I mean you just want something that compiles code. But modularity is actually a critical component of bringing this technology forward into a number of different areas. And so, the integration with Xcode that you saw on Monday, for example, is one key example of that. And so, we'll be talking about this more throughout the talk.

One common thing that LLVM and GCC do have is that they're both open source. And so, if you're interested in the LLVM Project, you want to learn more, you want to see things happening in real time in the community, I strongly encourage you go to the llvm.org website.

And of course, we welcome patches. So, if you don't like something, you can fix it. So, today, we're going to talk about the compiler landscape, talk about where things are and where we're going. And so, the first part of this landscape is the actual compilers themselves. Today, we have three compilers that are interesting: GCC 4.2, LLVM-GCC, and the LLVM Compiler.

Well, what are these? They are basically three different compilers with increasing levels of LLVM-ness in them. And so, if you take a compiler, you can break it into two pieces at the highest level. The first part of it is the Parser; the thing that read your source code, the thing that analyzes and tries to understand is it correct. If it's incorrect, it tells you-- gives you an error message, for example.

If it is correct, it sends it back to the optimizer and code generator, which are responsible for making it run fast and actually generating Intel code or ARM code for the iPhone. So, what these two parts, we-- because LLVM is modular, we're able to mix and match pieces with GCC. And so, GCC, of course, uses the GCC Parser and the GCC Optimizer or the GCC Code Generator. LLVM-GCC is a hybrid compiler.

And so, this compiler actually combines the LLVM Optimizer and Code Generator with the Parser from GCC, and I'll talk about why that's interesting later. The LLVM Compiler uses a Parser named the Clang Parser, the Clang front end. And it's a fully LLVM-base solution. And so, everything in this compiler is LLVM technology, and this gives you a number of advantages over either other, over either other compiler.

Other, either, well. So, beyond the compilers we have today, we have two platforms, of course, we have iOS, an iPhone OS, we also have the Mac. And of course, the other final access of our releases today is we have two releases, we have the Xcode 3 Production Release and the Xcode 4 Developer Preview.

So, today, I'm going to start by talking about Xcode 3 and the new features we have in the Production Release. And then later in the talk, Doug Gregor will come up and talk you about Xcode 4 and the great things that are happening there. So, let's talk about Xcode 3.2.3, amazingly long sequence of digits, but it has some cool stuff in it.

So, the biggest compiler change from previous versions of Xcode 3 is that the LLVM Compilers both now support iPhone and iPad. And so, this means that if you're an iPhone developer, suddenly, all these technology that we've talking about for several years is now very relevant to you and brings you a lot of advantages.

Beyond that, there's also been a larger number of enhancements for the Mac in LLVM Compiler, and we'll talk about those. So, before I go into all of that, I want to talk about what the LLVM Code Generator and Optimizer bring to the table, and LLVM-GCC, the hybrid compiler, is a great way to explain what these benefits of the LLVM Optimizer are. So, the LLVM Optimizer has a very modular design.

It brings in a lot of recent compiler research that's happened in say the last 10 to 15 years, and it brings a lot of power to the table. From the high-level perspective, LLVM-GCC, which combines the GCC front end with the LLVM back end, brings you those advantages, which I'll talk about in a second, but it also combines with the GCC front end.

The key thing that the GCC front end brings the table is great support for C++ because in Xcode 3 the LLVM Compiler which is fully LLVM technology doesn't support C++, that's in Xcode 4. And so, if you're interested in doing shipping products, I strongly recommend you use LLVM-GCC.

In fact, LLVM-GCC is the most stable production compiler on our system more so even than GCC 4. And so, if you're using GCC, I strongly urge that you upgrade to LLVM-GCC because we're just not fixing bugs in GCC anymore. And LLVM-GCC is definitely a great compiler; I strongly recommend you use at least it. So, there you go.

We actually strongly considered making this the default compiler in this release, but it turns out that changing default compilers in a dot release is frowned upon. So, we did that on Xcode 4, and you can use it there. The versions of LLVM-GCC in both Xcodes are identical. So, why is the LLVM back end good? Why do you care? Well, as you saw on Monday, the LLVM Compiler brings substantial performance wins in a lot of cases. So, OpenSSL is one great example where it's a very complicated large system. If you aggregate many performance metrics across the board, you'll get overall a 28 percent speedup. This is on iPhone. Another interesting case is JavaScriptCore.

JavaScriptCore is actually a really critical part of WebKit. Well, WebKit is really performance-sensitive code, and it's used for a lot of things on the system. And a very interesting benchmark is the SunSpider Benchmark. SunSpider is one of the industry's standard JavaScript benchmarks, and it beats on JavaScriptCore. JavaScriptCore is the key thing that controls performance.

If you build JavaScriptCore on WebKit with LLVM, it speeds up 11 percent. Well, 11 percent doesn't seem like it's very much necessarily, but this is code that's been highly tuned and highly optimized because people really care about this. And just switching compilers, gaining a double digit percentage speedup is a pretty big deal. This is on iPhone.

Well, more than just that, actually, in iOS 4, several key pieces of the system were built with LLVM including WebKit and JavaScriptCore. So, this is a great technology. There's a lot of advantages of using it. Beyond performance, there's actually another area where the optimizer can help, and that is, well, how fast does code build, right? One of the major things we want or that I want as a developer is I want the compiler to do its thing getting out of my way, right, because it's the thing that's preventing me from running my code.

And so, if you look at a large number of applications, these are some random ones we pulled out, OpenSSL is a C code base. AppKit is the large Objective-C code base. JavaScriptCore and the LLVM code base itself are both large C++ apps. These are the build times to build these applications at O2 or O3 or OS or whatever the default release builds are. And if you look at them, of course, they have different size code basis mixed up with different things especially building with LLVM-GCC.

And suddenly, they build quite a bit faster, right, in, you know, it varies based on the code base, but 20 to 60 percent faster is a big win, right. This is cutting minutes off build times here. Well, the reason for this is that, again, the LLVM Optimizer is built on much more mature and modern technology than the GCC Optimizer. And so, using more modern techniques means you're not burning cycles, running old school bit vector data-flow that you read about in the Dragon Book. So, this is a major win.

Now, you notice up there it says "Release Builds", right. Well, the problem is is that in debug builds, the Optimizer's not doing anything, right, because you have it turned off. Well, unfortunately, LLVM-GCC is using the exact same front end as GCC, and in debug builds, you're not spending anytime in the Optimizer. Well, that means that LLVM has no real-- nothing to really add to the performance picture here.

So, what can we do? Well, it turns out that when you get into this mode, the front end is really the critical thing. For debug builds, the front end matters a lot because the back end is just not doing very much. Well, so, this is the diagram that explains LLVM-GCC. If you take the Clang Parser and put it in place at the GCC front end, we get a fully LLVM Compiler as I said before. But what is this? Well, it's available for iPhone OS.

So, what is the Clang front end? Well, as I said before, it's a Parser, it's a Parser for the C family of languages. This includes C, Objective-C, C++, Objective C++. In Xcode 3, the LLVM Compiler does not or it doesn't have C++ support turned on. And so, if you're interested in C++, Xcode 4 has that and Doug will be talking about that later today. But beyond being a front end, it's actually built with the LLVM style library-based design approach. This means that it's built as a series of reusable libraries that mean that we can do a lot of interesting source-level things.

The compiler front end is the thing that knows about your source code. It knows that macros are being instantiated or the, you know, templates are flying all over the place or exactly where that parenthesis was, right. And so, the front end is really interesting technology both from performance standpoint but also because you can build a lot of interesting source-level tools on it, because this is what knows your source.

So, like the rest of LLVM, the Clang front end is an open source project. And if you're interested, I heartily recommend you go to the clang.llvm.org webpage, which explains what it is and why you should care if you like that. So, why do we care? Well, you break it down and we're just not getting a great experience at the GCC front end, right.

So, as I mentioned before, debug builds, right? The front end is the critical piece that's holding back a really fast debug builds, and we want to fix this because when I'm doing my development, I'm actually sitting there doing debug builds and then running and then debugging and then doing another editing, doing another debug build, and we want this cycle be really fast. And for me, I just, again, want the compiler to get out of the way particularly when there's a bug, and I really want to figure that out.

Beyond that, the front end is also chiefly responsible for the user experience. So, it's not just, you know, the flags you pass in the compiler, which it is also responsible for, but it's OK you get an error message. Is it going to explain to you in a way that makes sense or not? How much effort are we going to put into that? What other features does the front end have? Beyond everything else, we are committed and we have to be compatible with GCC. This means both source-level support, we need to be able to support all those funky GCC extensions so that have, you know, have been grown over the years.

It also means binary-level support. If you build things with the LLVM Compiler, you can drop in individual .O files and mix and match them with GCC. So, everything is extremely compatible, and trying things out is really easy. So, again, coming back to faster debug builds, right? We're building a new front end.

Well, even of last year on the Mac, we've shown the Clang front end provides really fast debug builds. This is a broad variety of Objective-C code on Mac from everything, AddressBook, Automator, Dashcode, Interface Builder, Mail, AppleScriptEditor, Xcode itself, and there's a couple of open source applications over here.

These are big apps. Xcode has millions of lines of code, right. And getting three times faster builds is a huge productivity boost, right? Well, this is because this has been designed from the start to be all about performance, features, modern design, make it reusable, right. And I'm happy to say that this has a certain amount of success in that range. And if you switch from GCC or LLVM-GCC to the LLVM Compiler, I think you'll notice that it's noticeably faster and more memory efficient. So, let's talk about user experience here.

And one of the easiest ways is to talk about errors and warnings. And I don't know about you, but I almost never make a bug in my code, and the compiler almost never tells me that there's something wrong in it. But I've seen other people's codes that have problems. So, the way this works is that the compiler detects an error, right? It says, "Oh, I don't, you know, there's supposed to be a parenthesis here, what's going on?" Right. You know, there's a 4 and then something like an int and that doesn't make sense.

Well, the compiler doesn't know what you did wrong, it just knows that there is something wrong. And so, there's actually a lot of room for the compiler to guess what is the actual problem. And how well the compiler guesses and how much effort we've put in to making the compiler smart, controls a lot of, you know, how good it is at diagnosing what the actual problem is that you're facing. GCC hasn't really been so great at this, it turns out. I don't know exactly why, but I think they're more focused on making it work, and they don't really care so much about the user experience.

And there's lots of examples of this, but this is, perhaps, my favorite one, right. This message tells me almost nothing, right. And it doesn't even matter if you saw the source code, when I get something like this out of GCC, I just say, OK, well, I'll go to that line of code and try to understand from first principles what's going on because this is isn't helping.

If you run the LLVM Compiler, which on the command line is named Clang, you get something like this, right. In this case, it's a very simple thing, a misspelled NSString. And instead of telling me expected gobbledygook because the attribute was really likely to be there and asm too, it actually diagnoses the real problem, right. It actually says, "Hey, you know, I needed a type and NSstring is not a type." Well--

So this is, you know, one small example.

There are a lot of other ones. But if you upgrade to build with Clang, the LLVM Compiler, you will get much better user experience and faster builds, which is great. Well, this actually existed last year on the Mac. And we've been pushing it much farther this year. And so, there are some really great enhancements here.

One of these is spell checking, right. And so, the compiler actually has a huge corpus of information about your program by the time it detects a problem. It turns out that, you know, misspelling NSString especially with all the inner caps is something that really happens in real world code. And so, if you're using the LLVM Compiler now, it actually autodetects many common spellings, and it doesn't-- they're not hardcoded in, it actually works by checking to see how far your spelling was away from all the other possibilities it's seen, it actually autosuggests.

The really great thing about this is this helps with the cascade of error effect, right, because if the compiler gets something wrong, it gets confused then, you know, all the stuff downstream turns into nonsense very quickly. Because it says you probably meant NSString, from that point on, it assumes that is actually an NSString and the compilers your code according to that.

And that means that the error messages that come out later are much improved as well.

So, if you're interested in learning more detail about how this works, we have another session later this afternoon which talks about how it all fits together, how Xcode is using it, how we pull this into the user interface there.

And that again, builds on the library-based design of the compiler. And so, it will do that. Another major feature which applies both to Mac and iPhone is that we've implemented a number of new warning flags that GCC has supported for sometime. And I'm not going to go through all these, but these have been highly requested by developers who have been using the LLVM Compiler since last year. And I'm happy to say that they all work.

And beyond just working, we've actually put a lot of energy into making them really great. And so, the format string warning is a great example where not only does it tell you that there's a problem and it tells you the types and what it expects, it actually points to the format string. It actually tells you this is what you need to change, which in Xcode is really great because you jump right to the point in the editor with the caret. So, there are a lot of great things in here.

So, if you're interested in picking this in Xcode 3, as I mentioned before, the default compiler is still GCC, but you can go into the Build Settings Inspector and get the full list of compilers here. GCC 4.0 is on its way out as Doug will talk about later, so I strongly recommend you don't use that. GCC 4.2 is the system default. LLVM-GCC is a great compiler particularly if you want C++ support.

In Xcode 3, if you pick LLVM Compiler and you have a mixed project which has C, Objective-C, and some C++ code in it, it'll actually build the C and Objective-C parts with the LLVM Compiler, and it'll automatically switch to the LLVM-GCC Compiler for the C++ code. And so, you can actually just pick the bottom one on the mixed project and everything will just work, which is really nice. And you can play around with these. They are all binary compatible, so you can actually go crazy playing with things.

So, as I mentioned before, though, again, this is all about libraries, right? We want to do great things with this, not just build monolithic compiler tools. Well, so what are we doing with them? You know, we've already talked about a lot of different applications that this stuff is used for. The Clang front end, for example, is used both by the LLVM Compiler, right, but it's also used by the Xcode Static Analyzer. We'll talk about that in a second.

It's heavily embedded in Xcode 4. And you saw some of the examples of what that can bring to you as a user through the IDE in Monday's keynote. The LLDB Debugger also uses a lot of LLVM technologies. OpenCL, the graphics programming framework on the Desktop is a great technology, which, you know, is parsing C-like code fragments for your kernels and running them on the GPU. And this is all going through LLVM.

So, there are a lot of great things that building these tools as libraries enables us to make, right. And if this were a monolithic application, we really wouldn't be able to do that. Building something like OpenCL, well, the first step would be to write a C-parser, and that's actually a lot of work. So, I want to talk about one of these which is the Xcode Static Analyzer. And I don't know if you've been using it at all.

Have you tried it out?

So, the Xcode Static Analyzer is this great idea of saying, "Hey, we want to use all this compiler information we have, this dataflow and the deep compiler knowledge about what's going on in the program to automatically see if we can find bugs." And it turns out that this is pretty good. Finding bugs early is key to this, because the earlier you find the bug, the cheaper it is to fix it, right. In worst case, you end up shipping the bug to your customer and then you get unhappy people and you don't want to go there, right.

So, the great thing about the Xcode Static Analyzer is it directly integrates with your workflow as you're building and developing your applications it's really easy to use. So, even as of last year, this has worked on iPhone and Mac. And so if you have either style project, you can use this with no problem. To do this, you just pick the Build and Analyze menu option out of Xcode, and this is Xcode 3, it got renamed in Xcode 4. But you just pick Build and Analyze, it'll scan your code, and then present a list of potential issues.

What do these issues look like? Well, these issues pop up, and they actually show you exactly what's going on in your code. And so, because this is heavily integrated with the Xcode editor, even in Xcode 3, this can show you, and I'm not going to go into details on what this bug is, but it can show you that, you know, this bug occurs on this loop, and the first iteration of this loop interacts with the second iteration of this loop, and this is all the control flow that has to happen. And because it's tightly integrated with the editor, you get a really great experience of it explaining to you what the problem is.

And so, you get the combination of the deep information the compiler knows with the great code integration experience that the Xcode IDE can provide. And it's a really great thing. If you haven't tried it, I strongly recommend it. Well, in this version of Xcode, the second analyzer has actually gotten quite a bit smarter which is really great. So, most of this is all under the covers. The user interface is still the same, but there's many enhancements. For example, the analyzer now understands Blocks.

And so if you're using Blocks in your code, the analyzer will actually go into the bodies of those Blocks and look at how they're used and actually detect bugs there. And it knows much better, much more precise information about arrays and structures. And so, it treats each structure element as a distinct variable, and it can analyze those independently, so you get much many fewer false positives. There are more API checks.

Grand Central Dispatch is a great new API that's available on the phone. It's been available on the Desktop for sometime. And so, those APIs have a few common things that are easier to misuse and the analyzer can help you out with it. Overall, the message, though, is that this release adds a lot of enhancements. It will find more bugs, it has fewer false positives, and overall, just gives a better experience. And so, I think that you should definitely try this out even if you've used the analyzer before because there's a lot of great work that's going on here.

So, this-- the second analyzer was the-- it's also open source, so you can go to the LLVM webpage and read about it and contribute to it. The second analyzer is the first example of tight integration between the LLVM Compiler and the Xcode user interface. And so, we pushed that much further in Xcode 4, and I'd like Doug to come talk about that.

Thank you, Chris. So, in Xcode 4, our next major release of developer tools, Xcode developer tools, it's Developer Preview here at WWDC. But we're taking the idea of the modular reuse of the LLVM Compiler and all of its pieces and pushing it further into Xcode. So, this comes in several forms. It comes with new tools.

So, the Xcode 4 Developer Preview has a new compiler, version 2 of the LLVM Compiler, and it has a new debugger, LLDB that's based on LLVM technologies. Moreover, we're really taking LLVM, in particular the Clang front end, the Parser, and we're moving it into Xcode 4 to give you a much richer experience when you're editing your source code. So, this involves source code indexing, right, which is the program, which is Xcode understanding your source code, producing symbols for the symbol browser and cross referencing information, your project, so you can jump to the definition.

It means better syntax highlighting with more semantic information, better code completion results, because who but the compilers knows exactly what you can do at any point in your program. It has to handle whatever you can write there, so it knows what you can write. And finally, once we've taken the compiler front end and we've moved it into Xcode, we can now do other interesting things like we can give you warnings and errors live as you type them. As soon as you make a mistake, you get an indication that you made a mistake. And we can also do Fix-its, right.

You saw Fix-its on Monday in the initial state of the union talk for developer tools. Fix-its are the compiler saying, "I actually think I know how you want to fix this code and giving you the UI to make that fix quickly and easily without breaking your flow." So, in this talk, we're going to focus on the LLVM Compiler 2. If you're interested in peeking behind the curtain to see how will these other features exists, how is it that you actually use a compiler to build a new debugger, right, how do you integrate a compiler front end into Xcode.

I suggest you come to our LLVM Technologies In Depth Session later this afternoon. I think it'll be really interesting to see how this stuff actually works under the covers. So, with Xcode 4, the Developer Preview, we're moving the compiler landscape forward. So, GCC 4.0 is on its way out, it is gone. If you're still using it, please move to a new compiler preferably one based on LLVM, alright. GCC 4.2 will still be there.

But again, we really want you to move forward to LLVM-GCC or the LLVM Compiler. And we're making LLVM-GCC 4.2 the default compiler in the Xcode 4 Developer Preview, alright. Now the new kid on the block is the LLVM Compiler version 2.0, and we're going to talk about that.

So, last year, we released the first version of the LLVM Compiler 1.0, and the LLVM Compiler supports C and Objective-C. We've improved that compiler for Xcode 3 here. But the big feature with the version 2 of the LLVM Compiler is that we've implemented the entirety of the C++ language.

So, this is great.

I mean we've gone from implementing classes, and name spaces, and the other easy things through multiple inheritance, operator overloading, templates, right, the grand daddy of all C++ features. There's one feature we did not implement. If you're a C++ guru, you know what it is. But I'll tell it to you any way. It's called exported templates. If you're not a C++ guru and you haven't heard of this, that's fine. GCC doesn't support it. Most mainstream compilers don't support it. And in fact, it's so utterly useless that the C++ standards committee took it out of the next standard.

So don't worry about it. For all practical purposes, we've implemented the entirety of the C++ language. And this is wonderful for us as a compiler team because it turns out the entire LLVM Compiler is written in C++. It's about three-quarters of million lines of C++ source code and it can build itself, right. It built itself very well. We live on it on a daily basis, and we love using our own compiler for ourselves. And actually, in the Developer Preview that we shipped to you, the LLVM Compiler built itself right, and we've shifted to this that way.

So, there are other things that actually work, that's not the only C++ program that LLVM can build. We handle, for example, the Boost C++ libraries. So, Boost is a relatively large collection of peer-reviewed open source C++ libraries. Boost is known for really pushing the C++ language to its limits, and pushing compilers well beyond their limits. So, the great news here is that the LLVM Compiler built all of Boost. We passed 100 percent of the regression tests in Boost.

So this speaks well to our language conformance for the C++ standard.

And in fact, GCC doesn't pass a 100 percent of those regression tests neither does Visual Studio right, despite having lots of workarounds in Boost for those compilers. We don't have workarounds, we just do C++ right. So we can handle--

Sorry, I had to.

So, we can build Xcode 4, right.

So, this is actually a mixed application, lots of Objective-C, lots of Objective-C++ in there. We can handle Objective-C++. And FreeBSD is interesting. So, we can build the entire FreeBSD-base system, lots of C and C++ code in there. And the FreeBSD community is actually really excited. Just yesterday, they imported the LLVM Compiler into their own source trees, and it's going to start becoming available on FreeBSD. And they're looking toward the future.

They really want to use the LLVM Compiler as their platform compiler, just like Apple wants to move for the LLVM Compiler. C++ support in the LLVM Compiler actually makes that possible. So, if you want to, right, why would you actually want to use this compiler? Well, if you like Boost, you want to use this compiler. However, it has other benefits, right. It has faster compilation. We saw this with C and Objective-C. Also with C++, we provide faster compile so you can get back to work. We provide much better warnings and errors.

When something goes wrong, we tell you what went wrong and why, we don't just point out something happened here, we don't know what it is. Of course, it provides complete binary compatibility with GCC and with LLVM-GCC. So, you don't have to move your whole world over to the LLVM Compiler to try out the C++ support, you can just build parts of your application or some of your frameworks with the LLVM Compiler. We offer better C++ standards conformance.

Of course the Boost results show that. But, you know, we have some of an advantage in that we just started recently. So, we have a very good understanding of the C++ standard, and we can implement it to the letter to make sure that if your code compiles with the LLVM Compiler, it's going to be portable to other compilers including future versions of the LLVM Compiler. We fully support Objective-C++.

Of course this is the union of Objective-C and C++, and there are some corners there what we need to deal with, we've done so, and we think we have a great product here for Objective-C++ programmers that want to use C++ and they want to use Cocoa together, or UIKit. Now, no compiler transition is completely easy, we understand that.

And the flip side of having better C++ standards conformance is that LLVM Compiler is actually more strict about C++ than GCC was, right. It actually does much more especially in area of templates to make sure that your code is conforming C++ code. To that end, there's a C++ compatibility page up on the Open Source website.

When you're trying out the LLVM Compiler, I strongly recommend that you go check it out. It has common pitfalls along with the explanations of why the LLVM Compiler is right and how to fix your code, and avoid this case. Yeah, avoid this case in the future. If you want to try out this new compiler, which I highly recommend, in Xcode 4, very easy. First of all, you can just start a new project.

It is the default compiler. Start new project, start writing C++ code. If you're importing a project from Xcode 3 into Xcode 4, just go into the project build settings, search for compiler, and select the LLVM Compiler 2.0. And as we've pointed out, notice the GCC 4.0 is not on this list, right, GCC 4.0 is gone, please move forward. OK. If you're a command line user, you use make files some other tool, then you can get that Clang and Clang C++ support with the LLVM Compiler.

In Xcode 4, usr/bin/clang, this is the replacement for GCC for C and Objective-C code, or Xcode/user/bin/clang++ is the replacement for G++, for C++ and Objective-C++ code. Now, the Clang driver program, which is the LLVM Compiler, is drop-in compatible with GCC and G++. So, just change your compiler, run a make file project, it should just work. Alright. Let's take a look at performance.

I claimed that the LLVM Compiler is faster at building C++ code than GCC, so here are a couple of examples. So, this is Compile-Time Performance on a debug build, right. Debug build is where it's the front end, the Parser that actually takes a lot of time. So, we have two projects here, we have the Mac OS X Linker, which is small but meaty C++ application that uses a lot of the C++ feature set, and we have the LLVM Compiler itself. So, with the Linker, we can build the Linker about 25 percent faster than GCC could. With the LLVM Compiler, things are about the same, so there's a much larger code base.

You know, three-quarters of a million lines of C++ code, we built it 27 percent faster. Now, we use this, and I can tell you that 25 percent-27 percent is actually significant, you notice this, this is minutes off your build time, and that's wonderful. But we think we're not done yet. So, we spent all of the last year just bringing up C++ support, it turns out to be a huge language.

And we have not yet gotten to the point--

Oh, you agree with me? OK. We haven't yet gotten to the point of actually being able to really tune the front end, to be really fast, right. We have got lots of low-hanging fruit, so we're hoping in the future we can do better than this just 25 to 27 percent faster for your C++ applications, because, you know, this actually really matters for our build times and for our own productivity. So, Memory Usage is another area where the LLVM Compiler has typically been very good, right.

So, let's take an example of building the Mac OS X Linker. So, this is just some representative sample out of the Linker. GCC versus the LLVM Compiler. GCC takes about 220 megabytes to compile one file in the Mac OS X Linker, right. The LLVM Compiler comes in at 33 percent smaller, less than 150 megabytes to do the exact same thing, right.

For a variety of reasons, this is great.

Of course using less memory uses less memory bandwidth, you get better performance, but far more important is that when you're building 16-way right, you've got 16 C++ jobs going, 33 percent smaller means it's much more likely that you're not going to start swapping, you're not going to have to kill apps to actually be able to build your code. This is really, really helpful in the development process, and of course, it makes things faster.

So, let's move on to the other main feature of the LLVM Compiler, right, which is better errors and warnings that actually describes things in a way that you can understand them and fix the problem quickly. So, let's take a typical C++ problem, right, access control. And look at what GCC says. So, here we have a relatively simple example, we've got a clear function. It looks like it's public to me.

Some part down at the bottom of the code we tried to call clear, and we get a diagnostic that says, "Hey this clear function is inaccessible" over here some place later in the code, that's GCC. What can the LLVM Compiler do to actually help us? Well, the LLVM Compiler is going to give us much more precise information.

So, first of all, the error that shows up shows up at exactly the point where the clear function is called, that's where the error is. It's not up at the declaration of clear which on line 3, which is where GCC told us to look first, that's wrong, right.

So, this is the problem at the call to clear, however, this is a private member, maybe you didn't mean it to be a private member. So, what the LLVM Compiler does is it will give you notes following the error or the warning with relevant information to help you diagnose what's going wrong. So, in this case, the first note is highlighting our inheritance of vector from the vector implementation class.

Alright. What you notice here is we didn't write that it was public inheritance or private inheritance. And so, the compiler is forced to implicitly assume you meant private, well, that's not great, the note says this is implicitly private, probably not what you meant, maybe you want to make this public and the example actually work.

We'll give you a second note at the bottom to say this is the clear member we actually found, right. Why is this important? Well, in this case, there's only one clear function, however in many cases, you have overloads and some of them might be public, and some of them might be private. So, we have to show you which one we found so you can say, "Ah, this is what I meant to find, there's another problem" or "This isn't the function I meant to call, let me go see what I did wrong." Ambiguity is multiple inheritance, right.

This is another complicated area of C++ where the compiler could really help you. So, here we have some of the classic multiple inheritance problem, right. We have a Person class, we have Teacher and Student classes that inherit from person, and then we have a Teaching Assistant, who's both a Teacher and a Student. And this is fine.

This is perfectly valid C++ code up until the point where you actually want to treat your TeachingAssistants like people.

So, any compiler is going to tell you that there's an ambiguous conversion here, right. You can't convert from a TeachingAssistant object to a Person object because there's an ambiguity in the hierarchy.

So, what LLVM Compiler is going to tell you is it's actually going to show you what are the paths through the hierarchy that causes the ambiguities. You're going to have to find these yourself, right. You're going to have to go look up at the source code and trace there and say, "Oh, wait, the TeachingAssistant is a Teacher, oh, that inherits from Person this way, and so on," you'll have to do this twice.

What the LLVM Compiler does is it shows you the paths, so you don't have to go hunt it down in your source code, right. You just see what the problem is and realize, "Oops, I needed virtual inheritance."

And the LLVM Compiler tries to do this everywhere it can to try to give you the information you need so you don't have to go hunting for your source code to figure out what actually went wrong.

So, spellchecking, right. This is in LLVM Compiler 1.5 in Xcode 3. It also shows up in Xcode 4. And we use it throughout C++, throughout the compiler to give you corrections. So, here, well, we've mistyped the name of vector when we refer to it in namespace std, so therefore, we give a correction that says, "Hey, we think you meant this other vector thing, here's the correction." And then, we'll put a follow-on note to say if , that tells you what we actually corrected to.

And if that's the thing that you expected to write there, perfect, you're all set. Now notice this little vector down below the caret line. So, this is actually how you see Fix-it hints if you're using the command line compiler. It's just a totally different UI on Fix-its that says here's the text that you should put at the point that I'm pointing too in the caret.

Now, of course, if you're on the Xcode 4 IDE and building C++ code there or C code there, these Fix-its turn into the little Fix-it UI that allows you just to apply the change quickly and keep moving on. Again, this is modularity and reuse. We can have multiple UIs for the same core feature of the Fix-it. OK. One last example of diagnostics.

So, this is one of the worst parts of programming in C++. You have some overloaded functions, and you make a call to those overloaded functions, but you make a mistake, right, none of those functions actually does match. With any other compiler, the LLVM Compiler will tell you, "Well, none of these function matches, I'm sorry, I can't call draw." At this point, what you're used to expecting, of course, is a long list of candidate functions, right. What did the compiler consider, consider this, this, this, this, and this, good luck with that. So, the LLVM Compiler, of course, it has to tell you this candidate list.

It's important for it to tell you what did it consider so you can go look at those things. But what the LLVM Compiler does, in addition, is it tells you why it rejected this particular candidate for each of the candidates. So in this case, we have the second function.

This is probably the one we meant to call, right. The first parameter matches up, we've got a pointer to points, had to match the pointer to points. It's the second argument where there's no conversation here, right. We can't convert a pointer down to an integer for the second argument. That tells us what the mistake was.

We should have passed the length or the difference between these two pointers rather than just passing the two pointers along. And LLVM Compiler helps us zero in on that as our actual mistake. Now, of course, it's going to tell us that there's another candidate function here, right, the first function. And here, we had the wrong number of arguments, right. We've passed in three arguments that actually expected two arguments. This function is clearly on visible. There's something else very subtle going on here.

Notice that the order in which I have the functions written up in the source code is different. It's actually the opposite of the order that the diagnostic show up in the notes. So, the LLVM Compiler is actually using some heuristics here to try to tell you first the function it thinks is mostly likely that you actually meant to call, and put the less relevant candidate below, right.

So I expect to be working on these heuristics for a while.

But it is very, very helpful to help you zero in on this is the problem, here is why the compiler rejected what I wrote so you can fix it quickly. Instead of having to second guess what the compiler is doing. OK. So, we have very good diagnostics in the LLVM Compiler, we have good performance. I guess we're done right, not so. C++ language isn't a static language, right.

It's not that it's been written once and it never changes, in fact the C++ language is continually evolving, and the C++ standardization committee is working hard on the next C++ standard, right. This is called C++'0x typically. And it actually has a whole of great new features in both the language and in the library. So, language features, of course, you can go look this up, but it has things like simple-type inference where you can have auto variables that determine their type based on their initializers to save you a whole lot of typing when you're writing things quickly.

And it has moved semantics to help you actually improve the performance of your code by moving resources around rather than making expensive copies. And these features have made it into a new C++ standard library that comes with C++ '0x. It uses move semantics throughout to give you better performance in your applications just by recompiling.

And also it has new features like regular expression support built-in, and hash cables in the library. Now, all these new features in the C++ '0x standard are backward compatible with the current C++ standard. So, if your code builds as C++ code today, and it's correct, it will work tomorrow except for a few corners where they've decided to break backward compatibility. So, the C++ '0x standard is not finished.

It's still in the works. Right now, it's looking like we'll get a finalized standard sometime next year for C++ '0x, right. So, rather than actually delaying until all the ink is dry, we've actually started working on the C++ '0x standard in the form of a completely new implementation of the C++ standard library, called libc++.

So, this is a complete redesign of the C++ standard library, so it's built from the ground up for complete C++ '0x support so that when that standard is available, we can actually be ready for it, right, and you can start using C++ '0x features. And one of the great things about starting a new C++ standard library is we've learned a lot in the past decade of using the new C++ standard library.

And now, we can actually know how to build new implementations for the algorithms in the standard library that are faster, that provide better performance. We know how to build data structures that are smaller, faster, right. So, your applications get better just by compiling with the new library and using these better implementations. And like all of the other LLVM projects, libc++ is part of the LLVM umbrella project. It's a 100 percent open source.

If you're interested in it, you can go check it out at libcxx.llvm.org to see what the future of the C++ standard library is going to look like for the '0x standard. So, talking a lot about C++, let's take a look back at sort of the evolution of tools here for-- the Apple tools for C++.

So, the current compiler, what you should be using for C++ code here is LLVM-GCC. So, this is a production quality compiler, it's very stable. It combines the GCC front end with the LLVM back end, right, gives better performance, and the existing GCC standard library. Moving forward, we have the LLVM Compiler.

So, this is using the Clang front end, we've been talking about with the LLVM back end. And for C++ '98 applications, which is the current C++ standard, we'll use the GCC standard library to provide perfect interoperability with LLVM-GCC. Now moving forward to the C++ '0x standard, we're only going to be implementing C++ '0x features in the Clang front end. There will be no C++ '0x support in GCC or LLVM-GCC. So, if you're interested in the new standard, you're going to need to move to the new compiler.

Similarly on the library side, C++ '0x support will require the libc++ standard library where we've been able to build and engineer the entire thing for proper C++ '0x support. Now, to wrap up the session here, we've talked about two completely different Xcode releases. We have the newest Xcode 3 release, Xcode 3.2.3.

It includes a completely new LLVM-GCC Compiler. So, this is the first LLVM-GCC that supports iPhone OS development for the iPad and the iPhone. It has better optimizers right to produce smaller compiled binaries that run faster. We also have the new version of the LLVM Compiler, version 1.5. So, this has all the benefits of LLVM-GCC, the iPhone OS development support, great performance and compiled code, but it provides you with super fast compiles, right, three times faster we've seen on large Objective-C applications. And over the previous version of the LLVM Compiler, it has a whole bunch of new warnings, spellchecking, and many improvements to the Static Analyzer to find more bugs with fewer false positives.

So looking forward, we have the Developer Preview of Xcode 4, right, where we've really taken the LLVM Compiler and moved it inside the IDE to give you a much better experience. With the new version of the LLVM Compiler we talked about here, that C++ and Objective-C++ support for the first time, and a brand new debugger based on LLVM technologies. And many of the features like code completion, source code indexing, and so on, are built into the Xcode 4 IDE using the Clang front end. Including live warnings and Fix-its to help you get to your code. There's a couple of related sessions.

So later on, we have the LLVM Technologies In-Depth Session where we'll talk about how these technologies are actually going to be used within Xcode 4 to produce better tools and give you better experience. There's also a Debugging Session tomorrow on using the LLDB debugger. So, if you're interested in these technologies, if you want more information, you can talk to our Developer Tools Evangelist, Michael Jurewitz. Or you can surf over to the LLVM Project Open Source homepage at llvm.org for more information about the entire project, or talk to us at the Apple Developer Forums.