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>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</a> 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 </div>
 644
 645 <!-- *********************************************************************** -->
 646 <h2>
 647   <a name="whatsnew">What's New in LLVM 3.0?</a>
 648 </h2>
 649 <!-- *********************************************************************** -->
 650
 651 <div>
 652
 653 <p>This release includes a huge number of bug fixes, performance tweaks and
 654    minor improvements.  Some of the major improvements and new features are
 655    listed in this section.</p>
 656
 657 <!--=========================================================================-->
 658 <h3>
 659 <a name="majorfeatures">Major New Features</a>
 660 </h3>
 661
 662 <div>
 663
 664 <p><b>llvm-gcc is gone</b></p>
 665
 666 <p>LLVM 3.0 includes several major new capabilities:</p>
 667
 668 <ul>
 669
 670 <!--
 671 <li></li>
 672 -->
 673
 674 </ul>
 675
 676 </div>
 677
 678 <!--=========================================================================-->
 679 <h3>
 680 <a name="coreimprovements">LLVM IR and Core Improvements</a>
 681 </h3>
 682
 683 <div>
 684
 685 <p>LLVM IR has several new features for better support of new targets and that
 686    expose new optimization opportunities:</p>
 687
 688 <p>One of the biggest changes is that 3.0 has a new exception handling
 689    system. The old system used LLVM intrinsics to convey the exception handling
 690    information to the code generator. It worked in most cases, but not
 691    all. Inlining was especially difficult to get right. Also, the intrinsics
 692    could be moved away from the <code>invoke</code> instruction, making it hard
 693    to recover that information.</p>
 694
 695 <p>The new EH system makes exception handling a first-class member of the IR. It
 696    adds two new instructions:</p>
 697
 698 <ul>
 699   <li><a href="LangRef.html#i_landingpad"><code>landingpad</code></a> &mdash;
 700       this instruction defines a landing pad basic block. It contains all of the
 701       information that's needed by the code generator. It's also required to be
 702       the first non-PHI instruction in the landing pad. In addition, a landing
 703       pad may be jumped to only by the unwind edge of an <code>invoke</code>
 704       instruction.</li>
 705
 706   <li><a href="LangRef.html#i_resume"><code>resume</code></a> &mdash; this
 707       instruction causes the current exception to resume traveling up the
 708       stack. It replaces the <code>@llvm.eh.resume</code> intrinsic.</li>
 709 </ul>
 710
 711 <p>Converting from the old EH API to the new EH API is rather simple, because a
 712    lot of complexity has been removed. The two intrinsics,
 713    <code>@llvm.eh.exception</code> and <code>@llvm.eh.selector</code> have been
 714    superceded by the <code>landingpad</code> instruction. Instead of generating
 715    a call to <code>@llvm.eh.exception</code> and <code>@llvm.eh.selector</code>:
 716
 717 <div class="doc_code">
 718 <pre>
 719 Function *ExcIntr = Intrinsic::getDeclaration(TheModule,
 720                                               Intrinsic::eh_exception);
 721 Function *SlctrIntr = Intrinsic::getDeclaration(TheModule,
 722                                                 Intrinsic::eh_selector);
 723
 724 // The exception pointer.
 725 Value *ExnPtr = Builder.CreateCall(ExcIntr, "exc_ptr");
 726
 727 std::vector&lt;Value*&gt; Args;
 728 Args.push_back(ExnPtr);
 729 Args.push_back(Builder.CreateBitCast(Personality,
 730                                      Type::getInt8PtrTy(Context)));
 731
 732 <i>// Add selector clauses to Args.</i>
 733
 734 // The selector call.
 735 Builder.CreateCall(SlctrIntr, Args, "exc_sel");
 736 </pre>
 737 </div>
 738
 739 <p>You should instead generate a <code>landingpad</code> instruction, that
 740    returns an exception object and selector value:</p>
 741
 742 <div class="doc_code">
 743 <pre>
 744 LandingPadInst *LPadInst =
 745   Builder.CreateLandingPad(StructType::get(Int8PtrTy, Int32Ty, NULL),
 746                            Personality, 0);
 747
 748 Value *LPadExn = Builder.CreateExtractValue(LPadInst, 0);
 749 Builder.CreateStore(LPadExn, getExceptionSlot());
 750
 751 Value *LPadSel = Builder.CreateExtractValue(LPadInst, 1);
 752 Builder.CreateStore(LPadSel, getEHSelectorSlot());
 753 </pre>
 754 </div>
 755
 756 <p>It's now trivial to add the individual clauses to the <code>landingpad</code>
 757    instruction.</p>
 758
 759 <div class="doc_code">
 760 <pre>
 761 <i><b>// Adding a catch clause</b></i>
 762 Constant *TypeInfo = getTypeInfo();
 763 LPadInst-&gt;addClause(TypeInfo);
 764
 765 <i><b>// Adding a C++ catch-all</b></i>
 766 LPadInst-&gt;addClause(Constant::getNullValue(Builder.getInt8PtrTy()));
 767
 768 <i><b>// Adding a cleanup</b></i>
 769 LPadInst-&gt;setCleanup(true);
 770
 771 <i><b>// Adding a filter clause</b></i>
 772 std::vector&lt;Constant*&gt; TypeInfos;
 773 Constant *TypeInfo = getFilterTypeInfo();
 774 TypeInfos.push_back(Builder.CreateBitCast(TypeInfo, Builder.getInt8PtrTy()));
 775
 776 ArrayType *FilterTy = ArrayType::get(Int8PtrTy, TypeInfos.size());
 777 LPadInst-&gt;addClause(ConstantArray::get(FilterTy, TypeInfos));
 778 </pre>
 779 </div>
 780
 781 <p>Converting from using the <code>@llvm.eh.resume</code> intrinsic to
 782    the <code>resume</code> instruction is trivial. It takes the exception
 783    pointer and exception selector values returned by
 784    the <code>landingpad</code> instruction:</p>
 785
 786 <div class="doc_code">
 787 <pre>
 788 Type *UnwindDataTy = StructType::get(Builder.getInt8PtrTy(),
 789                                      Builder.getInt32Ty(), NULL);
 790 Value *UnwindData = UndefValue::get(UnwindDataTy);
 791 Value *ExcPtr = Builder.CreateLoad(getExceptionObjSlot());
 792 Value *ExcSel = Builder.CreateLoad(getExceptionSelSlot());
 793 UnwindData = Builder.CreateInsertValue(UnwindData, ExcPtr, 0, "exc_ptr");
 794 UnwindData = Builder.CreateInsertValue(UnwindData, ExcSel, 1, "exc_sel");
 795 Builder.CreateResume(UnwindData);
 796 </pre>
 797 </div>
 798
 799 </div>
 800
 801 <!--=========================================================================-->
 802 <h3>
 803 <a name="loopoptimization">Loop Optimization Improvements</a>
 804 </h3>
 805
 806 <div>
 807 <p>The induction variable simplification pass in 3.0 only modifies
 808    induction variables when profitable. Sign and zero extension
 809    elimination, linear function test replacement, loop unrolling, and
 810    other simplifications that require induction variable analysis have
 811    been generalized so they no longer require loops to be rewritten in a
 812    typically suboptimal form prior to optimization. This new design
 813    preserves more IR level information, avoids undoing earlier loop
 814    optimizations (particularly hand-optimized loops), and no longer
 815    strongly depends on the code generator rewriting loops a second time
 816    in a now optimal form--an intractable problem.</p>
 817
 818 <p>The original behavior can be restored with -mllvm -enable-iv-rewrite;
 819    however, support for this mode will be short lived. As such, bug
 820    reports should be filed for any significant performance regressions
 821    when moving from -mllvm -enable-iv-rewrite to the 3.0 default mode.</p>
 822 </div>
 823
 824 <!--=========================================================================-->
 825 <h3>
 826 <a name="optimizer">Optimizer Improvements</a>
 827 </h3>
 828
 829 <div>
 830
 831 <p>In addition to a large array of minor performance tweaks and bug fixes, this
 832    release includes a few major enhancements and additions to the
 833    optimizers:</p>
 834
 835 <ul>
 836 <!--
 837 <li></li>
 838 -->
 839 </li>
 840
 841 </ul>
 842
 843 </div>
 844
 845 <!--=========================================================================-->
 846 <h3>
 847 <a name="mc">MC Level Improvements</a>
 848 </h3>
 849
 850 <div>
 851
 852 <p>The LLVM Machine Code (aka MC) subsystem was created to solve a number of
 853    problems in the realm of assembly, disassembly, object file format handling,
 854    and a number of other related areas that CPU instruction-set level tools work
 855    in.</p>
 856
 857 <ul>
 858 <!--
 859 <li></li>
 860 -->
 861 </ul>
 862
 863 <p>For more information, please see
 864    the <a href="http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html">Intro
 865    to the LLVM MC Project Blog Post</a>.</p>
 866
 867 </div>
 868
 869 <!--=========================================================================-->
 870 <h3>
 871 <a name="codegen">Target Independent Code Generator Improvements</a>
 872 </h3>
 873
 874 <div>
 875
 876 <p>We have put a significant amount of work into the code generator
 877    infrastructure, which allows us to implement more aggressive algorithms and
 878    make it run faster:</p>
 879
 880 <ul>
 881 <!--
 882 <li></li>
 883 -->
 884 </ul>
 885 </div>
 886
 887 <!--=========================================================================-->
 888 <h3>
 889 <a name="x86">X86-32 and X86-64 Target Improvements</a>
 890 </h3>
 891
 892 <div>
 893
 894 <p>New features and major changes in the X86 target include:</p>
 895
 896 <ul>
 897
 898   <li>The CRC32 intrinsics have been renamed.  The intrinsics were previously
 899       <code>@llvm.x86.sse42.crc32.[8|16|32]</code>
 900       and <code>@llvm.x86.sse42.crc64.[8|64]</code>. They have been renamed to
 901       <code>@llvm.x86.sse42.crc32.32.[8|16|32]</code> and
 902       <code>@llvm.x86.sse42.crc32.64.[8|64]</code>.</li>
 903
 904 </ul>
 905
 906 </div>
 907
 908 <!--=========================================================================-->
 909 <h3>
 910 <a name="ARM">ARM Target Improvements</a>
 911 </h3>
 912
 913 <div>
 914
 915 <p>New features of the ARM target include:</p>
 916
 917 <ul>
 918 <!--
 919 <li></li>
 920 -->
 921 </ul>
 922 </div>
 923
 924 <!--=========================================================================-->
 925 <h3>
 926 <a name="OtherTS">Other Target Specific Improvements</a>
 927 </h3>
 928
 929 <div>
 930
 931   <p>PPC32/ELF va_arg was implemented.</p>
 932   <p>PPC32 initial support for .o file writing was implemented.</p>
 933
 934 <ul>
 935 <!--
 936 <li></li>
 937 -->
 938 </ul>
 939
 940 </div>
 941
 942 <!--=========================================================================-->
 943 <h3>
 944 <a name="changes">Major Changes and Removed Features</a>
 945 </h3>
 946
 947 <div>
 948
 949 <p>If you're already an LLVM user or developer with out-of-tree changes based on
 950    LLVM 2.9, this section lists some "gotchas" that you may run into upgrading
 951    from the previous release.</p>
 952
 953 <ul>
 954   <li>The <code>LLVMC</code> front end code was removed while separating
 955       out language independence.</li>
 956   <li>The <code>LowerSetJmp</code> pass wasn't used effectively by any
 957       target and has been removed.</li>
 958   <li>The old <code>TailDup</code> pass was not used in the standard pipeline
 959       and was unable to update ssa form, so it has been removed.
 960   <li>The syntax of volatile loads and stores in IR has been changed to
 961       "<code>load volatile</code>"/"<code>store volatile</code>".  The old
 962       syntax ("<code>volatile load</code>"/"<code>volatile store</code>")
 963       is still accepted, but is now considered deprecated.</li>
 964   <li>The old atomic intrinscs (<code>llvm.memory.barrier</code> and
 965       <code>llvm.atomic.*</code>) are now gone.  Please use the new atomic
 966       instructions, described in the <a href="Atomics.html">atomics guide</a>.
 967 </ul>
 968
 969 <h4>Windows (32-bit)</h4>
 970 <div>
 971
 972 <ul>
 973   <li>On Win32(MinGW32 and MSVC), Windows 2000 will not be supported.
 974       Windows XP or higher is required.</li>
 975 </ul>
 976
 977 </div>
 978
 979 </div>
 980
 981 <!--=========================================================================-->
 982 <h3>
 983 <a name="api_changes">Internal API Changes</a>
 984 </h3>
 985
 986 <div>
 987
 988 <p>In addition, many APIs have changed in this release.  Some of the major
 989    LLVM API changes are:</p>
 990
 991 <ul>
 992   <li>The biggest and most pervasive change is that llvm::Type's are no longer
 993       returned or accepted as 'const' values.  Instead, just pass around
 994       non-const Type's.</li>
 995
 996   <li><code>PHINode::reserveOperandSpace</code> has been removed. Instead, you
 997       must specify how many operands to reserve space for when you create the
 998       PHINode, by passing an extra argument
 999       into <code>PHINode::Create</code>.</li>
