docs/ReleaseNotes.html

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