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