Gitiles
Code Review Sign In
gerrit-public.fairphone.software / fp2-dev / platform / external / clang / cf086eaf3ff15a394e76b7f21918f0f958ea7fb9 / . / www / features.html
blob: 718a1e877e66303b5e3c57ab598289c1c0d50ca2 [file] [log] [blame]
Chris Lattnerce90ba62007-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 Lattner7a274392007-10-06 05:23:00 +0000[diff] [blame]3<html>
4<head>
Chris Lattnerce90ba62007-12-10 05:20:47 +0000[diff] [blame]5 <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
Chris Lattner6908f302007-12-10 05:52:05 +0000[diff] [blame]6 <title>Clang - Features and Goals</title>
Chris Lattnerce90ba62007-12-10 05:20:47 +0000[diff] [blame]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 Lattner7a274392007-10-06 05:23:00 +0000[diff] [blame]10</style>
11</head>
12<body>
Chris Lattnerce90ba62007-12-10 05:20:47 +0000[diff] [blame]13
Chris Lattner7a274392007-10-06 05:23:00 +0000[diff] [blame]14<!--#include virtual="menu.html.incl"-->
Chris Lattnerce90ba62007-12-10 05:20:47 +0000[diff] [blame]15
Chris Lattner7a274392007-10-06 05:23:00 +0000[diff] [blame]16<div id="content">
Chris Lattner7a274392007-10-06 05:23:00 +0000[diff] [blame]17
Chris Lattneread27db2007-12-10 08:12:49 +0000[diff] [blame]18<!--*************************************************************************-->
Chris Lattner6908f302007-12-10 05:52:05 +0000[diff] [blame]19<h1>Clang - Features and Goals</h1>
Chris Lattneread27db2007-12-10 08:12:49 +0000[diff] [blame]20<!--*************************************************************************-->
21
Chris Lattner6908f302007-12-10 05:52:05 +0000[diff] [blame]22<p>
23This page describes the <a href="index.html#goals">features and goals</a> of
24Clang in more detail and gives a more broad explanation about what we mean.
25These features are:
26</p>
Chris Lattner7a274392007-10-06 05:23:00 +0000[diff] [blame]27
Chris Lattner1a380a02007-12-10 07:14:08 +0000[diff] [blame]28<p>End-User Features:</p>
29
30<ul>
Chris Lattneread27db2007-12-10 08:12:49 +0000[diff] [blame]31<li><a href="#performance">High performance and low memory use</a></li>
Chris Lattnercf086ea2007-12-10 08:19:29 +0000[diff] [blame^]32<li><a href="#expressivediags">Expressive diagnostics</a></li>
Chris Lattnerb5604af2007-12-10 07:23:52 +0000[diff] [blame]33<li><a href="#gcccompat">GCC compatibility</a></li>
Chris Lattner1a380a02007-12-10 07:14:08 +0000[diff] [blame]34</ul>
35
Chris Lattneread27db2007-12-10 08:12:49 +0000[diff] [blame]36<p>Utility and Applications:</p>
37
38<ul>
39<li><a href="#libraryarch">Library based architecture</a></li>
40<li><a href="#diverseclients">Support diverse clients</a></li>
41<li><a href="#ideintegration">Integration with IDEs</a></li>
42<li><a href="#license">Use the LLVM 'BSD' License</a></li>
43</ul>
44
45<p>Internal Design and Implementation:</p>
46
Chris Lattner6908f302007-12-10 05:52:05 +0000[diff] [blame]47<ul>
48<li><a href="#real">A real-world, production quality compiler</a></li>
Chris Lattnerb5604af2007-12-10 07:23:52 +0000[diff] [blame]49<li><a href="#simplecode">A simple and hackable code base</a></li>
Chris Lattner6908f302007-12-10 05:52:05 +0000[diff] [blame]50<li><a href="#unifiedparser">A single unified parser for C, Objective C, C++,
51 and Objective C++</a></li>
52<li><a href="#conformance">Conformance with C/C++/ObjC and their
53 variants</a></li>
54</ul>
Chris Lattner7a274392007-10-06 05:23:00 +0000[diff] [blame]55
Chris Lattneread27db2007-12-10 08:12:49 +0000[diff] [blame]56<!--*************************************************************************-->
Chris Lattnercf086ea2007-12-10 08:19:29 +0000[diff] [blame^]57<h1><a name="enduser">End-User Features</a></h1>
Chris Lattneread27db2007-12-10 08:12:49 +0000[diff] [blame]58<!--*************************************************************************-->
Chris Lattner1a380a02007-12-10 07:14:08 +0000[diff] [blame]59
60
61<!--=======================================================================-->
62<h2><a name="performance">High Performance and Low Memory Use</a></h2>
63<!--=======================================================================-->
64
65<p>A major focus of our work on clang is to make it fast, light and scalable.
66The library-based architecture of clang makes it straight-forward to time and
67profile the cost of each layer of the stack, and the driver has a number of
68options for performance analysis.</p>
69
70<p>While there is still much that can be done, we find that the clang front-end
71is significantly quicker than gcc and uses less memory For example, when
72compiling "Carbon.h" on Mac OS/X, we see that clang is 2.5x faster than GCC:</p>
73
74<img class="img_slide" src="feature-compile1.png" width="400" height="300" />
75
76<p>Carbon.h is a monster: it transitively includes 558 files, 12.3M of code,
77declares 10000 functions, has 2000 struct definitions, 8000 fields, 20000 enum
78constants, etc (see slide 25+ of the <a href="clang_video-07-25-2007.html">clang
79talk</a> for more information). It is also #include'd into almost every C file
80in a GUI app on the Mac, so its compile time is very important.</p>
81
82<p>From the slide above, you can see that we can measure the time to preprocess
83the file independently from the time to parse it, and independently from the
84time to build the ASTs for the code. GCC doesn't provide a way to measure the
85parser without AST building (it only provides -fsyntax-only). In our
86measurements, we find that clang's preprocessor is consistently 40% faster than
87GCCs, and the parser + AST builder is ~4x faster than GCC's. If you have
88sources that do not depend as heavily on the preprocessor (or if you
89use Precompiled Headers) you may see a much bigger speedup from clang.
90</p>
91
92<p>Compile time performance is important, but when using clang as an API, often
93memory use is even moreso: the less memory the code takes the more code you can
94fit into memory at a time (useful for whole program analysis tools, for
95example).</p>
96
97<img class="img_slide" src="feature-memory1.png" width="400" height="300" />
98
99<p>Here we see a huge advantage of clang: its ASTs take <b>5x less memory</b>
100than GCC's syntax trees, despite the fact that clang's ASTs capture far more
101source-level information than GCC's trees do. This feat is accomplished through
102the use of carefully designed APIs and efficient representations.</p>
103
104<p>In addition to being efficient when pitted head-to-head against GCC in batch
105mode, clang is built with a <a href="#libraryarch">library based
106architecture</a> that makes it relatively easy to adapt it and build new tools
107with it. This means that it is often possible to apply out-of-the-box thinking
108and novel techniques to improve compilation in various ways.</p>
109
110<img class="img_slide" src="feature-compile2.png" width="400" height="300" />
111
112<p>This slide shows how the clang preprocessor can be used to make "distcc"
113parallelization <b>3x</b> more scalable than when using the GCC preprocessor.
114"distcc" quickly bottlenecks on the preprocessor running on the central driver
115machine, so a fast preprocessor is very useful. Comparing the first two bars
116of each group shows how a ~40% faster preprocessor can reduce preprocessing time
117of these large C++ apps by about 40% (shocking!).</p>
118
119<p>The third bar on the slide is the interesting part: it shows how trivial
120caching of file system accesses across invocations of the preprocessor allows
121clang to reduce time spent in the kernel by 10x, making distcc over 3x more
122scalable. This is obviously just one simple hack, doing more interesting things
123(like caching tokens across preprocessed files) would yield another substantial
124speedup.</p>
125
126<p>The clean framework-based design of clang means that many things are possible
127that would be very difficult in other systems, for example incremental
128compilation, multithreading, intelligent caching, etc. We are only starting
129to tap the full potential of the clang design.</p>
130
131
132<!--=======================================================================-->
133<h2><a name="expressivediags">Expressive Diagnostics</a></h2>
134<!--=======================================================================-->
135
136<p>Clang is designed to efficiently capture range information for expressions
137and statements, which allows it to emit very useful and detailed diagnostic
138information (e.g. warnings and errors) when a problem is detected.</p>
139
140<p>For example, this slide compares the diagnostics emitted by clang (top) to
141the diagnostics emitted by GCC (middle) for a simple example:</p>
142
143<img class="img_slide" src="feature-diagnostics1.png" width="400" height="300"/>
144
145<p>As you can see, clang goes beyond tracking just column number information: it
146is able to highlight the subexpressions involved in a problem, making it much
147easier to understand the source of the problem in many cases. For example, in
148the first problem, it tells you <em>why</em> the operand is invalid (it
149requires a pointer) and what type it really is.</p>
150
151<p>In the second error, you can see how clang uses column number information to
152identify exactly which "+" out of the four on that line is causing the problem.
153Further, it highlights the subexpressions involved, which can be very useful
154when a complex subexpression that relies on tricky precedence rules.</p>
155
156<p>The example doesn't show it, but clang works very hard to retain typedef
157information, ensuring that diagnostics print the user types, not the fully
158expanded (and often huge) types. This is clearly important for C++ code (tell
159me about "<tt>std::string</tt>", not about "<tt>std::basic_string&lt;char,
160std::char_traits&lt;char&gt;, std::allocator&lt;char&gt; &gt;</tt>"!), but it is
161also very useful in C code in some cases as well (e.g. "<tt>__m128"</tt> vs
162"<tt>float __attribute__((__vector_size__(16)))</tt>").</p>
163
Chris Lattnerb5604af2007-12-10 07:23:52 +0000[diff] [blame]164<!--=======================================================================-->
165<h2><a name="gcccompat">GCC Compatibility</a></h2>
166<!--=======================================================================-->
167
168<p>GCC is currently the defacto-standard open source compiler today, and it
169routinely compiles a huge volume of code. GCC supports a huge number of
170extensions and features (many of which are undocumented) and a lot of
171code and header files depend on these features in order to build.</p>
172
173<p>While it would be nice to be able to ignore these extensions and focus on
174implementing the language standards to the letter, pragmatics force us to
175support the GCC extensions that see the most use. Many users just want their
176code to compile, they don't care to argue about whether it is pedantically C99
177or not.</p>
178
179<p>As mentioned above, all
180extensions are explicitly recognized as such and marked with extension
181diagnostics, which can be mapped to warnings, errors, or just ignored.
182</p>
183
Chris Lattner1a380a02007-12-10 07:14:08 +0000[diff] [blame]184
Chris Lattneread27db2007-12-10 08:12:49 +0000[diff] [blame]185<!--*************************************************************************-->
Chris Lattnercf086ea2007-12-10 08:19:29 +0000[diff] [blame^]186<h1><a name="applications">Utility and Applications</a></h1>
Chris Lattneread27db2007-12-10 08:12:49 +0000[diff] [blame]187<!--*************************************************************************-->
188
Chris Lattner1a380a02007-12-10 07:14:08 +0000[diff] [blame]189<!--=======================================================================-->
Chris Lattneread27db2007-12-10 08:12:49 +0000[diff] [blame]190<h2><a name="libraryarch">Library Based Architecture</a></h2>
Chris Lattner1a380a02007-12-10 07:14:08 +0000[diff] [blame]191<!--=======================================================================-->
192
Chris Lattneread27db2007-12-10 08:12:49 +0000[diff] [blame]193<p>A major design concept for clang is its use of a library-based
194architecture. In this design, various parts of the front-end can be cleanly
195divided into separate libraries which can then be mixed up for different needs
196and uses. In addition, the library-based approach encourages good interfaces
197and makes it easier for new developers to get involved (because they only need
198to understand small pieces of the big picture).</p>
199
200<blockquote>
201"The world needs better compiler tools, tools which are built as libraries.
202This design point allows reuse of the tools in new and novel ways. However,
203building the tools as libraries isn't enough: they must have clean APIs, be as
204decoupled from each other as possible, and be easy to modify/extend. This
205requires clean layering, decent design, and keeping the libraries independent of
206any specific client."</blockquote>
207
208<p>
209Currently, clang is divided into the following libraries and tool:
210</p>
211
212<ul>
213<li><b>libsupport</b> - Basic support library, from LLVM.</li>
214<li><b>libsystem</b> - System abstraction library, from LLVM.</li>
215<li><b>libbasic</b> - Diagnostics, SourceLocations, SourceBuffer abstraction,
216 file system caching for input source files.</li>
217<li><b>libast</b> - Provides classes to represent the C AST, the C type system,
218 builtin functions, and various helpers for analyzing and manipulating the
219 AST (visitors, pretty printers, etc).</li>
220<li><b>liblex</b> - Lexing and preprocessing, identifier hash table, pragma
221 handling, tokens, and macro expansion.</li>
222<li><b>libparse</b> - Parsing. This library invokes coarse-grained 'Actions'
223 provided by the client (e.g. libsema builds ASTs) but knows nothing about
224 ASTs or other client-specific data structures.</li>
225<li><b>libsema</b> - Semantic Analysis. This provides a set of parser actions
226 to build a standardized AST for programs.</li>
227<li><b>libcodegen</b> - Lower the AST to LLVM IR for optimization &amp; code
228 generation.</li>
229<li><b>librewrite</b> - Editing of text buffers (important for code rewriting
230 transformation, like refactoring).</li>
231<li><b>libanalysis</b> - Static analysis support.</li>
232<li><b>clang</b> - A driver program, client of the libraries at various
233 levels.</li>
234</ul>
235
236<p>As an example of the power of this library based design.... If you wanted to
237build a preprocessor, you would take the Basic and Lexer libraries. If you want
238an indexer, you would take the previous two and add the Parser library and
239some actions for indexing. If you want a refactoring, static analysis, or
240source-to-source compiler tool, you would then add the AST building and
241semantic analyzer libraries.</p>
242
243<p>For more information about the low-level implementation details of the
244various clang libraries, please see the <a href="docs/InternalsManual.html">
245clang Internals Manual</a>.</p>
246
247<!--=======================================================================-->
248<h2><a name="diverseclients">Support Diverse Clients</a></h2>
249<!--=======================================================================-->
250
251<p>Clang is designed and built with many grand plans for how we can use it. The
252driving force is the fact that we use C and C++ daily, and have to suffer due to
253a lack of good tools available for it. We believe that the C and C++ tools
254ecosystem has been significantly limited by how difficult it is to parse and
255represent the source code for these languages, and we aim to rectify this
256problem in clang.</p>
257
258<p>The problem with this goal is that different clients have very different
259requirements. Consider code generation, for example: a simple front-end that
260parses for code generation must analyze the code for validity and emit code
261in some intermediate form to pass off to a optimizer or backend. Because
262validity analysis and code generation can largely be done on the fly, there is
263not hard requirement that the front-end actually build up a full AST for all
264the expressions and statements in the code. TCC and GCC are examples of
265compilers that either build no real AST (in the former case) or build a stripped
266down and simplified AST (in the later case) because they focus primarily on
267codegen.</p>
268
269<p>On the opposite side of the spectrum, some clients (like refactoring) want
270highly detailed information about the original source code and want a complete
271AST to describe it with. Refactoring wants to have information about macro
272expansions, the location of every paren expression '(((x)))' vs 'x', full
273position information, and much more. Further, refactoring wants to look
274<em>across the whole program</em> to ensure that it is making transformations
275that are safe. Making this efficient and getting this right requires a
276significant amount of engineering and algorithmic work that simply are
277unnecessary for a simple static compiler.</p>
278
279<p>The beauty of the clang approach is that it does not restrict how you use it.
280In particular, it is possible to use the clang preprocessor and parser to build
281an extremely quick and light-weight on-the-fly code generator (similar to TCC)
282that does not build an AST at all. As an intermediate step, clang supports
283using the current AST generation and semantic analysis code and having a code
284generation client free the AST for each function after code generation. Finally,
285clang provides support for building and retaining fully-fledged ASTs, and even
286supports writing them out to disk.</p>
287
288<p>Designing the libraries with clean and simple APIs allows these high-level
289policy decisions to be determined in the client, instead of forcing "one true
290way" in the implementation of any of these libraries. Getting this right is
291hard, and we don't always get it right the first time, but we fix any problems
292when we realize we made a mistake.</p>
293
294<!--=======================================================================-->
295<h2><a name="ideintegration">Integration with IDEs</h2>
296<!--=======================================================================-->
297
298<p>
299We believe that Integrated Development Environments (IDE's) are a great way
300to pull together various pieces of the development puzzle, and aim to make clang
301work well in such an environment. The chief advantage of an IDE is that they
302typically have visibility across your entire project and are long-lived
303processes, whereas stand-alone compiler tools are typically invoked on each
304individual file in the project, and thus have limited scope.</p>
305
306<p>There are many implications of this difference, but a significant one has to
307do with efficiency and caching: sharing an address space across different files
308in a project, means that you can use intelligent caching and other techniques to
309dramatically reduce analysis/compilation time.</p>
310
311<p>A further difference between IDEs and batch compiler is that they often
312impose very different requirements on the front-end: they depend on high
313performance in order to provide a "snappy" experience, and thus really want
314techniques like "incremental compilation", "fuzzy parsing", etc. Finally, IDEs
315often have very different requirements than code generation, often requiring
316information that a codegen-only frontend can throw away. Clang is
317specifically designed and built to capture this information.
318</p>
319
320
321<!--=======================================================================-->
322<h2><a name="license">Use the LLVM 'BSD' License</a></h2>
323<!--=======================================================================-->
324
325<p>We actively indend for clang (and a LLVM as a whole) to be used for
326commercial projects, and the BSD license is the simplest way to allow this. We
327feel that the license encourages contributors to pick up the source and work
328with it, and believe that those individuals and organizations will contribute
329back their work if they do not want to have to maintain a fork forever (which is
330time consuming and expensive when merges are involved). Further, nobody makes
331money on compilers these days, but many people need them to get bigger goals
332accomplished: it makes sense for everyone to work together.</p>
333
334<p>For more information about the LLVM/clang license, please see the <a
335href="http://llvm.org/docs/DeveloperPolicy.html#license">LLVM License
336Description</a> for more information.</p>
337
338
339
340<!--*************************************************************************-->
Chris Lattnercf086ea2007-12-10 08:19:29 +0000[diff] [blame^]341<h1><a name="design">Internal Design and Implementation</a></h1>
Chris Lattneread27db2007-12-10 08:12:49 +0000[diff] [blame]342<!--*************************************************************************-->
343
Chris Lattner1a380a02007-12-10 07:14:08 +0000[diff] [blame]344<!--=======================================================================-->
Chris Lattner6908f302007-12-10 05:52:05 +0000[diff] [blame]345<h2><a name="real">A real-world, production quality compiler</a></h2>
346<!--=======================================================================-->
Chris Lattner7a274392007-10-06 05:23:00 +0000[diff] [blame]347
Chris Lattner6908f302007-12-10 05:52:05 +0000[diff] [blame]348<p>
349Clang is designed and built by experienced commercial compiler developers who
350are increasingly frustrated with the problems that <a
351href="comparison.html">existing open source compilers</a> have. Clang is
352carefully and thoughtfully designed and built to provide the foundation of a
353whole new generation of C/C++/Objective C development tools, and we intend for
354it to be commercial quality.</p>
355
356<p>Being a production quality compiler means many things: it means being high
357performance, being solid and (relatively) bug free, and it means eventually
358being used and depended on by a broad range of people. While we are still in
359the early development stages, we strongly believe that this will become a
360reality.</p>
361
362<!--=======================================================================-->
Chris Lattnerb5604af2007-12-10 07:23:52 +0000[diff] [blame]363<h2><a name="simplecode">A simple and hackable code base</a></h2>
364<!--=======================================================================-->
365
366<p>Our goal is to make it possible for anyone with a basic understanding
367of compilers and working knowledge of the C/C++/ObjC languages to understand and
368extend the clang source base. A large part of this falls out of our decision to
369make the AST mirror the languages as closely as possible: you have your friendly
370if statement, for statement, parenthesis expression, structs, unions, etc, all
371represented in a simple and explicit way.</p>
372
373<p>In addition to a simple design, we work to make the source base approachable
374by commenting it well, including citations of the language standards where
375appropriate, and designing the code for simplicity. Beyond that, clang offers
376a set of AST dumpers, printers, and visualizers that make it easy to put code in
377and see how it is represented.</p>
378
379<!--=======================================================================-->
Chris Lattner6908f302007-12-10 05:52:05 +0000[diff] [blame]380<h2><a name="unifiedparser">A single unified parser for C, Objective C, C++,
381and Objective C++</a></h2>
382<!--=======================================================================-->
383
384<p>Clang is the "C Language Family Front-end", which means we intend to support
385the most popular members of the C family. We are convinced that the right
386parsing technology for this class of languages is a hand-built recursive-descent
387parser. Because it is plain C++ code, recursive descent makes it very easy for
388new developers to understand the code, it easily supports ad-hoc rules and other
389strange hacks required by C/C++, and makes it straight-forward to implement
390excellent diagnostics and error recovery.</p>
391
392<p>We believe that implementing C/C++/ObjC in a single unified parser makes the
393end result easier to maintain and evolve than maintaining a separate C and C++
394parser which must be bugfixed and maintained independently of each other.</p>
395
396<!--=======================================================================-->
397<h2><a name="conformance">Conformance with C/C++/ObjC and their
398 variants</a></h2>
399<!--=======================================================================-->
400
401<p>When you start work on implementing a language, you find out that there is a
402huge gap between how the language works and how most people understand it to
403work. This gap is the difference between a normal programmer and a (scary?
404super-natural?) "language lawyer", who knows the ins and outs of the language
405and can grok standardese with ease.</p>
406
407<p>In practice, being conformant with the languages means that we aim to support
408the full language, including the dark and dusty corners (like trigraphs,
409preprocessor arcana, C99 VLAs, etc). Where we support extensions above and
410beyond what the standard officially allows, we make an effort to explicitly call
411this out in the code and emit warnings about it (which are disabled by default,
412but can optionally be mapped to either warnings or errors), allowing you to use
413clang in "strict" mode if you desire.</p>
414
415<p>We also intend to support "dialects" of these languages, such as C89, K&amp;R
416C, C++'03, Objective-C 2, etc.</p>
417
Chris Lattner7a274392007-10-06 05:23:00 +0000[diff] [blame]418</div>
419</body>
Chris Lattnerbafc68f2007-10-06 05:48:57 +0000[diff] [blame]420</html>