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