Chris Lattner | ce90ba6 | 2007-12-10 05:20:47 +0000 | [diff] [blame^] | 1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" |
| 2 | "http://www.w3.org/TR/html4/strict.dtd"> |
Chris Lattner | 7a27439 | 2007-10-06 05:23:00 +0000 | [diff] [blame] | 3 | <html> |
| 4 | <head> |
Chris Lattner | ce90ba6 | 2007-12-10 05:20:47 +0000 | [diff] [blame^] | 5 | <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /> |
| 6 | <title>Clang - Features</title> |
| 7 | <link type="text/css" rel="stylesheet" href="menu.css" /> |
| 8 | <link type="text/css" rel="stylesheet" href="content.css" /> |
| 9 | <style type="text/css"> |
Chris Lattner | 7a27439 | 2007-10-06 05:23:00 +0000 | [diff] [blame] | 10 | </style> |
| 11 | </head> |
| 12 | <body> |
Chris Lattner | ce90ba6 | 2007-12-10 05:20:47 +0000 | [diff] [blame^] | 13 | |
Chris Lattner | 7a27439 | 2007-10-06 05:23:00 +0000 | [diff] [blame] | 14 | <!--#include virtual="menu.html.incl"--> |
Chris Lattner | ce90ba6 | 2007-12-10 05:20:47 +0000 | [diff] [blame^] | 15 | |
Chris Lattner | 7a27439 | 2007-10-06 05:23:00 +0000 | [diff] [blame] | 16 | <div id="content"> |
Chris Lattner | 7a27439 | 2007-10-06 05:23:00 +0000 | [diff] [blame] | 17 | |
Chris Lattner | ce90ba6 | 2007-12-10 05:20:47 +0000 | [diff] [blame^] | 18 | <h1>Features of Clang</h1> |
| 19 | <p> |
| 20 | This page outlines the main goals of Clang, as well as some compelling reasons |
| 21 | why you should consider using Clang. In the Goals section below, you will find |
| 22 | a brief, bulleted overview of the goals and features that we are striving for |
| 23 | in the development of Clang. However, in the <a href="#keyfeatures">Key |
| 24 | Features</a> section you will find a more detailed presentation on what we |
| 25 | believe are some key drawing points for the Clang front-end.</p> |
Chris Lattner | 7a27439 | 2007-10-06 05:23:00 +0000 | [diff] [blame] | 26 | |
Chris Lattner | 7a27439 | 2007-10-06 05:23:00 +0000 | [diff] [blame] | 27 | <h1><a name="keyfeatures">Key Features</a></h1> |
| 28 | |
| 29 | There are several key features which we believe make Clang an exciting front-end. These features are designed to make things easier for both the compiler developer (people working on Clang and derivative products) and the application developer (those who use Clang/LLVM). |
| 30 | |
| 31 | <h2>Library based architecture</h2> |
| 32 | A major design concept for the LLVM front-end involves using a library based architecture. In this library based architecture, various parts of the front-end can be cleanly divided into separate libraries which can then be mixed up for different needs and uses. In addition, the library based approach makes it much easier for new developers to get involved and extend LLVM to do new and unique things. In the words of Chris, |
Chris Lattner | bafc68f | 2007-10-06 05:48:57 +0000 | [diff] [blame] | 33 | <div class="quote">"The world needs better compiler tools, tools which are built as libraries. This design point allows reuse of the tools in new and novel ways. However, building the tools as libraries isn't enough: they must have clean APIs, be as decoupled from each other as possible, and be easy to modify/extend. This requires clean layering, decent design, and keeping the libraries independent of any specific client."</div> |
Chris Lattner | 7a27439 | 2007-10-06 05:23:00 +0000 | [diff] [blame] | 34 | Currently, the LLVM front-end is divided into the following libraries: |
| 35 | <ul> |
| 36 | <li>libsupport - Basic support library, reused from LLVM. |
| 37 | <li>libsystem - System abstraction library, reused from LLVM. |
| 38 | <li>libbasic - Diagnostics, SourceLocations, SourceBuffer abstraction, file system caching for input source files. <span class="weak_txt">(depends on above libraries)</span> |
| 39 | <li>libast - Provides classes to represent the C AST, the C type system, builtin functions, and various helpers for analyzing and manipulating the AST (visitors, pretty printers, etc). <span class="weak_txt">(depends on above libraries)</span> |
| 40 | <li>liblex - C/C++/ObjC lexing and preprocessing, identifier hash table, pragma handling, tokens, and macros. <span class="weak_txt">(depends on above libraries)</span> |
| 41 | <li>libparse - Parsing and local semantic analysis. This library invokes coarse-grained 'Actions' provided by the client to do stuff (e.g. libsema builds ASTs). <span class="weak_txt">(depends on above libraries)</span> |
| 42 | <li>libsema - Provides a set of parser actions to build a standardized AST for programs. AST's are 'streamed' out a top-level declaration at a time, allowing clients to use decl-at-a-time processing, build up entire translation units, or even build 'whole program' ASTs depending on how they use the APIs. <span class="weak_txt">(depends on libast and libparse)</span> |
| 43 | <li>libcodegen - Lower the AST to LLVM IR for optimization & codegen. <span class="weak_txt">(depends on libast)</span> |
| 44 | <li>librewrite - Editing of text buffers, depends on libast.</li> |
| 45 | <li>libanalysis - Static analysis support, depends on libast.</li> |
| 46 | <li><b>clang</b> - An example driver, client of the libraries at various levels. <span class="weak_txt">(depends on above libraries, and LLVM VMCore)</span> |
| 47 | </ul> |
| 48 | As an example of the power of this library based design.... If you wanted to build a preprocessor, you would take the Basic and Lexer libraries. If you want an indexer, you would take the previous two and add the Parser library and some actions for indexing. If you want a refactoring, static analysis, or source-to-source compiler tool, you would then add the AST building and semantic analyzer libraries. |
| 49 | In the end, LLVM's library based design will provide developers with many more possibilities. |
| 50 | |
Chris Lattner | 40ae32f | 2007-12-10 05:06:15 +0000 | [diff] [blame] | 51 | <h2><a name="performance">Speed and Memory</a></h2> |
Chris Lattner | 96e778b | 2007-10-06 05:30:19 +0000 | [diff] [blame] | 52 | Another major focus of LLVM's frontend is speed (for all libraries). Even at this early stage, the clang front-end is quicker than gcc and uses less memory.<br> |
Chris Lattner | 7a27439 | 2007-10-06 05:23:00 +0000 | [diff] [blame] | 53 | <div class="img_container"> |
| 54 | <div class="img_title">Memory:</div> |
| 55 | <img src="feature-memory1.png" /> |
| 56 | <div class="img_desc">This test was run using Mac OS X's Carbon.h header, which is 12.3MB spread across 558 files! |
Chris Lattner | 96e778b | 2007-10-06 05:30:19 +0000 | [diff] [blame] | 57 | Although large headers are one of the worst case scenarios for GCC, they are very common and it shows how clang's implemenation is significantly more memory efficient. |
Chris Lattner | 7a27439 | 2007-10-06 05:23:00 +0000 | [diff] [blame] | 58 | </div> |
| 59 | </div> |
| 60 | <div class="img_container"> |
| 61 | <div class="img_title">Performance:</div> |
| 62 | <img src="feature-compile1.png" /> |
Chris Lattner | 96e778b | 2007-10-06 05:30:19 +0000 | [diff] [blame] | 63 | <div class="img_desc">Even at this early stage, the C parser for Clang is able to achieve significantly better performance. Many optimizations are still possible of course. |
Chris Lattner | 7a27439 | 2007-10-06 05:23:00 +0000 | [diff] [blame] | 64 | </div> |
| 65 | </div> |
| 66 | <div class="img_container"> |
| 67 | <div class="img_title">Performance:</div> |
| 68 | <img src="feature-compile2.png" /> |
Chris Lattner | 96e778b | 2007-10-06 05:30:19 +0000 | [diff] [blame] | 69 | <div class="img_desc">By using very trivial file-system caching, clang can significantly speed up preprocessing-bound applications like distcc. <span class="img_notes">(<a href="clang_video-07-25-2007.html">more details</a>)</span> |
| 70 | </div> |
Chris Lattner | 7a27439 | 2007-10-06 05:23:00 +0000 | [diff] [blame] | 71 | </div> |
| 72 | |
| 73 | <h2><a name="expressivediags">Expressive Diagnostics</a></h2> |
Chris Lattner | 96e778b | 2007-10-06 05:30:19 +0000 | [diff] [blame] | 74 | Clang is designed to efficiently capture range information for expressions and statements, which allows it to emit very detailed diagnostic information when a problem is detected.<br> |
Chris Lattner | 7a27439 | 2007-10-06 05:23:00 +0000 | [diff] [blame] | 75 | <div class="img_container"> |
| 76 | <div class="img_title">Clang vs GCC:</div> |
| 77 | <img src="feature-diagnostics1.png" /> |
| 78 | <div class="img_desc">There are several things to take note of in this example: |
| 79 | <ul> |
| 80 | <li>The error messages from Clang are more detailed. |
| 81 | <li>Clang shows you exactly where the error is, plus the range it has a problem with. |
| 82 | </ul> |
| 83 | </div> |
| 84 | <div class="img_notes"><span>Notes:</span>The first results are from clang; the second results are from gcc.</div> |
| 85 | </div> |
| 86 | <h2>Better Integration with IDEs</h2> |
Chris Lattner | 96e778b | 2007-10-06 05:30:19 +0000 | [diff] [blame] | 87 | Another design goal of Clang is to integrate extremely well with IDEs. IDEs often have very different requirements than code generation, often requiring information that a codegen-only frontend can throw away. Clang is specifically designed and built to capture this information. |
Chris Lattner | 7a27439 | 2007-10-06 05:23:00 +0000 | [diff] [blame] | 88 | </div> |
| 89 | </body> |
Chris Lattner | bafc68f | 2007-10-06 05:48:57 +0000 | [diff] [blame] | 90 | </html> |