From sabre at nondot.org Mon Dec 10 00:01:34 2007
From: sabre at nondot.org (Chris Lattner)
Date: Mon, 10 Dec 2007 06:01:34 -0000
Subject: [cfe-commits] r44782 - /cfe/trunk/www/comparison.html
Message-ID: <200712100601.lBA61YZw031858@zion.cs.uiuc.edu>
Author: lattner
Date: Mon Dec 10 00:01:32 2007
New Revision: 44782
URL: http://llvm.org/viewvc/llvm-project?rev=44782&view=rev
Log:
incorporate suggestions from Joel Nelson.
Modified:
cfe/trunk/www/comparison.html
Modified: cfe/trunk/www/comparison.html
URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/www/comparison.html?rev=44782&r1=44781&r2=44782&view=diff
==============================================================================
--- cfe/trunk/www/comparison.html (original)
+++ cfe/trunk/www/comparison.html Mon Dec 10 00:01:32 2007
@@ -25,7 +25,11 @@
The goal of this list is to describe how differences in goals lead to
different strengths and weaknesses, not to make some compiler look bad.
This will hopefully help you to evaluate whether using clang is a good
- idea for your specific goals.
+ idea for your personal goals. Because we don't know specifically what
+ Please email cfe-dev if you think we should add another compiler to this
list or if you think some characterization is unfair here.
@@ -130,7 +134,10 @@
Elsa is not built as a stack of reusable libraries like clang is. It is
very difficult to use part of elsa without the whole front-end. For
example, you cannot use Elsa to parse C/ObjC code without building an
From sabre at nondot.org Mon Dec 10 01:14:09 2007
From: sabre at nondot.org (Chris Lattner)
Date: Mon, 10 Dec 2007 07:14:09 -0000
Subject: [cfe-commits] r44783 - in /cfe/trunk/www: content.css features.html
index.html menu.css
Message-ID: <200712100714.lBA7E9dW006545@zion.cs.uiuc.edu>
Author: lattner
Date: Mon Dec 10 01:14:08 2007
New Revision: 44783
URL: http://llvm.org/viewvc/llvm-project?rev=44783&view=rev
Log:
reorganize features, expound on a couple more.
Modified:
cfe/trunk/www/content.css
cfe/trunk/www/features.html
cfe/trunk/www/index.html
cfe/trunk/www/menu.css
Modified: cfe/trunk/www/content.css
URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/www/content.css?rev=44783&r1=44782&r2=44783&view=diff
==============================================================================
--- cfe/trunk/www/content.css (original)
+++ cfe/trunk/www/content.css Mon Dec 10 01:14:08 2007
@@ -1,8 +1,15 @@
html, body {
- margin:0px;
padding:0px;
}
+/* Slides */
+IMG.img_slide {
+ display: block;
+ margin-left: auto;
+ margin-right: auto
+}
+
+
/* FIXME: This is only for the status page */
table,tr,td {
border:.3ex solid black;
@@ -18,46 +25,7 @@
.code {
font:Courier,Arial;
}
-.quote {
- display: block;
- margin: 0 5em;
-}
-.key_point {
- color:rgb(200,0,0);
-}
.simple_list { /* simple lists that don't need to stand out */
margin-left:0;
}
-
-
-/* ****************** */
-/* Performance images */
-.img_container {
- display:inline;
- background-color:rgb(250,250,250);
- width:400px;
- vertical-align:top;
- margin:.1em;
-}
-[class=img_container] {
- display:inline-block;
-}
-.img_container img {
- display:block;
-}
-
-.img_title {
- display:block;
- font-weight:bold;
- color:rgb(20,50,150);
-}
-.img_desc .img-notes {
- display:block;
- padding:.3em;
-}
-.img_notes {
- font-style:italic;
- color:rgb(50,50,50);
- font-size:.9em;
-}
-/* ****************** */
\ No newline at end of file
+
Modified: cfe/trunk/www/features.html
URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/www/features.html?rev=44783&r1=44782&r2=44783&view=diff
==============================================================================
--- cfe/trunk/www/features.html (original)
+++ cfe/trunk/www/features.html Mon Dec 10 01:14:08 2007
@@ -22,15 +22,137 @@
These features are:
+End-User Features:
+
+
+
+Driving Goals and Internal Design:
+End-User Features
+
+
+
+
+
+
+
+A major focus of our work on clang is to make it fast, light and scalable.
+The library-based architecture of clang makes it straight-forward to time and
+profile the cost of each layer of the stack, and the driver has a number of
+options for performance analysis.
+
+While there is still much that can be done, we find that the clang front-end
+is significantly quicker than gcc and uses less memory For example, when
+compiling "Carbon.h" on Mac OS/X, we see that clang is 2.5x faster than GCC:
+
+
+
+Carbon.h is a monster: it transitively includes 558 files, 12.3M of code,
+declares 10000 functions, has 2000 struct definitions, 8000 fields, 20000 enum
+constants, etc (see slide 25+ of the clang
+talk for more information). It is also #include'd into almost every C file
+in a GUI app on the Mac, so its compile time is very important.
+
+From the slide above, you can see that we can measure the time to preprocess
+the file independently from the time to parse it, and independently from the
+time to build the ASTs for the code. GCC doesn't provide a way to measure the
+parser without AST building (it only provides -fsyntax-only). In our
+measurements, we find that clang's preprocessor is consistently 40% faster than
+GCCs, and the parser + AST builder is ~4x faster than GCC's. If you have
+sources that do not depend as heavily on the preprocessor (or if you
+use Precompiled Headers) you may see a much bigger speedup from clang.
+
+
+Compile time performance is important, but when using clang as an API, often
+memory use is even moreso: the less memory the code takes the more code you can
+fit into memory at a time (useful for whole program analysis tools, for
+example).
+
+
+
+Here we see a huge advantage of clang: its ASTs take 5x less memory
+than GCC's syntax trees, despite the fact that clang's ASTs capture far more
+source-level information than GCC's trees do. This feat is accomplished through
+the use of carefully designed APIs and efficient representations.
+
+In addition to being efficient when pitted head-to-head against GCC in batch
+mode, clang is built with a library based
+architecture that makes it relatively easy to adapt it and build new tools
+with it. This means that it is often possible to apply out-of-the-box thinking
+and novel techniques to improve compilation in various ways.
+
+
+
+This slide shows how the clang preprocessor can be used to make "distcc"
+parallelization 3x more scalable than when using the GCC preprocessor.
+"distcc" quickly bottlenecks on the preprocessor running on the central driver
+machine, so a fast preprocessor is very useful. Comparing the first two bars
+of each group shows how a ~40% faster preprocessor can reduce preprocessing time
+of these large C++ apps by about 40% (shocking!).
+
+The third bar on the slide is the interesting part: it shows how trivial
+caching of file system accesses across invocations of the preprocessor allows
+clang to reduce time spent in the kernel by 10x, making distcc over 3x more
+scalable. This is obviously just one simple hack, doing more interesting things
+(like caching tokens across preprocessed files) would yield another substantial
+speedup.
+
+The clean framework-based design of clang means that many things are possible
+that would be very difficult in other systems, for example incremental
+compilation, multithreading, intelligent caching, etc. We are only starting
+to tap the full potential of the clang design.
+
+
+
+
+
+
+Clang is designed to efficiently capture range information for expressions
+and statements, which allows it to emit very useful and detailed diagnostic
+information (e.g. warnings and errors) when a problem is detected.
+
+For example, this slide compares the diagnostics emitted by clang (top) to
+the diagnostics emitted by GCC (middle) for a simple example:
+
+
+
+As you can see, clang goes beyond tracking just column number information: it
+is able to highlight the subexpressions involved in a problem, making it much
+easier to understand the source of the problem in many cases. For example, in
+the first problem, it tells you why the operand is invalid (it
+requires a pointer) and what type it really is.
+
+In the second error, you can see how clang uses column number information to
+identify exactly which "+" out of the four on that line is causing the problem.
+Further, it highlights the subexpressions involved, which can be very useful
+when a complex subexpression that relies on tricky precedence rules.
+
+The example doesn't show it, but clang works very hard to retain typedef
+information, ensuring that diagnostics print the user types, not the fully
+expanded (and often huge) types. This is clearly important for C++ code (tell
+me about "std::string", not about "std::basic_string<char,
+std::char_traits<char>, std::allocator<char> >"!), but it is
+also very useful in C code in some cases as well (e.g. "__m128" vs
+"float __attribute__((__vector_size__(16)))").
+
+
+
+Driving Goals and Internal Design
+
+
+
@@ -88,11 +210,36 @@
C, C++'03, Objective-C 2, etc.
-Library based architecture
+
+
+
+GCC is currently the defacto-standard open source compiler today, and it
+routinely compiles a huge volume of code. GCC supports a huge number of
+extensions and features (many of which are undocumented) and a lot of
+code and header files depend on these features in order to build.
+
+While it would be nice to be able to ignore these extensions and focus on
+implementing the language standards to the letter, pragmatics force us to
+support the GCC extensions that see the most use. As mentioned above, all
+extensions are explicitly recognized as such and marked with extension
+diagnostics, which can be mapped to warnings, errors, or just ignored.
+
+
+
+
+
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,
-"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."
+
+
+"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."
+
Currently, the LLVM front-end is divided into the following libraries:
- libsupport - Basic support library, reused from LLVM.
@@ -110,41 +257,6 @@
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.
In the end, LLVM's library based design will provide developers with many more possibilities.
-
-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.
-
-
Memory:
-

-
This test was run using Mac OS X's Carbon.h header, which is 12.3MB spread across 558 files!
- 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.
-
-
-
-
Performance:
-

-
Even at this early stage, the C parser for Clang is able to achieve significantly better performance. Many optimizations are still possible of course.
-
-
-
-
Performance:
-

-
By using very trivial file-system caching, clang can significantly speed up preprocessing-bound applications like distcc.
(more details)
-
-
-
-
-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.
-
-
Clang vs GCC:
-

-
There are several things to take note of in this example:
-
- - The error messages from Clang are more detailed.
-
- Clang shows you exactly where the error is, plus the range it has a problem with.
-
-
-
Notes:The first results are from clang; the second results are from gcc.
-
Better Integration with IDEs
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.
Modified: cfe/trunk/www/index.html
URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/www/index.html?rev=44783&r1=44782&r2=44783&view=diff
==============================================================================
--- cfe/trunk/www/index.html (original)
+++ cfe/trunk/www/index.html Mon Dec 10 01:14:08 2007
@@ -48,9 +48,9 @@
Of course this is only a rough outline of the goals and features of
- Clang. To get a true sense of what the new LLVM front-end is all about,
- as well as why you might want to considering using it, see the Features section.
+ Clang. To get a true sense of what it is all about, see the Features section. The Features section breaks
+ each of these down and explains them in more detail.
Why?
@@ -58,7 +58,7 @@
The development of a new front-end was started out of a need -- a need
for a compiler that allows better diagnostics, better integration with
IDEs, a license that is compatible with commercial products, and a
- compiler that is easier to develop and maintain. All of these were
+ nimble compiler that is easy to develop and maintain. All of these were
motivations for starting work on a new front-end that could
meet these needs.
Modified: cfe/trunk/www/menu.css
URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/www/menu.css?rev=44783&r1=44782&r2=44783&view=diff
==============================================================================
--- cfe/trunk/www/menu.css (original)
+++ cfe/trunk/www/menu.css Mon Dec 10 01:14:08 2007
@@ -23,10 +23,6 @@
/* menu style */
/**************/
-#menu {
- padding-left: .3em;
-}
-
#menu .submenu {
padding-top:1em;
display:block;
From sabre at nondot.org Mon Dec 10 01:23:53 2007
From: sabre at nondot.org (Chris Lattner)
Date: Mon, 10 Dec 2007 07:23:53 -0000
Subject: [cfe-commits] r44784 - in /cfe/trunk/www: comparison.html
features.html
Message-ID: <200712100723.lBA7NrCQ007246@zion.cs.uiuc.edu>
Author: lattner
Date: Mon Dec 10 01:23:52 2007
New Revision: 44784
URL: http://llvm.org/viewvc/llvm-project?rev=44784&view=rev
Log:
now with hackability.
Modified:
cfe/trunk/www/comparison.html
cfe/trunk/www/features.html
Modified: cfe/trunk/www/comparison.html
URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/www/comparison.html?rev=44784&r1=44783&r2=44784&view=diff
==============================================================================
--- cfe/trunk/www/comparison.html (original)
+++ cfe/trunk/www/comparison.html Mon Dec 10 01:23:52 2007
@@ -60,7 +60,8 @@
Pro's of clang vs GCC:
- - The Clang ASTs and design are intended to be easily understandable to
+
- The Clang ASTs and design are intended to be easily understandable by
anyone who is familiar with the languages involved and who have a basic
understanding of how a compiler works. GCC has a very old codebase
which presents a steep learning curve to new developers.
Modified: cfe/trunk/www/features.html
URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/www/features.html?rev=44784&r1=44783&r2=44784&view=diff
==============================================================================
--- cfe/trunk/www/features.html (original)
+++ cfe/trunk/www/features.html Mon Dec 10 01:23:52 2007
@@ -27,16 +27,17 @@
Driving Goals and Internal Design:
@@ -147,6 +148,26 @@
also very useful in C code in some cases as well (e.g. "__m128" vs
"float __attribute__((__vector_size__(16)))").
+
+
+
+
+GCC is currently the defacto-standard open source compiler today, and it
+routinely compiles a huge volume of code. GCC supports a huge number of
+extensions and features (many of which are undocumented) and a lot of
+code and header files depend on these features in order to build.
+
+While it would be nice to be able to ignore these extensions and focus on
+implementing the language standards to the letter, pragmatics force us to
+support the GCC extensions that see the most use. Many users just want their
+code to compile, they don't care to argue about whether it is pedantically C99
+or not.
+
+As mentioned above, all
+extensions are explicitly recognized as such and marked with extension
+diagnostics, which can be mapped to warnings, errors, or just ignored.
+
+
Driving Goals and Internal Design
@@ -171,6 +192,23 @@
reality.
+
+
+
+Our goal is to make it possible for anyone with a basic understanding
+of compilers and working knowledge of the C/C++/ObjC languages to understand and
+extend the clang source base. A large part of this falls out of our decision to
+make the AST mirror the languages as closely as possible: you have your friendly
+if statement, for statement, parenthesis expression, structs, unions, etc, all
+represented in a simple and explicit way.
+
+In addition to a simple design, we work to make the source base approachable
+by commenting it well, including citations of the language standards where
+appropriate, and designing the code for simplicity. Beyond that, clang offers
+a set of AST dumpers, printers, and visualizers that make it easy to put code in
+and see how it is represented.
+
+
@@ -209,22 +247,6 @@
We also intend to support "dialects" of these languages, such as C89, K&R
C, C++'03, Objective-C 2, etc.
-
-
-
-
-GCC is currently the defacto-standard open source compiler today, and it
-routinely compiles a huge volume of code. GCC supports a huge number of
-extensions and features (many of which are undocumented) and a lot of
-code and header files depend on these features in order to build.
-
-While it would be nice to be able to ignore these extensions and focus on
-implementing the language standards to the letter, pragmatics force us to
-support the GCC extensions that see the most use. As mentioned above, all
-extensions are explicitly recognized as such and marked with extension
-diagnostics, which can be mapped to warnings, errors, or just ignored.
-
-
From sabre at nondot.org Mon Dec 10 02:12:50 2007
From: sabre at nondot.org (Chris Lattner)
Date: Mon, 10 Dec 2007 08:12:50 -0000
Subject: [cfe-commits] r44787 - in /cfe/trunk/www: content.css features.html
Message-ID: <200712100812.lBA8CodT012652@zion.cs.uiuc.edu>
Author: lattner
Date: Mon Dec 10 02:12:49 2007
New Revision: 44787
URL: http://llvm.org/viewvc/llvm-project?rev=44787&view=rev
Log:
finish the features description.
Modified:
cfe/trunk/www/content.css
cfe/trunk/www/features.html
Modified: cfe/trunk/www/content.css
URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/www/content.css?rev=44787&r1=44786&r2=44787&view=diff
==============================================================================
--- cfe/trunk/www/content.css (original)
+++ cfe/trunk/www/content.css Mon Dec 10 02:12:49 2007
@@ -17,11 +17,6 @@
padding:.4ex;
}
-.weak_txt {
- font-size:.9em;
- color:rgb(100,100,100);
-}
-
.code {
font:Courier,Arial;
}
Modified: cfe/trunk/www/features.html
URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/www/features.html?rev=44787&r1=44786&r2=44787&view=diff
==============================================================================
--- cfe/trunk/www/features.html (original)
+++ cfe/trunk/www/features.html Mon Dec 10 02:12:49 2007
@@ -15,7 +15,10 @@
+
Clang - Features and Goals
+
+
This page describes the features and goals of
Clang in more detail and gives a more broad explanation about what we mean.
@@ -25,12 +28,22 @@
End-User Features:
-
Driving Goals and Internal Design:
+
Utility and Applications:
+
+
+
+
Internal Design and Implementation:
+
-
+
End-User Features
-
+
@@ -169,10 +182,165 @@
+
+
Utility and Applications
+
+
+
+
+
+
+
A major design concept for clang is its use of a library-based
+architecture. In this design, 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 encourages good interfaces
+and makes it easier for new developers to get involved (because they only need
+to understand small pieces of the big picture).
+
+
+"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."
+
+
+Currently, clang is divided into the following libraries and tool:
+
+
+
+- libsupport - Basic support library, from LLVM.
+- libsystem - System abstraction library, from LLVM.
+- libbasic - Diagnostics, SourceLocations, SourceBuffer abstraction,
+ file system caching for input source files.
+- 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).
+- liblex - Lexing and preprocessing, identifier hash table, pragma
+ handling, tokens, and macro expansion.
+- libparse - Parsing. This library invokes coarse-grained 'Actions'
+ provided by the client (e.g. libsema builds ASTs) but knows nothing about
+ ASTs or other client-specific data structures.
+- libsema - Semantic Analysis. This provides a set of parser actions
+ to build a standardized AST for programs.
+- libcodegen - Lower the AST to LLVM IR for optimization & code
+ generation.
+- librewrite - Editing of text buffers (important for code rewriting
+ transformation, like refactoring).
+- libanalysis - Static analysis support.
+- clang - A driver program, client of the libraries at various
+ levels.
+
+
+
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.
+
+
For more information about the low-level implementation details of the
+various clang libraries, please see the
+clang Internals Manual.
+
+
+
+
+
+
Clang is designed and built with many grand plans for how we can use it. The
+driving force is the fact that we use C and C++ daily, and have to suffer due to
+a lack of good tools available for it. We believe that the C and C++ tools
+ecosystem has been significantly limited by how difficult it is to parse and
+represent the source code for these languages, and we aim to rectify this
+problem in clang.
+
+
The problem with this goal is that different clients have very different
+requirements. Consider code generation, for example: a simple front-end that
+parses for code generation must analyze the code for validity and emit code
+in some intermediate form to pass off to a optimizer or backend. Because
+validity analysis and code generation can largely be done on the fly, there is
+not hard requirement that the front-end actually build up a full AST for all
+the expressions and statements in the code. TCC and GCC are examples of
+compilers that either build no real AST (in the former case) or build a stripped
+down and simplified AST (in the later case) because they focus primarily on
+codegen.
+
+
On the opposite side of the spectrum, some clients (like refactoring) want
+highly detailed information about the original source code and want a complete
+AST to describe it with. Refactoring wants to have information about macro
+expansions, the location of every paren expression '(((x)))' vs 'x', full
+position information, and much more. Further, refactoring wants to look
+across the whole program to ensure that it is making transformations
+that are safe. Making this efficient and getting this right requires a
+significant amount of engineering and algorithmic work that simply are
+unnecessary for a simple static compiler.
+
+
The beauty of the clang approach is that it does not restrict how you use it.
+In particular, it is possible to use the clang preprocessor and parser to build
+an extremely quick and light-weight on-the-fly code generator (similar to TCC)
+that does not build an AST at all. As an intermediate step, clang supports
+using the current AST generation and semantic analysis code and having a code
+generation client free the AST for each function after code generation. Finally,
+clang provides support for building and retaining fully-fledged ASTs, and even
+supports writing them out to disk.
+
+
Designing the libraries with clean and simple APIs allows these high-level
+policy decisions to be determined in the client, instead of forcing "one true
+way" in the implementation of any of these libraries. Getting this right is
+hard, and we don't always get it right the first time, but we fix any problems
+when we realize we made a mistake.
+
+
+
+
+
+
+We believe that Integrated Development Environments (IDE's) are a great way
+to pull together various pieces of the development puzzle, and aim to make clang
+work well in such an environment. The chief advantage of an IDE is that they
+typically have visibility across your entire project and are long-lived
+processes, whereas stand-alone compiler tools are typically invoked on each
+individual file in the project, and thus have limited scope.
+
+
There are many implications of this difference, but a significant one has to
+do with efficiency and caching: sharing an address space across different files
+in a project, means that you can use intelligent caching and other techniques to
+dramatically reduce analysis/compilation time.
+
+
A further difference between IDEs and batch compiler is that they often
+impose very different requirements on the front-end: they depend on high
+performance in order to provide a "snappy" experience, and thus really want
+techniques like "incremental compilation", "fuzzy parsing", etc. Finally, 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.
+
+
+
-
Driving Goals and Internal Design
+
+
We actively indend for clang (and a LLVM as a whole) to be used for
+commercial projects, and the BSD license is the simplest way to allow this. We
+feel that the license encourages contributors to pick up the source and work
+with it, and believe that those individuals and organizations will contribute
+back their work if they do not want to have to maintain a fork forever (which is
+time consuming and expensive when merges are involved). Further, nobody makes
+money on compilers these days, but many people need them to get bigger goals
+accomplished: it makes sense for everyone to work together.
+
+
For more information about the LLVM/clang license, please see the LLVM License
+Description for more information.
+
+
+
+
+
Internal Design and Implementation
+
+
@@ -247,40 +415,6 @@
We also intend to support "dialects" of these languages, such as C89, K&R
C, C++'03, Objective-C 2, etc.
-
-
-
-
-
-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,
-
-
-"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."
-
-Currently, the LLVM front-end is divided into the following libraries:
-
-- libsupport - Basic support library, reused from LLVM.
-
- libsystem - System abstraction library, reused from LLVM.
-
- libbasic - Diagnostics, SourceLocations, SourceBuffer abstraction, file system caching for input source files. (depends on above libraries)
-
- 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). (depends on above libraries)
-
- liblex - C/C++/ObjC lexing and preprocessing, identifier hash table, pragma handling, tokens, and macros. (depends on above libraries)
-
- libparse - Parsing and local semantic analysis. This library invokes coarse-grained 'Actions' provided by the client to do stuff (e.g. libsema builds ASTs). (depends on above libraries)
-
- 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. (depends on libast and libparse)
-
- libcodegen - Lower the AST to LLVM IR for optimization & codegen. (depends on libast)
-
- librewrite - Editing of text buffers, depends on libast.
-- libanalysis - Static analysis support, depends on libast.
-- clang - An example driver, client of the libraries at various levels. (depends on above libraries, and LLVM VMCore)
-
-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.
-In the end, LLVM's library based design will provide developers with many more possibilities.
-
-
Better Integration with IDEs
-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.