1000
1001   <li>PHINodes no longer store their incoming BasicBlocks as operands. Instead,
1002       the list of incoming BasicBlocks is stored separately, and can be accessed
1003       with new functions <code>PHINode::block_begin</code>
1004       and <code>PHINode::block_end</code>.</li>
1005
1006   <li>Various functions now take an <code>ArrayRef</code> instead of either a
1007       pair of pointers (or iterators) to the beginning and end of a range, or a
1008       pointer and a length. Others now return an <code>ArrayRef</code> instead
1009       of a reference to a <code>SmallVector</code>
1010       or <code>std::vector</code>. These include:
1011 <ul>
1012 <!-- Please keep this list sorted. -->
1013 <li><code>CallInst::Create</code></li>
1014 <li><code>ComputeLinearIndex</code> (in <code>llvm/CodeGen/Analysis.h</code>)</li>
1015 <li><code>ConstantArray::get</code></li>
1016 <li><code>ConstantExpr::getExtractElement</code></li>
1017 <li><code>ConstantExpr::getGetElementPtr</code></li>
1018 <li><code>ConstantExpr::getInBoundsGetElementPtr</code></li>
1019 <li><code>ConstantExpr::getIndices</code></li>
1020 <li><code>ConstantExpr::getInsertElement</code></li>
1021 <li><code>ConstantExpr::getWithOperands</code></li>
1022 <li><code>ConstantFoldCall</code> (in <code>llvm/Analysis/ConstantFolding.h</code>)</li>
1023 <li><code>ConstantFoldInstOperands</code> (in <code>llvm/Analysis/ConstantFolding.h</code>)</li>
1024 <li><code>ConstantVector::get</code></li>
1025 <li><code>DIBuilder::createComplexVariable</code></li>
1026 <li><code>DIBuilder::getOrCreateArray</code></li>
1027 <li><code>ExtractValueInst::Create</code></li>
1028 <li><code>ExtractValueInst::getIndexedType</code></li>
1029 <li><code>ExtractValueInst::getIndices</code></li>
1030 <li><code>FindInsertedValue</code> (in <code>llvm/Analysis/ValueTracking.h</code>)</li>
1031 <li><code>gep_type_begin</code> (in <code>llvm/Support/GetElementPtrTypeIterator.h</code>)</li>
1032 <li><code>gep_type_end</code> (in <code>llvm/Support/GetElementPtrTypeIterator.h</code>)</li>
1033 <li><code>GetElementPtrInst::Create</code></li>
1034 <li><code>GetElementPtrInst::CreateInBounds</code></li>
1035 <li><code>GetElementPtrInst::getIndexedType</code></li>
1036 <li><code>InsertValueInst::Create</code></li>
1037 <li><code>InsertValueInst::getIndices</code></li>
1038 <li><code>InvokeInst::Create</code></li>
1039 <li><code>IRBuilder::CreateCall</code></li>
1040 <li><code>IRBuilder::CreateExtractValue</code></li>
1041 <li><code>IRBuilder::CreateGEP</code></li>
1042 <li><code>IRBuilder::CreateInBoundsGEP</code></li>
1043 <li><code>IRBuilder::CreateInsertValue</code></li>
1044 <li><code>IRBuilder::CreateInvoke</code></li>
1045 <li><code>MDNode::get</code></li>
1046 <li><code>MDNode::getIfExists</code></li>
1047 <li><code>MDNode::getTemporary</code></li>
1048 <li><code>MDNode::getWhenValsUnresolved</code></li>
1049 <li><code>SimplifyGEPInst</code> (in <code>llvm/Analysis/InstructionSimplify.h</code>)</li>
1050 <li><code>TargetData::getIndexedOffset</code></li>
1051 </ul></li>
1052
1053   <li>All forms of <code>StringMap::getOrCreateValue</code> have been remove
1054       except for the one which takes a <code>StringRef</code>.</li>
1055
1056   <li>The <code>LLVMBuildUnwind</code> function from the C API was removed. The
1057       LLVM <code>unwind</code> instruction has been deprecated for a long time
1058       and isn't used by the current front-ends. So this was removed during the
1059       exception handling rewrite.</li>
1060
1061   <li>The <code>LLVMAddLowerSetJmpPass</code> function from the C API was
1062       removed because the <code>LowerSetJmp</code> pass was removed.</li>
1063
1064   <li>The <code>DIBuilder</code> interface used by front ends to encode
1065       debugging information in the LLVM IR now expects clients to
1066       use <code>DIBuilder::finalize()</code> at the end of translation unit to
1067       complete debugging information encoding.</li>
1068
1069   <li>The way the type system works has been
1070       rewritten: <code>PATypeHolder</code> and <code>OpaqueType</code> are gone,
1071       and all APIs deal with <code>Type*</code> instead of <code>const
1072       Type*</code>.  If you need to create recursive structures, then create a
1073       named structure, and use <code>setBody()</code> when all its elements are
1074       built.  Type merging and refining is gone too: named structures are not
1075       merged with other structures, even if their layout is identical.  (of
1076       course anonymous structures are still uniqued by layout).</li>
1077
1078   <li>TargetSelect.h moved to Support/ from Target/</li>
1079
1080   <li>UpgradeIntrinsicCall no longer upgrades pre-2.9 intrinsic calls (for
1081       example <code>llvm.memset.i32</code>).</li>
1082
1083   <li>It is mandatory to initialize all out-of-tree passes too and their dependencies now with
1084       <code>INITIALIZE_PASS{BEGIN,END,}</code>
1085       and <code>INITIALIZE_{PASS,AG}_DEPENDENCY</code>.</li>
1086
1087   <li>The interface for MemDepResult in MemoryDependenceAnalysis has been
1088       enhanced with new return types Unknown and NonFuncLocal, in addition to
1089       the existing types Clobber, Def, and NonLocal.</li>
1090 </ul>
1091
1092 </div>
1093
1094 </div>
1095
1096 <!-- *********************************************************************** -->
1097 <h2>
1098   <a name="knownproblems">Known Problems</a>
1099 </h2>
1100 <!-- *********************************************************************** -->
1101
1102 <div>
1103
1104 <p>This section contains significant known problems with the LLVM system, listed
1105    by component.  If you run into a problem, please check
1106    the <a href="http://llvm.org/bugs/">LLVM bug database</a> and submit a bug if
1107    there isn't already one.</p>
1108
1109 <!-- ======================================================================= -->
1110 <h3>
1111   <a name="experimental">Experimental features included with this release</a>
1112 </h3>
1113
1114 <div>
1115
1116 <p>The following components of this LLVM release are either untested, known to
1117    be broken or unreliable, or are in early development.  These components
1118    should not be relied on, and bugs should not be filed against them, but they
1119    may be useful to some people.  In particular, if you would like to work on
1120    one of these components, please contact us on
1121    the <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev
1122    list</a>.</p>
1123
1124 <ul>
1125   <li>The Alpha, Blackfin, CellSPU, MicroBlaze, MSP430, MIPS, PTX, SystemZ and
1126       XCore backends are experimental.</li>
1127
1128   <li><tt>llc</tt> "<tt>-filetype=obj</tt>" is experimental on all targets other
1129       than darwin and ELF X86 systems.</li>
1130 </ul>
1131
1132 </div>
1133
1134 <!-- ======================================================================= -->
1135 <h3>
1136   <a name="x86-be">Known problems with the X86 back-end</a>
1137 </h3>
1138
1139 <div>
1140
1141 <ul>
1142   <li>The X86 backend does not yet support
1143       all <a href="http://llvm.org/PR879">inline assembly that uses the X86
1144       floating point stack</a>.  It supports the 'f' and 't' constraints, but
1145       not 'u'.</li>
1146
1147   <li>The X86-64 backend does not yet support the LLVM IR instruction
1148       <tt>va_arg</tt>. Currently, front-ends support variadic argument
1149       constructs on X86-64 by lowering them manually.</li>
1150
1151   <li>Windows x64 (aka Win64) code generator has a few issues.
1152     <ul>
1153       <li>On mingw-w64, you will see unresolved symbol <tt>__chkstk</tt> due
1154           to <a href="http://llvm.org/bugs/show_bug.cgi?id=8919">Bug 8919</a>.
1155           It is fixed
1156           in <a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110321/118499.html">r128206</a>.</li>
1157
1158       <li>Miss-aligned MOVDQA might crash your program. It is due to
1159           <a href="http://llvm.org/bugs/show_bug.cgi?id=9483">Bug 9483</a>, lack
1160           of handling aligned internal globals.</li>
1161       </ul>
1162   </li>
1163
1164 </ul>
1165
1166 </div>
1167
1168 <!-- ======================================================================= -->
1169 <h3>
1170   <a name="ppc-be">Known problems with the PowerPC back-end</a>
1171 </h3>
1172
1173 <div>
1174
1175 <ul>
1176   <li>The PPC32/ELF support lacks PIC support.</li>
1177 </ul>
1178
1179 </div>
1180
1181 <!-- ======================================================================= -->
1182 <h3>
1183   <a name="arm-be">Known problems with the ARM back-end</a>
1184 </h3>
1185
1186 <div>
1187
1188 <ul>
1189   <li>Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6
1190       processors, thumb programs can crash or produce wrong results
1191       (<a href="http://llvm.org/PR1388">PR1388</a>).</li>
1192
1193   <li>Compilation for ARM Linux OABI (old ABI) is supported but not fully
1194       tested.</li>
1195 </ul>
1196
1197 </div>
1198
1199 <!-- ======================================================================= -->
1200 <h3>
1201   <a name="sparc-be">Known problems with the SPARC back-end</a>
1202 </h3>
1203
1204 <div>
1205
1206 <ul>
1207   <li>The SPARC backend only supports the 32-bit SPARC ABI (-m32); it does not
1208       support the 64-bit SPARC ABI (-m64).</li>
1209 </ul>
1210
1211 </div>
1212
1213 <!-- ======================================================================= -->
1214 <h3>
1215   <a name="mips-be">Known problems with the MIPS back-end</a>
1216 </h3>
1217
1218 <div>
1219
1220 <ul>
1221   <li>64-bit MIPS targets are not supported yet.</li>
1222 </ul>
1223
1224 </div>
1225
1226 <!-- ======================================================================= -->
1227 <h3>
1228   <a name="alpha-be">Known problems with the Alpha back-end</a>
1229 </h3>
1230
1231 <div>
1232
1233 <ul>
1234   <li>On 21164s, some rare FP arithmetic sequences which may trap do not have
1235       the appropriate nops inserted to ensure restartability.</li>
1236 </ul>
1237
1238 </div>
1239
1240 <!-- ======================================================================= -->
1241 <h3>
1242   <a name="c-be">Known problems with the C back-end</a>
1243 </h3>
1244
1245 <div>
1246
1247 <p>The C backend has numerous problems and is not being actively maintained.
1248    Depending on it for anything serious is not advised.</p>
1249
1250 <ul>
1251   <li><a href="http://llvm.org/PR802">The C backend has only basic support for
1252       inline assembly code</a>.</li>
1253
1254   <li><a href="http://llvm.org/PR1658">The C backend violates the ABI of common
1255       C++ programs</a>, preventing intermixing between C++ compiled by the CBE
1256       and C++ code compiled with <tt>llc</tt> or native compilers.</li>
1257
1258   <li>The C backend does not support all exception handling constructs.</li>
1259
1260   <li>The C backend does not support arbitrary precision integers.</li>
1261 </ul>
1262
1263 </div>
1264
1265 </div>
1266
1267 <!-- *********************************************************************** -->
1268 <h2>
1269   <a name="additionalinfo">Additional Information</a>
1270 </h2>
1271 <!-- *********************************************************************** -->
1272
1273 <div>
1274
1275 <p>A wide variety of additional information is available on
1276    the <a href="http://llvm.org/">LLVM web page</a>, in particular in
1277    the <a href="http://llvm.org/docs/">documentation</a> section.  The web page
1278    also contains versions of the API documentation which is up-to-date with the
1279    Subversion version of the source code.  You can access versions of these
1280    documents specific to this release by going into the "<tt>llvm/doc/</tt>"
1281    directory in the LLVM tree.</p>
1282
1283 <p>If you have any questions or comments about LLVM, please feel free to contact
1284    us via the <a href="http://llvm.org/docs/#maillist"> mailing lists</a>.</p>
1285
1286 </div>
1287
1288 <!-- *********************************************************************** -->
1289
1290 <hr>
1291 <address>
1292   <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
1293   src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
1294   <a href="http://validator.w3.org/check/referer"><img
1295   src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
1296
1297   <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br>
1298   Last modified: $Date$
1299 </address>
1300
1301 </body>
1302 </html>