Add a link to Bill's blog post.
[oota-llvm.git] / docs / ReleaseNotes.html
1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
2                       "http://www.w3.org/TR/html4/strict.dtd">
3 <html>
4 <head>
5   <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
6   <link rel="stylesheet" href="llvm.css" type="text/css">
7   <title>LLVM 3.0 Release Notes</title>
8 </head>
9 <body>
10
11 <h1>LLVM 3.0 Release Notes</h1>
12
13 <img align=right src="http://llvm.org/img/DragonSmall.png"
14     width="136" height="136" alt="LLVM Dragon Logo">
15
16 <ol>
17   <li><a href="#intro">Introduction</a></li>
18   <li><a href="#subproj">Sub-project Status Update</a></li>
19   <li><a href="#externalproj">External Projects Using LLVM 3.0</a></li>
20   <li><a href="#whatsnew">What's New in LLVM 3.0?</a></li>
21   <li><a href="GettingStarted.html">Installation Instructions</a></li>
22   <li><a href="#knownproblems">Known Problems</a></li>
23   <li><a href="#additionalinfo">Additional Information</a></li>
24 </ol>
25
26 <div class="doc_author">
27   <p>Written by the <a href="http://llvm.org/">LLVM Team</a></p>
28 </div>
29
30 <!--
31 <h1 style="color:red">These are in-progress notes for the upcoming LLVM 3.0
32 release.<br>
33 You may prefer the
34 <a href="http://llvm.org/releases/2.9/docs/ReleaseNotes.html">LLVM 2.9
35 Release Notes</a>.</h1>
36  -->
37
38 <!-- *********************************************************************** -->
39 <h2>
40   <a name="intro">Introduction</a>
41 </h2>
42 <!-- *********************************************************************** -->
43
44 <div>
45
46 <p>This document contains the release notes for the LLVM Compiler
47    Infrastructure, release 3.0.  Here we describe the status of LLVM, including
48    major improvements from the previous release, improvements in various
49    subprojects of LLVM, and some of the current users of the code.
50    All LLVM releases may be downloaded from
51    the <a href="http://llvm.org/releases/">LLVM releases web site</a>.</p>
52
53 <p>For more information about LLVM, including information about the latest
54    release, please check out the <a href="http://llvm.org/">main LLVM web
55    site</a>.  If you have questions or comments,
56    the <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVM
57    Developer's Mailing List</a> is a good place to send them.</p>
58
59 <p>Note that if you are reading this file from a Subversion checkout or the main
60    LLVM web page, this document applies to the <i>next</i> release, not the
61    current one.  To see the release notes for a specific release, please see the
62    <a href="http://llvm.org/releases/">releases page</a>.</p>
63
64 </div>
65
66
67 <!-- *********************************************************************** -->
68 <h2>
69   <a name="subproj">Sub-project Status Update</a>
70 </h2>
71 <!-- *********************************************************************** -->
72
73 <div>
74
75 <p>The LLVM 3.0 distribution currently consists of code from the core LLVM
76    repository (which roughly includes the LLVM optimizers, code generators and
77    supporting tools), and the Clang repository.  In
78    addition to this code, the LLVM Project includes other sub-projects that are
79    in development.  Here we include updates on these subprojects.</p>
80
81 <!--=========================================================================-->
82 <h3>
83 <a name="clang">Clang: C/C++/Objective-C Frontend Toolkit</a>
84 </h3>
85
86 <div>
87
88 <p><a href="http://clang.llvm.org/">Clang</a> is an LLVM front end for the C,
89    C++, and Objective-C languages. Clang aims to provide a better user
90    experience through expressive diagnostics, a high level of conformance to
91    language standards, fast compilation, and low memory use. Like LLVM, Clang
92    provides a modular, library-based architecture that makes it suitable for
93    creating or integrating with other development tools. Clang is considered a
94    production-quality compiler for C, Objective-C, C++ and Objective-C++ on x86
95    (32- and 64-bit), and for Darwin/ARM targets.</p>
96
97 <p>In the LLVM 3.0 time-frame, the Clang team has made many improvements:
98 <ul>
99   <li>Greatly improved support for building C++ applications, with greater
100       stability and better diagnostics.</li>
101
102   <li><a href="http://clang.llvm.org/cxx_status.html">Improved support</a> for
103       the <a href="http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50372">C++
104       2011</a> standard (aka "C++'0x"), including implementations of non-static data member
105       initializers, alias templates, delegating constructors, range-based
106       for loops, and implicitly-generated move constructors and move assignment
107       operators, among others.</li>
108
109   <li>Implemented support for some features of the upcoming C1x standard,
110       including static assertions and generic selections.</li>
111
112   <li>Better detection of include and linking paths for system headers and
113       libraries, especially for Linux distributions.</li>
114
115   <li>Several improvements to Objective-C support, including:
116
117     <ul>
118       <li><a href="http://clang.llvm.org/docs/AutomaticReferenceCounting.html">
119           Automatic Reference Counting</a> (ARC) and an improved memory model
120           cleanly separating object and C memory.</li>
121
122       <li>A migration tool for moving manual retain/release code to ARC</li>
123
124       <li>Better support for data hiding, allowing instance variables to be
125           declared in implementation contexts or class extensions</li>
126       <li>Weak linking support for Objective-C classes</li>
127       <li>Improved static type checking by inferring the return type of methods
128       such as +alloc and -init.</li>
129     </ul>
130
131     Some new Objective-C features require either the Mac OS X 10.7 / iOS 5
132     Objective-C runtime, or version 1.6 or later of the GNUstep Objective-C
133     runtime version.</li>
134
135   <li>Implemented a number of optimizations in <tt>libclang</tt>, the Clang C
136       interface, to improve the performance of code completion and the mapping
137       from source locations to abstract syntax tree nodes.</li>
138 </ul>
139 For more details about the changes to Clang since the 2.9 release, see the
140 <a href="http://clang.llvm.org/docs/ReleaseNotes.html">Clang release notes</a>
141 </p>
142
143
144 <p>If Clang rejects your code but another compiler accepts it, please take a
145    look at the <a href="http://clang.llvm.org/compatibility.html">language
146    compatibility</a> guide to make sure this is not intentional or a known
147    issue.</p>
148
149 </div>
150
151 <!--=========================================================================-->
152 <h3>
153 <a name="dragonegg">DragonEgg: GCC front-ends, LLVM back-end</a>
154 </h3>
155
156 <div>
157 <p><a href="http://dragonegg.llvm.org/">DragonEgg</a> is a
158    <a href="http://gcc.gnu.org/wiki/plugins">gcc plugin</a> that replaces GCC's
159    optimizers and code generators with LLVM's. It works with gcc-4.5 or gcc-4.6,
160    targets the x86-32 and x86-64 processor families, and has been successfully
161    used on the Darwin, FreeBSD, KFreeBSD, Linux and OpenBSD platforms.  It fully
162    supports Ada, C, C++ and Fortran.  It has partial support for Go, Java, Obj-C
163    and Obj-C++.</p>
164
165 <p>The 3.0 release has the following notable changes:</p>
166
167   <ul>
168   <li>GCC version 4.6 is now fully supported.</li>
169
170   <li>Patching and building GCC is no longer required: the plugin should work
171       with your system GCC (version 4.5 or 4.6; on Debian/Ubuntu systems the
172       gcc-4.5-plugin-dev or gcc-4.6-plugin-dev package is also needed).</li>
173
174   <li>The <tt>-fplugin-arg-dragonegg-enable-gcc-optzns</tt> option, which runs
175       GCC's optimizers as well as LLVM's, now works much better.  This is the
176       option to use if you want ultimate performance! It is still experimental
177       though: it may cause the plugin to crash.</li>
178
179   <li>The type and constant conversion logic has been almost entirely rewritten,
180       fixing a multitude of obscure bugs.</li>
181
182 </ul>
183
184 </div>
185
186 <!--=========================================================================-->
187 <h3>
188 <a name="compiler-rt">compiler-rt: Compiler Runtime Library</a>
189 </h3>
190
191 <div>
192
193 <p>The new LLVM <a href="http://compiler-rt.llvm.org/">compiler-rt project</a>
194    is a simple library that provides an implementation of the low-level
195    target-specific hooks required by code generation and other runtime
196    components.  For example, when compiling for a 32-bit target, converting a
197    double to a 64-bit unsigned integer is compiled into a runtime call to the
198    "__fixunsdfdi" function. The compiler-rt library provides highly optimized
199    implementations of this and other low-level routines (some are 3x faster than
200    the equivalent libgcc routines).</p>
201
202 <p>In the LLVM 3.0 timeframe, the target specific ARM code has converted to
203    "unified" assembly syntax, and several new functions have been added to the
204    library.</p>
205
206 </div>
207
208 <!--=========================================================================-->
209 <h3>
210 <a name="lldb">LLDB: Low Level Debugger</a>
211 </h3>
212
213 <div>
214
215 <p>LLDB is a ground-up implementation of a command line debugger, as well as a
216    debugger API that can be used from other applications.  LLDB makes use of the
217    Clang parser to provide high-fidelity expression parsing (particularly for
218    C++) and uses the LLVM JIT for target support.</p>
219
220 <p>LLDB has advanced by leaps and bounds in the 3.0 timeframe.  It is
221    dramatically more stable and useful, and includes both a
222    new <a href="http://lldb.llvm.org/tutorial.html">tutorial</a> and
223    a <a href="http://lldb.llvm.org/lldb-gdb.html">side-by-side comparison with
224    GDB</a>.</p>
225
226 </div>
227
228 <!--=========================================================================-->
229 <h3>
230 <a name="libc++">libc++: C++ Standard Library</a>
231 </h3>
232
233 <div>
234
235 <p>Like compiler_rt, libc++ is now <a href="DeveloperPolicy.html#license">dual
236    licensed</a> under the MIT and UIUC license, allowing it to be used more
237    permissively.</p>
238
239 <p>Libc++ has been ported to FreeBSD and imported into the base system.  It is
240    planned to be the default STL implementation for FreeBSD 10.</p>
241
242 </div>
243
244 <!--=========================================================================-->
245 <h3>
246 <a name="vmkit">VMKit</a>
247 </h3>
248
249 <div>
250
251   <p>The <a href="http://vmkit.llvm.org/">VMKit project</a> is an
252   implementation of a Java Virtual Machine (Java VM or JVM) that uses LLVM for
253   static and just-in-time compilation.
254
255   <p>In the LLVM 3.0 time-frame, VMKit has had significant improvements on both
256   runtime and startup performance:</p>
257
258   <ul>
259   <li>Precompilation: by compiling ahead of time a small subset of Java's core
260   library, the startup performance have been highly optimized to the point that
261   running a 'Hello World' program takes less than 30 milliseconds.</li>
262
263   <li>Customization: by customizing virtual methods for individual classes,
264   the VM can statically determine the target of a virtual call, and decide to
265   inline it.</li>
266
267   <li>Inlining: the VM does more inlining than it did before, by allowing more
268   bytecode instructions to be inlined, and thanks to customization. It also
269   inlines GC barriers, and object allocations.</li>
270
271   <li>New exception model: the generated code for a method that does not do
272   any try/catch is not penalized anymore by the eventuality of calling a
273   method that throws an exception. Instead, the method that throws the
274   exception jumps directly to the method that could catch it.</li>
275   </ul>
276
277 </div>
278
279
280 <!--=========================================================================-->
281 <h3>
282 <a name="LLBrowse">LLBrowse: IR Browser</a>
283 </h3>
284
285 <div>
286
287 <p><a href="http://llvm.org/svn/llvm-project/llbrowse/trunk/doc/LLBrowse.html">
288    LLBrowse</a> is an interactive viewer for LLVM modules. It can load any LLVM
289    module and displays its contents as an expandable tree view, facilitating an
290    easy way to inspect types, functions, global variables, or metadata nodes. It
291    is fully cross-platform, being based on the popular wxWidgets GUI
292    toolkit.</p>
293
294 </div>
295
296
297 <!--=========================================================================-->
298 <!--
299 <h3>
300 <a name="klee">KLEE: A Symbolic Execution Virtual Machine</a>
301 </h3>
302
303 <div>
304 <p>
305 <a href="http://klee.llvm.org/">KLEE</a> is a symbolic execution framework for
306 programs in LLVM bitcode form. KLEE tries to symbolically evaluate "all" paths
307 through the application and records state transitions that lead to fault
308 states. This allows it to construct testcases that lead to faults and can even
309 be used to verify some algorithms.
310 </p>
311
312 <p>UPDATE!</p>
313 </div>-->
314
315 </div>
316
317 <!-- *********************************************************************** -->
318 <h2>
319   <a name="externalproj">External Open Source Projects Using LLVM 3.0</a>
320 </h2>
321 <!-- *********************************************************************** -->
322
323 <div>
324
325 <p>An exciting aspect of LLVM is that it is used as an enabling technology for
326    a lot of other language and tools projects.  This section lists some of the
327    projects that have already been updated to work with LLVM 3.0.</p>
328
329 <!--=========================================================================-->
330 <h3>AddressSanitizer</h3>
331
332 <div>
333
334 <p><a href="http://code.google.com/p/address-sanitizer/">AddressSanitizer</a>
335    uses compiler instrumentation and a specialized malloc library to find C/C++
336    bugs such as use-after-free and out-of-bound accesses to heap, stack, and
337    globals. The key feature of the tool is speed: the average slowdown
338    introduced by AddressSanitizer is less than 2x.</p>
339
340 </div>
341
342 <!--=========================================================================-->
343 <h3>ClamAV</h3>
344
345 <div>
346
347 <p><a href="http://www.clamav.net">Clam AntiVirus</a> is an open source (GPL)
348    anti-virus toolkit for UNIX, designed especially for e-mail scanning on mail
349    gateways.</p>
350
351 <p>Since version 0.96 it
352    has <a href="http://vrt-sourcefire.blogspot.com/2010/09/introduction-to-clamavs-low-level.html">bytecode
353    signatures</a> that allow writing detections for complex malware.
354    It uses LLVM's JIT to speed up the execution of bytecode on X86, X86-64,
355    PPC32/64, falling back to its own interpreter otherwise.  The git version was
356    updated to work with LLVM 3.0.</p>
357
358 </div>
359
360 <!--=========================================================================-->
361 <h3>clang_complete for VIM</h3>
362
363 <div>
364
365 <p><a href="https://github.com/Rip-Rip/clang_complete">clang_complete</a> is a
366    VIM plugin, that provides accurate C/C++ autocompletion using the clang front
367    end. The development version of clang complete, can directly use libclang
368    which can maintain a cache to speed up auto completion.</p>
369
370 </div>
371
372 <!--=========================================================================-->
373 <h3>clReflect</h3>
374
375 <div>
376
377 <p><a href="https://bitbucket.org/dwilliamson/clreflect">clReflect</a> is a C++
378    parser that uses clang/LLVM to derive a light-weight reflection database
379    suitable for use in game development. It comes with a very simple runtime
380    library for loading and querying the database, requiring no external
381    dependencies (including CRT), and an additional utility library for object
382    management and serialisation.</p>
383
384 </div>
385
386 <!--=========================================================================-->
387 <h3>Cling C++ Interpreter</h3>
388
389 <div>
390
391 <p><a href="http://cern.ch/cling">Cling</a> is an interactive compiler interface
392   (aka C++ interpreter). It supports C++ and C, and uses LLVM's JIT and the
393   Clang parser. It has a prompt interface, runs source files, calls into shared
394    libraries, prints the value of expressions, even does runtime lookup of
395    identifiers (dynamic scopes). And it just behaves like one would expect from
396    an interpreter.</p>
397
398 </div>
399
400 <!--=========================================================================-->
401 <h3>Crack Programming Language</h3>
402
403 <div>
404
405 <p><a href="http://code.google.com/p/crack-language/">Crack</a> aims to provide
406    the ease of development of a scripting language with the performance of a
407    compiled language. The language derives concepts from C++, Java and Python,
408    incorporating object-oriented programming, operator overloading and strong
409    typing.</p>
410
411 </div>
412
413 <!--=========================================================================-->
414 <h3>Eero</h3>
415
416 <div>
417
418 <p><a href="http://eerolanguage.org/">Eero</a> is a fully
419    header-and-binary-compatible dialect of Objective-C 2.0, implemented with a
420    patched version of the Clang/LLVM compiler. It features a streamlined syntax,
421    Python-like indentation, and new operators, for improved readability and
422    reduced code clutter. It also has new features such as limited forms of
423    operator overloading and namespaces, and strict (type-and-operator-safe)
424    enumerations. It is inspired by languages such as Smalltalk, Python, and
425    Ruby.</p>
426
427 </div>
428
429 <!--=========================================================================-->
430 <h3>FAUST Real-Time Audio Signal Processing Language</h3>
431
432 <div>
433
434 <p><a href="http://faust.grame.fr/">FAUST</a> is a compiled language for
435   real-time audio signal processing. The name FAUST stands for Functional
436   AUdio STream. Its programming model combines two approaches: functional
437   programming and block diagram composition. In addition with the C, C++, Java
438   output formats, the Faust compiler can now generate LLVM bitcode, and works
439   with LLVM 2.7-3.0.
440   </p>
441
442 </div>
443
444 <!--=========================================================================-->
445 <h3>Glasgow Haskell Compiler (GHC)</h3>
446
447 <div>
448
449 <p>GHC is an open source, state-of-the-art programming suite for Haskell, a
450    standard lazy functional programming language. It includes an optimizing
451    static compiler generating good code for a variety of platforms, together
452    with an interactive system for convenient, quick development.</p>
453
454 <p>GHC 7.0 and onwards include an LLVM code generator, supporting LLVM 2.8 and
455    later. Since LLVM 2.9, GHC now includes experimental support for the ARM
456    platform with LLVM 3.0.</p>
457
458 </div>
459
460 <!--=========================================================================-->
461 <h3>gwXscript</h3>
462
463 <div>
464
465 <p><a href="http://botwars.tk/gwscript/">gwXscript</a> is an object oriented,
466    aspect oriented programming language which can create both executables (ELF,
467    EXE) and shared libraries (DLL, SO, DYNLIB). The compiler is implemented in
468    its own language and translates scripts into LLVM-IR which can be optimized
469    and translated into native code by the LLVM framework. Source code in
470    gwScript contains definitions that expand the namespaces. So you can build
471    your project and simply 'plug out' features by removing a file. The remaining
472    project does not leave scars since you directly separate concerns by the
473    'template' feature of gwX. It is also possible to add new features to a
474    project by just adding files and without editing the original project. This
475    language is used for example to create games or content management systems
476    that should be extendable.</p>
477
478 <p>gwXscript is strongly typed and offers comfort with its native types string,
479    hash and array. You can easily write new libraries in gwXscript or native
480    code. gwXscript is type safe and users should not be able to crash your
481    program or execute malicious code except code that is eating CPU time.</p>
482
483 </div>
484
485 <!--=========================================================================-->
486 <h3>include-what-you-use</h3>
487
488 <div>
489
490 <p><a href="http://code.google.com/p/include-what-you-use">include-what-you-use</a>
491    is a tool to ensure that a file directly <code>#include</code>s
492    all <code>.h</code> files that provide a symbol that the file uses. It also
493    removes superfluous <code>#include</code>s from source files.</p>
494
495 </div>
496
497 <!--=========================================================================-->
498 <h3>ispc: The Intel SPMD Program Compiler</h3>
499
500 <div>
501
502 <p><a href="http://ispc.github.com">ispc</a> is a compiler for "single program,
503    multiple data" (SPMD) programs. It compiles a C-based SPMD programming
504    language to run on the SIMD units of CPUs; it often delivers 5-6x speedups on
505    a single core of a CPU with an 8-wide SIMD unit compared to serial code,
506    while still providing a clean and easy-to-understand programming model.  For
507    an introduction to the language and its performance,
508    see <a href="http://ispc.github.com/example.html">the walkthrough</a> of a short
509    example program.  ispc is licensed under the BSD license.</p>
510
511 </div>
512
513 <!--=========================================================================-->
514 <h3>The Julia Programming Language</h3>
515
516 <div>
517
518 <p><a href="http://github.com/JuliaLang/julia">Julia</a> is a high-level,
519   high-performance dynamic language for technical
520   computing. It provides a sophisticated compiler, distributed parallel
521   execution, numerical accuracy, and an extensive mathematical function
522   library. The compiler uses type inference to generate fast code
523   without any type declarations, and uses LLVM's optimization passes and
524   JIT compiler. The language is designed around multiple dispatch,
525   giving programs a large degree of flexibility. It is ready for use on many
526   kinds of problems.</p>
527 </div>
528
529 <!--=========================================================================-->
530 <h3>LanguageKit and Pragmatic Smalltalk</h3>
531
532 <div>
533
534 <p><a href="http://etoileos.com/etoile/features/languagekit/">LanguageKit</a> is
535    a framework for implementing dynamic languages sharing an object model with
536    Objective-C. It provides static and JIT compilation using LLVM along with
537    its own interpreter. Pragmatic Smalltalk is a dialect of Smalltalk, built on
538    top of LanguageKit, that interfaces directly with Objective-C, sharing the
539    same object representation and message sending behaviour. These projects are
540    developed as part of the &Eacute;toil&eacute; desktop environment.</p>
541
542 </div>
543
544 <!--=========================================================================-->
545 <h3>LuaAV</h3>
546
547 <div>
548
549 <p><a href="http://lua-av.mat.ucsb.edu/blog/">LuaAV</a> is a real-time
550    audiovisual scripting environment based around the Lua language and a
551    collection of libraries for sound, graphics, and other media protocols. LuaAV
552    uses LLVM and Clang to JIT compile efficient user-defined audio synthesis
553    routines specified in a declarative syntax.</p>
554
555 </div>
556
557 <!--=========================================================================-->
558 <h3>Mono</h3>
559
560 <div>
561
562 <p>An open source, cross-platform implementation of C# and the CLR that is
563    binary compatible with Microsoft.NET. Has an optional, dynamically-loaded
564    LLVM code generation backend in Mini, the JIT compiler.</p>
565
566 <p>Note that we use a Git mirror of LLVM <a
567     href="https://github.com/mono/llvm">with some patches</a>.</p>
568
569 </div>
570
571 <!--=========================================================================-->
572 <h3>Polly</h3>
573
574 <div>
575
576 <p><a href="http://polly.grosser.es">Polly</a> is an advanced data-locality
577    optimizer and automatic parallelizer. It uses an advanced, mathematical
578    model to calculate detailed data dependency information which it uses to
579    optimize the loop structure of a program. Polly can speed up sequential code
580    by improving memory locality and consequently the cache use. Furthermore,
581    Polly is able to expose different kind of parallelism which it exploits by
582    introducing (basic) OpenMP and SIMD code. A mid-term goal of Polly is to
583    automatically create optimized GPU code.</p>
584
585 </div>
586
587 <!--=========================================================================-->
588 <h3>Portable OpenCL (pocl)</h3>
589
590 <div>
591
592 <p>Portable OpenCL is an open source implementation of the OpenCL standard which
593    can be easily adapted for new targets. One of the goals of the project is
594    improving performance portability of OpenCL programs, avoiding the need for
595    target-dependent manual optimizations. A "native" target is included, which
596    allows running OpenCL kernels on the host (CPU).</p>
597
598 </div>
599
600 <!--=========================================================================-->
601 <h3>Pure</h3>
602
603 <div>
604 <p><a href="http://pure-lang.googlecode.com/">Pure</a> is an
605   algebraic/functional programming language based on term rewriting. Programs
606   are collections of equations which are used to evaluate expressions in a
607   symbolic fashion. The interpreter uses LLVM as a backend to JIT-compile Pure
608   programs to fast native code. Pure offers dynamic typing, eager and lazy
609   evaluation, lexical closures, a hygienic macro system (also based on term
610   rewriting), built-in list and matrix support (including list and matrix
611   comprehensions) and an easy-to-use interface to C and other programming
612   languages (including the ability to load LLVM bitcode modules, and inline C,
613   C++, Fortran and Faust code in Pure programs if the corresponding LLVM-enabled
614   compilers are installed).</p>
615
616 <p>Pure version 0.48 has been tested and is known to work with LLVM 3.0
617   (and continues to work with older LLVM releases &gt;= 2.5).</p>
618
619 </div>
620
621 <!--=========================================================================-->
622 <h3>Renderscript</h3>
623
624 <div>
625
626 <p><a href="http://developer.android.com/guide/topics/renderscript/index.html">Renderscript</a>
627    is Android's advanced 3D graphics rendering and compute API. It provides a
628    portable C99-based language with extensions to facilitate common use cases
629    for enhancing graphics and thread level parallelism. The Renderscript
630    compiler frontend is based on Clang/LLVM. It emits a portable bitcode format
631    for the actual compiled script code, as well as reflects a Java interface for
632    developers to control the execution of the compiled bitcode. Executable
633    machine code is then generated from this bitcode by an LLVM backend on the
634    device. Renderscript is thus able to provide a mechanism by which Android
635    developers can improve performance of their applications while retaining
636    portability.</p>
637
638 </div>
639
640 <!--=========================================================================-->
641 <h3>SAFECode</h3>
642
643 <div>
644
645 <p><a href="http://safecode.cs.illinois.edu">SAFECode</a> is a memory safe C/C++
646    compiler built using LLVM.  It takes standard, unannotated C/C++ code,
647    analyzes the code to ensure that memory accesses and array indexing
648    operations are safe, and instruments the code with run-time checks when
649    safety cannot be proven statically.  SAFECode can be used as a debugging aid
650    (like Valgrind) to find and repair memory safety bugs.  It can also be used
651    to protect code from security attacks at run-time.</p>
652
653 </div>
654
655 <!--=========================================================================-->
656 <h3>The Stupid D Compiler (SDC)</h3>
657
658 <div>
659
660 <p><a href="https://github.com/bhelyer/SDC">The Stupid D Compiler</a> is a
661    project seeking to write a self-hosting compiler for the D programming
662    language without using the frontend of the reference compiler (DMD).</p>
663
664 </div>
665
666 <!--=========================================================================-->
667 <h3>TTA-based Co-design Environment (TCE)</h3>
668
669 <div>
670
671 <p>TCE is a toolset for designing application-specific processors (ASP) based on
672    the Transport triggered architecture (TTA). The toolset provides a complete
673    co-design flow from C/C++ programs down to synthesizable VHDL and parallel
674    program binaries. Processor customization points include the register files,
675    function units, supported operations, and the interconnection network.</p>
676
677 <p>TCE uses Clang and LLVM for C/C++ language support, target independent
678    optimizations and also for parts of code generation. It generates new
679    LLVM-based code generators "on the fly" for the designed TTA processors and
680    loads them in to the compiler backend as runtime libraries to avoid
681    per-target recompilation of larger parts of the compiler chain.</p>
682
683 </div>
684
685 <!--=========================================================================-->
686 <h3>Tart Programming Language</h3>
687
688 <div>
689
690 <p><a href="http://code.google.com/p/tart/">Tart</a> is a general-purpose,
691    strongly typed programming language designed for application
692    developers. Strongly inspired by Python and C#, Tart focuses on practical
693    solutions for the professional software developer, while avoiding the clutter
694    and boilerplate of legacy languages like Java and C++. Although Tart is still
695    in development, the current implementation supports many features expected of
696    a modern programming language, such as garbage collection, powerful
697    bidirectional type inference, a greatly simplified syntax for template
698    metaprogramming, closures and function literals, reflection, operator
699    overloading, explicit mutability and immutability, and much more. Tart is
700    flexible enough to accommodate a broad range of programming styles and
701    philosophies, while maintaining a strong commitment to simplicity, minimalism
702    and elegance in design.</p>
703
704 </div>
705
706 <!--=========================================================================-->
707 <h3>ThreadSanitizer</h3>
708
709 <div>
710
711 <p><a href="http://code.google.com/p/data-race-test/">ThreadSanitizer</a> is a
712    data race detector for (mostly) C and C++ code, available for Linux, Mac OS
713    and Windows. On different systems, we use binary instrumentation frameworks
714    (Valgrind and Pin) as frontends that generate the program events for the race
715    detection algorithm. On Linux, there's an option of using LLVM-based
716    compile-time instrumentation.</p>
717
718 </div>
719
720 </div>
721
722 <!-- *********************************************************************** -->
723 <h2>
724   <a name="whatsnew">What's New in LLVM 3.0?</a>
725 </h2>
726 <!-- *********************************************************************** -->
727
728 <div>
729
730 <p>This release includes a huge number of bug fixes, performance tweaks and
731    minor improvements.  Some of the major improvements and new features are
732    listed in this section.</p>
733
734 <!--=========================================================================-->
735 <h3>
736 <a name="majorfeatures">Major New Features</a>
737 </h3>
738
739 <div>
740
741   <!-- Features that need text if they're finished for 3.1:
742    ARM EHABI
743    combiner-aa?
744    strong phi elim
745    loop dependence analysis
746    CorrelatedValuePropagation
747    lib/Transforms/IPO/MergeFunctions.cpp => consider for 3.1.
748    Integrated assembler on by default for arm/thumb?
749
750    -->
751
752   <!-- Near dead:
753    Analysis/RegionInfo.h + Dom Frontiers
754    SparseBitVector: used in LiveVar.
755    llvm/lib/Archive - replace with lib object?
756    -->
757
758 <p>LLVM 3.0 includes several major changes and big features:</p>
759
760 <ul>
761 <li>llvm-gcc is no longer supported, and not included in the release.  We
762     recommend switching to <a
763        href="http://clang.llvm.org/">Clang</a> or <a
764        href="http://dragonegg.llvm.org/">DragonEgg</a>.</li>
765
766 <li>The linear scan register allocator has been replaced with a new "greedy"
767     register allocator, enabling live range splitting and many other
768     optimizations that lead to better code quality.  Please see its <a
769     href="http://blog.llvm.org/2011/09/greedy-register-allocation-in-llvm-30.html">blog post</a> or its talk at the <a
770       href="http://llvm.org/devmtg/2011-11/">Developer Meeting</a>
771     for more information.</li>
772 <li>LLVM IR now includes full support for <a href="Atomics.html">atomics
773     memory operations</a> intended to support the C++'11 and C'1x memory models.
774     This includes <a href="LangRef.html#memoryops">atomic load and store,
775     compare and exchange, and read/modify/write instructions</a> as well as a
776     full set of <a href="LangRef.html#ordering">memory ordering constraints</a>.
777     Please see the <a href="Atomics.html">Atomics Guide</a> for more
778     information.
779 </li>
780 <li>The LLVM IR exception handling representation has been redesigned and
781     reimplemented, making it more elegant, fixing a huge number of bugs, and
782     enabling inlining and other optimizations.  Please see its <a href=
783     "http://blog.llvm.org/2011/11/llvm-30-exception-handling-redesign.html">blog
784     post</a> and the <a href="ExceptionHandling.html">Exception Handling
785     documentation</a> for more information.</li>
786 <li>The LLVM IR Type system has been redesigned and reimplemented, making it
787     faster and solving some long-standing problems.
788     Please see its <a
789     href="http://blog.llvm.org/2011/11/llvm-30-type-system-rewrite.html">blog
790     post</a> for more information.</li>
791
792 <li>The MIPS backend has made major leaps in this release, going from an
793     experimental target to being virtually production quality and supporting a
794     wide variety of MIPS subtargets.  See the <a href="#MIPS">MIPS section</a>
795     below for more information.</li>
796
797 <li>The optimizer and code generator now supports gprof and gcov-style coverage
798     and profiling information, and includes a new llvm-cov tool (but also works
799     with gcov).  Clang exposes coverage and profiling through GCC-compatible
800     command line options.</li>
801 </ul>
802
803 </div>
804
805
806 <!--=========================================================================-->
807 <h3>
808 <a name="coreimprovements">LLVM IR and Core Improvements</a>
809 </h3>
810
811 <div>
812
813 <p>LLVM IR has several new features for better support of new targets and that
814    expose new optimization opportunities:</p>
815
816   <ul>
817   <li><a href="Atomics.html">Atomic memory accesses and memory ordering</a> are
818       now directly expressible in the IR.</li>
819   <li>A new <a href="LangRef.html#int_fma">llvm.fma intrinsic</a> directly
820     represents floating point multiply accumulate operations without an
821     intermediate rounding stage.</li>
822   <li>A new llvm.expect intrinsic (XXX not documented in langref) allows a
823      frontend to express expected control flow (and the __builtin_expect builtin
824     from GNU C).</li>
825   <li>The <a href="LangRef.html#int_prefetch">llvm.prefetch intrinsic</a> now
826     takes a 4th argument that specifies whether the prefetch happens from the
827     icache or dcache.</li>
828   <li>The new <a href="LangRef.html#uwtable">uwtable function attribute</a>
829     allows a frontend to control emission of unwind tables.</li>
830   <li>The new <a href="LangRef.html#fnattrs">nonlazybind function
831     attribute</a> allow optimization of Global Offset Table (GOT) accesses.</li>
832   <li>The new <a href="LangRef.html#returns_twice">returns_twice attribute</a>
833     allows better modeling of functions like setjmp.</li>
834   <li>The <a href="LangRef.html#datalayout">target datalayout</a> string can now
835     encode the natural alignment of the target's stack for better optimization.
836     </li>
837   </ul>
838 </div>
839
840 <!--=========================================================================-->
841 <h3>
842 <a name="optimizer">Optimizer Improvements</a>
843 </h3>
844
845 <div>
846
847 <p>In addition to many minor performance tweaks and bug fixes, this
848    release includes a few major enhancements and additions to the
849    optimizers:</p>
850
851 <ul>
852 <li>The pass manager now has an extension API that allows front-ends and plugins
853     to insert their own optimizations in the well-known places in the standard
854     pass optimization pipeline.</li>
855
856 <li>Information about <a href="BranchWeightMetadata.html">branch probability</a>
857     and basic block frequency is now available within LLVM, based on a
858     combination of static branch prediction heuristics and
859     <code>__builtin_expect</code> calls.  That information is currently used for
860     register spill placement and if-conversion, with additional optimizations
861     planned for future releases.  The same framework is intended for eventual
862     use with profile-guided optimization.</li>
863
864 <li>The "-indvars" induction variable simplification pass only modifies
865     induction variables when profitable. Sign and zero extension
866     elimination, linear function test replacement, loop unrolling, and
867     other simplifications that require induction variable analysis have
868     been generalized so they no longer require loops to be rewritten into
869     canonical form prior to optimization. This new design
870     preserves more IR level information, avoids undoing earlier loop
871     optimizations (particularly hand-optimized loops), and no longer
872     requires the code generator to reconstruct loops into an optimal form -
873     an intractable problem.</li>
874
875 <li>LLVM now includes a pass to optimize retain/release calls for the
876   <a href="http://clang.llvm.org/docs/AutomaticReferenceCounting.html">Automatic
877     Reference Counting</a> (ARC) Objective-C language feature (in
878     lib/Transforms/Scalar/ObjCARC.cpp).  It is a decent example of implementing
879     a source-language-specific optimization in LLVM.</li>
880
881 </ul>
882
883 </div>
884
885 <!--=========================================================================-->
886 <h3>
887 <a name="mc">MC Level Improvements</a>
888 </h3>
889
890 <div>
891
892 <p>The LLVM Machine Code (aka MC) subsystem was created to solve a number of
893    problems in the realm of assembly, disassembly, object file format handling,
894    and a number of other related areas that CPU instruction-set level tools work
895    in. For more information, please see
896   the <a href="http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html">Intro
897     to the LLVM MC Project Blog Post</a>.</p>
898
899 <ul>
900   <li>The MC layer has undergone significant refactoring to eliminate layering
901     violations that caused it to pull in the LLVM compiler backend code.</li>
902   <li>The ELF object file writers are much more full featured.</li>
903   <li>The integrated assembler now supports #line directives.</li>
904   <li>An early implementation of a JIT built on top of the MC framework (known
905       as MC-JIT) has been implemented and will eventually replace the old JIT.
906     It emits object files direct to memory and uses a runtime dynamic linker to
907     resolve references and drive lazy compilation.  The MC-JIT enables much
908     greater code reuse between the JIT and the static compiler and provides
909     better integration with the platform ABI as a result.
910   </li>
911   <li>The assembly printer now makes uses of assemblers instruction aliases
912     (InstAliases) to print simplified mneumonics when possible.</li>
913   <li>TableGen can now autogenerate MC expansion logic for pseudo
914     instructions that expand to multiple MC instructions (through the
915     PseudoInstExpansion class).</li>
916   <li>A new llvm-dwarfdump tool provides a start of a drop-in
917     replacement for the corresponding tool that use LLVM libraries.  As part of
918     this, LLVM has the beginnings of a dwarf parsing library.</li>
919   <li>llvm-objdump has more output including, symbol by symbol disassembly,
920       inline relocations, section headers, symbol tables, and section contents.
921       Support for archive files has also been added.</li>
922   <li>llvm-nm has gained support for archives of binary files.</li>
923   <li>llvm-size has been added. This tool prints out section sizes.</li>
924 </ul>
925
926 </div>
927
928 <!--=========================================================================-->
929 <h3>
930 <a name="codegen">Target Independent Code Generator Improvements</a>
931 </h3>
932
933 <div>
934
935 <p>We have put a significant amount of work into the code generator
936    infrastructure, which allows us to implement more aggressive algorithms and
937    make it run faster:</p>
938
939 <ul>
940 <li>LLVM can now produce code that works with libgcc
941     to <a href="SegmentedStacks.html">dynamically allocate stack
942     segments</a>, as opposed to allocating a worst-case chunk of
943     virtual memory for each thread.</li>
944 <li>LLVM generates substantially better code for indirect gotos due to a new
945     tail duplication pass, which can be a substantial performance win for
946     interpreter loops that use them.</li>
947 <li>Exception handling and debug frame information is now emitted with CFI
948     directives. This lets the assembler produce more compact info as it knows
949     the final offsets, yielding <a href="http://blog.mozilla.com/respindola/2011/05/12/cfi-directives/">much smaller executables</a> for some C++ applications.
950     If the system assembler doesn't support it, MC exands the directives when
951     the integrated assembler is not used.
952 </li>
953
954 <li>The code generator now supports vector "select" operations on vector
955     comparisons, turning them into various optimized code sequences (e.g.
956     using the SSE4/AVX "blend" instructions).</li>
957 <li>The SSE execution domain fix pass and the ARM NEON move fix pass have been
958     merged to a target independent execution dependency fix pass. This pass is
959     used to select alternative equivalent opcodes in a way that minimizes
960     execution domain crossings. Closely connected instructions are moved to
961     the same execution domain when possible. Targets can override the
962     <code>getExecutionDomain</code> and <code>setExecutionDomain</code> hooks
963     to use the pass.</li>
964 </ul>
965 </div>
966
967 <!--=========================================================================-->
968 <h3>
969 <a name="x86">X86-32 and X86-64 Target Improvements</a>
970 </h3>
971
972 <div>
973
974 <p>New features and major changes in the X86 target include:</p>
975
976 <ul>
977 <li>The X86 backend, assembler and disassembler now have full support for AVX 1.
978     To enable it pass <code>-mavx</code> to the compiler. AVX2 implementation is
979     underway on mainline.</li>
980 <li>The integrated assembler and disassembler now support a broad range of new
981     instructions including Atom, Ivy Bridge, <a
982     href="http://en.wikipedia.org/wiki/SSE4a">SSE4a/BMI</a> instructions, <a
983    href="http://en.wikipedia.org/wiki/RdRand">rdrand</a> and many others.</li>
984 <li>The X86 backend now fully supports the <a href="http://llvm.org/PR879">X87
985   floating point stack inline assembly constraints</a>.</li>
986 <li>The integrated assembler now supports the <tt>.code32</tt> and
987     <tt>.code64</tt> directives to switch between 32-bit and 64-bit
988     instructions.</li>
989 <li>The X86 backend now synthesizes horizontal add/sub instructions from generic
990     vector code when the appropriate instructions are enabled.</li>
991 <li>The X86-64 backend generates smaller and faster code at -O0 due to
992     improvements in fast instruction selection.</li>
993 <li><a href="http://code.google.com/p/nativeclient/">Native Client</a>
994     subtarget support has been added.</li>
995
996 <li>The CRC32 intrinsics have been renamed.  The intrinsics were previously
997     <code>@llvm.x86.sse42.crc32.[8|16|32]</code>
998     and <code>@llvm.x86.sse42.crc64.[8|64]</code>. They have been renamed to
999     <code>@llvm.x86.sse42.crc32.32.[8|16|32]</code> and
1000     <code>@llvm.x86.sse42.crc32.64.[8|64]</code>.</li>
1001 </ul>
1002
1003 </div>
1004
1005 <!--=========================================================================-->
1006 <h3>
1007 <a name="ARM">ARM Target Improvements</a>
1008 </h3>
1009
1010 <div>
1011
1012 <p>New features of the ARM target include:</p>
1013
1014 <ul>
1015 <li>The ARM backend generates much faster code for Cortex-A9 chips.</li>
1016 <li>The ARM backend has improved support for Cortex-M series processors.</li>
1017 <li>The ARM inline assembly constraints have been implemented and are now fully
1018     supported.</li>
1019 <li>NEON code produced by Clang often runs much faster due to improvements in
1020     the Scalar Replacement of Aggregates pass.</li>
1021 <li>The old ARM disassembler is replaced with a new one based on autogenerated
1022     encoding information from ARM .td files.</li>
1023 <li>The integrated assembler has made major leaps forward, but is still beta quality in LLVM 3.0.</li>
1024 </ul>
1025 </div>
1026
1027
1028 <!--=========================================================================-->
1029 <h3>
1030 <a name="MIPS">MIPS Target Improvements</a>
1031 </h3>
1032
1033 <div>
1034
1035 <p>This release has seen major new work on just about every aspect of the MIPS
1036   backend.  Some of the major new features include:</p>
1037
1038 <ul>
1039   <li>Most MIPS32r1 and r2 instructions are now supported.</li>
1040   <li>LE/BE MIPS32r1/r2 has been tested extensively.</li>
1041   <li>O32 ABI has been fully tested.</li>
1042   <li>MIPS backend has migrated to using the MC infrastructure for assembly printing. Initial support for direct object code emission has been implemented too.</li>
1043   <li>Delay slot filler has been updated. Now it tries to fill delay slots with useful instructions instead of always filling them with NOPs.</li>
1044   <li>Support for old-style JIT is complete.</li>
1045   <li>Support for old architectures (MIPS1 and MIPS2) has been removed.</li>
1046   <li>Initial support for MIPS64 has been added.</li>
1047 </ul>
1048 </div>
1049
1050 <!--=========================================================================-->
1051 <h3>
1052   <a name="PTX">PTX Target Improvements</a>
1053 </h3>
1054
1055 <div>
1056
1057   <p>
1058   The PTX back-end is still experimental, but is fairly usable for compute kernels
1059   in LLVM 3.0.  Most scalar arithmetic is implemented, as well as intrinsics to
1060   access the special PTX registers and sync instructions.  The major missing
1061   pieces are texture/sampler support and some vector operations.</p>
1062
1063   <p>That said, the backend is already being used for domain-specific languages
1064   and can be used by Clang to
1065   <a href="http://clang.llvm.org/docs/ReleaseNotes.html#opencl">compile OpenCL
1066   C code</a> into PTX.</p>
1067
1068 </div>
1069
1070 <!--=========================================================================-->
1071 <h3>
1072 <a name="OtherTS">Other Target Specific Improvements</a>
1073 </h3>
1074
1075 <div>
1076
1077 <ul>
1078 <li>Many PowerPC improvements have been implemented for ELF targets, including
1079    support for varargs and initial support for direct .o file emission.</li>
1080
1081 <li>MicroBlaze scheduling itineraries were added that model the
1082    3-stage and the 5-stage pipeline architectures. The 3-stage
1083    pipeline model can be selected with <code>-mcpu=mblaze3</code>
1084    and the 5-stage pipeline model can be selected with
1085    <code>-mcpu=mblaze5</code>.</li>
1086
1087 </ul>
1088
1089 </div>
1090
1091 <!--=========================================================================-->
1092 <h3>
1093 <a name="changes">Major Changes and Removed Features</a>
1094 </h3>
1095
1096 <div>
1097
1098 <p>If you're already an LLVM user or developer with out-of-tree changes based on
1099    LLVM 2.9, this section lists some "gotchas" that you may run into upgrading
1100    from the previous release.</p>
1101
1102 <ul>
1103 <li>LLVM 3.0 removes support for reading LLVM 2.8 and earlier files, and LLVM
1104     3.1 will eliminate support for reading LLVM 2.9 files.  Going forward, we
1105     aim for all future versions of LLVM to read bitcode files and .ll files
1106     produced by LLVM 3.0.</li>
1107 <li>Tablegen has been split into a library, allowing the clang tblgen pieces
1108     to now live in the clang tree.  The llvm version has been renamed to
1109     llvm-tblgen instead of tblgen.</li>
1110   <li>The <code>LLVMC</code> meta compiler driver was removed.</li>
1111   <li>The unused PostOrder Dominator Frontiers and LowerSetJmp passes were removed.</li>
1112
1113
1114   <li>The old <code>TailDup</code> pass was not used in the standard pipeline
1115       and was unable to update ssa form, so it has been removed.
1116   <li>The syntax of volatile loads and stores in IR has been changed to
1117       "<code>load volatile</code>"/"<code>store volatile</code>".  The old
1118       syntax ("<code>volatile load</code>"/"<code>volatile store</code>")
1119       is still accepted, but is now considered deprecated and will be removed in
1120       3.1.</li>
1121   <li>llvm-gcc's frontend tests have been removed from llvm/test/Frontend*, sunk
1122     into the clang and dragonegg testsuites.</li>
1123   <li>The old atomic intrinsics (<code>llvm.memory.barrier</code> and
1124       <code>llvm.atomic.*</code>) are now gone.  Please use the new atomic
1125       instructions, described in the <a href="Atomics.html">atomics guide</a>.
1126   <li>LLVM's configure script doesn't depend on llvm-gcc anymore, eliminating a
1127       strange circular dependence between projects.</li>
1128 </ul>
1129
1130 <h4>Windows (32-bit)</h4>
1131 <div>
1132
1133 <ul>
1134   <li>On Win32(MinGW32 and MSVC), Windows 2000 will not be supported.
1135       Windows XP or higher is required.</li>
1136 </ul>
1137
1138 </div>
1139
1140 </div>
1141
1142 <!--=========================================================================-->
1143 <h3>
1144 <a name="api_changes">Internal API Changes</a>
1145 </h3>
1146
1147 <div>
1148
1149 <p>In addition, many APIs have changed in this release.  Some of the major
1150    LLVM API changes are:</p>
1151
1152 <ul>
1153   <li>The biggest and most pervasive change is that the type system has been
1154       rewritten: <code>PATypeHolder</code> and <code>OpaqueType</code> are gone,
1155       and all APIs deal with <code>Type*</code> instead of <code>const
1156       Type*</code>.  If you need to create recursive structures, then create a
1157       named structure, and use <code>setBody()</code> when all its elements are
1158       built.  Type merging and refining is gone too: named structures are not
1159       merged with other structures, even if their layout is identical.  (of
1160       course anonymous structures are still uniqued by layout).</li>
1161
1162   <li><code>PHINode::reserveOperandSpace</code> has been removed. Instead, you
1163       must specify how many operands to reserve space for when you create the
1164       PHINode, by passing an extra argument
1165       into <code>PHINode::Create</code>.</li>
1166
1167   <li>PHINodes no longer store their incoming BasicBlocks as operands. Instead,
1168       the list of incoming BasicBlocks is stored separately, and can be accessed
1169       with new functions <code>PHINode::block_begin</code>
1170       and <code>PHINode::block_end</code>.</li>
1171
1172   <li>Various functions now take an <code>ArrayRef</code> instead of either a
1173       pair of pointers (or iterators) to the beginning and end of a range, or a
1174       pointer and a length. Others now return an <code>ArrayRef</code> instead
1175       of a reference to a <code>SmallVector</code>
1176       or <code>std::vector</code>. These include:
1177 <ul>
1178 <!-- Please keep this list sorted. -->
1179 <li><code>CallInst::Create</code></li>
1180 <li><code>ComputeLinearIndex</code> (in <code>llvm/CodeGen/Analysis.h</code>)</li>
1181 <li><code>ConstantArray::get</code></li>
1182 <li><code>ConstantExpr::getExtractElement</code></li>
1183 <li><code>ConstantExpr::getGetElementPtr</code></li>
1184 <li><code>ConstantExpr::getInBoundsGetElementPtr</code></li>
1185 <li><code>ConstantExpr::getIndices</code></li>
1186 <li><code>ConstantExpr::getInsertElement</code></li>
1187 <li><code>ConstantExpr::getWithOperands</code></li>
1188 <li><code>ConstantFoldCall</code> (in <code>llvm/Analysis/ConstantFolding.h</code>)</li>
1189 <li><code>ConstantFoldInstOperands</code> (in <code>llvm/Analysis/ConstantFolding.h</code>)</li>
1190 <li><code>ConstantVector::get</code></li>
1191 <li><code>DIBuilder::createComplexVariable</code></li>
1192 <li><code>DIBuilder::getOrCreateArray</code></li>
1193 <li><code>ExtractValueInst::Create</code></li>
1194 <li><code>ExtractValueInst::getIndexedType</code></li>
1195 <li><code>ExtractValueInst::getIndices</code></li>
1196 <li><code>FindInsertedValue</code> (in <code>llvm/Analysis/ValueTracking.h</code>)</li>
1197 <li><code>gep_type_begin</code> (in <code>llvm/Support/GetElementPtrTypeIterator.h</code>)</li>
1198 <li><code>gep_type_end</code> (in <code>llvm/Support/GetElementPtrTypeIterator.h</code>)</li>
1199 <li><code>GetElementPtrInst::Create</code></li>
1200 <li><code>GetElementPtrInst::CreateInBounds</code></li>
1201 <li><code>GetElementPtrInst::getIndexedType</code></li>
1202 <li><code>InsertValueInst::Create</code></li>
1203 <li><code>InsertValueInst::getIndices</code></li>
1204 <li><code>InvokeInst::Create</code></li>
1205 <li><code>IRBuilder::CreateCall</code></li>
1206 <li><code>IRBuilder::CreateExtractValue</code></li>
1207 <li><code>IRBuilder::CreateGEP</code></li>
1208 <li><code>IRBuilder::CreateInBoundsGEP</code></li>
1209 <li><code>IRBuilder::CreateInsertValue</code></li>
1210 <li><code>IRBuilder::CreateInvoke</code></li>
1211 <li><code>MDNode::get</code></li>
1212 <li><code>MDNode::getIfExists</code></li>
1213 <li><code>MDNode::getTemporary</code></li>
1214 <li><code>MDNode::getWhenValsUnresolved</code></li>
1215 <li><code>SimplifyGEPInst</code> (in <code>llvm/Analysis/InstructionSimplify.h</code>)</li>
1216 <li><code>TargetData::getIndexedOffset</code></li>
1217 </ul></li>
1218
1219   <li>All forms of <code>StringMap::getOrCreateValue</code> have been remove
1220       except for the one which takes a <code>StringRef</code>.</li>
1221
1222   <li>The <code>LLVMBuildUnwind</code> function from the C API was removed. The
1223       LLVM <code>unwind</code> instruction has been deprecated for a long time
1224       and isn't used by the current front-ends. So this was removed during the
1225       exception handling rewrite.</li>
1226
1227   <li>The <code>LLVMAddLowerSetJmpPass</code> function from the C API was
1228       removed because the <code>LowerSetJmp</code> pass was removed.</li>
1229
1230   <li>The <code>DIBuilder</code> interface used by front ends to encode
1231       debugging information in the LLVM IR now expects clients to
1232       use <code>DIBuilder::finalize()</code> at the end of translation unit to
1233       complete debugging information encoding.</li>
1234
1235   <li>TargetSelect.h moved to Support/ from Target/</li>
1236
1237   <li>UpgradeIntrinsicCall no longer upgrades pre-2.9 intrinsic calls (for
1238       example <code>llvm.memset.i32</code>).</li>
1239
1240   <li>It is mandatory to initialize all out-of-tree passes too and their dependencies now with
1241       <code>INITIALIZE_PASS{BEGIN,END,}</code>
1242       and <code>INITIALIZE_{PASS,AG}_DEPENDENCY</code>.</li>
1243
1244   <li>The interface for MemDepResult in MemoryDependenceAnalysis has been
1245       enhanced with new return types Unknown and NonFuncLocal, in addition to
1246       the existing types Clobber, Def, and NonLocal.</li>
1247 </ul>
1248
1249 </div>
1250
1251 </div>
1252
1253 <!-- *********************************************************************** -->
1254 <h2>
1255   <a name="knownproblems">Known Problems</a>
1256 </h2>
1257 <!-- *********************************************************************** -->
1258
1259 <div>
1260
1261 <p>LLVM is generally a production quality compiler, and is used by a broad range
1262    of applications and shipping in many products.  That said, not every
1263    subsystem is as mature as the aggregate, particularly the more obscure
1264    targets.  If you run into a problem, please check the <a
1265    href="http://llvm.org/bugs/">LLVM bug database</a> and submit a bug if
1266    there isn't already one or ask on the <a
1267     href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev
1268     list</a>.</p>
1269
1270   <p>Known problem areas include:</p>
1271
1272 <ul>
1273   <li>The Alpha, Blackfin, CellSPU, MSP430, PTX, SystemZ and
1274       XCore backends are experimental, and the Alpha, Blackfin and SystemZ
1275       targets have already been removed from mainline.</li>
1276
1277   <li>The integrated assembler, disassembler, and JIT is not supported by
1278       several targets.  If an integrated assembler is not supported, then a
1279       system assembler is required.  For more details, see the <a
1280       href="CodeGenerator.html#targetfeatures">Target Features Matrix</a>.
1281   </li>
1282
1283   <li>The C backend has numerous problems and is not being actively maintained.
1284     Depending on it for anything serious is not advised.</li>
1285 </ul>
1286
1287 </div>
1288
1289 </div>
1290
1291 <!-- *********************************************************************** -->
1292 <h2>
1293   <a name="additionalinfo">Additional Information</a>
1294 </h2>
1295 <!-- *********************************************************************** -->
1296
1297 <div>
1298
1299 <p>A wide variety of additional information is available on
1300    the <a href="http://llvm.org/">LLVM web page</a>, in particular in
1301    the <a href="http://llvm.org/docs/">documentation</a> section.  The web page
1302    also contains versions of the API documentation which is up-to-date with the
1303    Subversion version of the source code.  You can access versions of these
1304    documents specific to this release by going into the "<tt>llvm/doc/</tt>"
1305    directory in the LLVM tree.</p>
1306
1307 <p>If you have any questions or comments about LLVM, please feel free to contact
1308    us via the <a href="http://llvm.org/docs/#maillist"> mailing lists</a>.</p>
1309
1310 </div>
1311
1312 <!--=========================================================================-->
1313
1314 <!-- EH details: to be moved to a blog post:
1315
1316
1317
1318
1319 <p>One of the biggest changes is that 3.0 has a new exception handling
1320    system. The old system used LLVM intrinsics to convey the exception handling
1321    information to the code generator. It worked in most cases, but not
1322    all. Inlining was especially difficult to get right. Also, the intrinsics
1323    could be moved away from the <code>invoke</code> instruction, making it hard
1324    to recover that information.</p>
1325
1326 <p>The new EH system makes exception handling a first-class member of the IR. It
1327    adds two new instructions:</p>
1328
1329 <ul>
1330   <li><a href="LangRef.html#i_landingpad"><code>landingpad</code></a> &mdash;
1331       this instruction defines a landing pad basic block. It contains all of the
1332       information that's needed by the code generator. It's also required to be
1333       the first non-PHI instruction in the landing pad. In addition, a landing
1334       pad may be jumped to only by the unwind edge of an <code>invoke</code>
1335       instruction.</li>
1336
1337   <li><a href="LangRef.html#i_resume"><code>resume</code></a> &mdash; this
1338       instruction causes the current exception to resume traveling up the
1339       stack. It replaces the <code>@llvm.eh.resume</code> intrinsic.</li>
1340 </ul>
1341
1342 <p>Converting from the old EH API to the new EH API is rather simple, because a
1343    lot of complexity has been removed. The two intrinsics,
1344    <code>@llvm.eh.exception</code> and <code>@llvm.eh.selector</code> have been
1345    superseded by the <code>landingpad</code> instruction. Instead of generating
1346    a call to <code>@llvm.eh.exception</code> and <code>@llvm.eh.selector</code>:
1347
1348 <div class="doc_code">
1349 <pre>
1350 Function *ExcIntr = Intrinsic::getDeclaration(TheModule,
1351                                               Intrinsic::eh_exception);
1352 Function *SlctrIntr = Intrinsic::getDeclaration(TheModule,
1353                                                 Intrinsic::eh_selector);
1354
1355 // The exception pointer.
1356 Value *ExnPtr = Builder.CreateCall(ExcIntr, "exc_ptr");
1357
1358 std::vector&lt;Value*&gt; Args;
1359 Args.push_back(ExnPtr);
1360 Args.push_back(Builder.CreateBitCast(Personality,
1361                                      Type::getInt8PtrTy(Context)));
1362
1363 <i>// Add selector clauses to Args.</i>
1364
1365 // The selector call.
1366 Builder.CreateCall(SlctrIntr, Args, "exc_sel");
1367 </pre>
1368 </div>
1369
1370 <p>You should instead generate a <code>landingpad</code> instruction, that
1371    returns an exception object and selector value:</p>
1372
1373 <div class="doc_code">
1374 <pre>
1375 LandingPadInst *LPadInst =
1376   Builder.CreateLandingPad(StructType::get(Int8PtrTy, Int32Ty, NULL),
1377                            Personality, 0);
1378
1379 Value *LPadExn = Builder.CreateExtractValue(LPadInst, 0);
1380 Builder.CreateStore(LPadExn, getExceptionSlot());
1381
1382 Value *LPadSel = Builder.CreateExtractValue(LPadInst, 1);
1383 Builder.CreateStore(LPadSel, getEHSelectorSlot());
1384 </pre>
1385 </div>
1386
1387 <p>It's now trivial to add the individual clauses to the <code>landingpad</code>
1388    instruction.</p>
1389
1390 <div class="doc_code">
1391 <pre>
1392 <i><b>// Adding a catch clause</b></i>
1393 Constant *TypeInfo = getTypeInfo();
1394 LPadInst-&gt;addClause(TypeInfo);
1395
1396 <i><b>// Adding a C++ catch-all</b></i>
1397 LPadInst-&gt;addClause(Constant::getNullValue(Builder.getInt8PtrTy()));
1398
1399 <i><b>// Adding a cleanup</b></i>
1400 LPadInst-&gt;setCleanup(true);
1401
1402 <i><b>// Adding a filter clause</b></i>
1403 std::vector&lt;Constant*&gt; TypeInfos;
1404 Constant *TypeInfo = getFilterTypeInfo();
1405 TypeInfos.push_back(Builder.CreateBitCast(TypeInfo, Builder.getInt8PtrTy()));
1406
1407 ArrayType *FilterTy = ArrayType::get(Int8PtrTy, TypeInfos.size());
1408 LPadInst-&gt;addClause(ConstantArray::get(FilterTy, TypeInfos));
1409 </pre>
1410 </div>
1411
1412 <p>Converting from using the <code>@llvm.eh.resume</code> intrinsic to
1413    the <code>resume</code> instruction is trivial. It takes the exception
1414    pointer and exception selector values returned by
1415    the <code>landingpad</code> instruction:</p>
1416
1417 <div class="doc_code">
1418 <pre>
1419 Type *UnwindDataTy = StructType::get(Builder.getInt8PtrTy(),
1420                                      Builder.getInt32Ty(), NULL);
1421 Value *UnwindData = UndefValue::get(UnwindDataTy);
1422 Value *ExcPtr = Builder.CreateLoad(getExceptionObjSlot());
1423 Value *ExcSel = Builder.CreateLoad(getExceptionSelSlot());
1424 UnwindData = Builder.CreateInsertValue(UnwindData, ExcPtr, 0, "exc_ptr");
1425 UnwindData = Builder.CreateInsertValue(UnwindData, ExcSel, 1, "exc_sel");
1426 Builder.CreateResume(UnwindData);
1427 </pre>
1428 </div>
1429
1430
1431
1432
1433  -->
1434
1435
1436 <!-- *********************************************************************** -->
1437
1438 <hr>
1439 <address>
1440   <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
1441   src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
1442   <a href="http://validator.w3.org/check/referer"><img
1443   src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
1444
1445   <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br>
1446   Last modified: $Date$
1447 </address>
1448
1449 </body>
1450 </html>