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