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   <meta encoding="utf8">
   7   <link rel="stylesheet" href="llvm.css" type="text/css">
   8   <title>LLVM 2.9 Release Notes</title>
   9 </head>
  10 <body>
  11
  12 <h1 class="doc_title">LLVM 2.9 Release Notes</h1>
  13
  14 <img align=right src="http://llvm.org/img/DragonSmall.png"
  15     width="136" height="136" alt="LLVM Dragon Logo">
  16
  17 <ol>
  18   <li><a href="#intro">Introduction</a></li>
  19   <li><a href="#subproj">Sub-project Status Update</a></li>
  20   <li><a href="#externalproj">External Projects Using LLVM 2.9</a></li>
  21   <li><a href="#whatsnew">What's New in LLVM 2.9?</a></li>
  22   <li><a href="GettingStarted.html">Installation Instructions</a></li>
  23   <li><a href="#knownproblems">Known Problems</a></li>
  24   <li><a href="#additionalinfo">Additional Information</a></li>
  25 </ol>
  26
  27 <div class="doc_author">
  28   <p>Written by the <a href="http://llvm.org">LLVM Team</a></p>
  29 </div>
  30
  31 <!--
  32 <h1 style="color:red">These are in-progress notes for the upcoming LLVM 2.9
  33 release.<br>
  34 You may prefer the
  35 <a href="http://llvm.org/releases/2.8/docs/ReleaseNotes.html">LLVM 2.8
  36 Release Notes</a>.</h1>
  37  -->
  38
  39 <!-- *********************************************************************** -->
  40 <h1>
  41   <a name="intro">Introduction</a>
  42 </h1>
  43 <!-- *********************************************************************** -->
  44
  45 <div class="doc_text">
  46
  47 <p>This document contains the release notes for the LLVM Compiler
  48 Infrastructure, release 2.9.  Here we describe the status of LLVM, including
  49 major improvements from the previous release and significant known problems.
  50 All LLVM releases may be downloaded from the <a
  51 href="http://llvm.org/releases/">LLVM releases web site</a>.</p>
  52
  53 <p>For more information about LLVM, including information about the latest
  54 release, please check out the <a href="http://llvm.org/">main LLVM
  55 web site</a>.  If you have questions or comments, the <a
  56 href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVM Developer's
  57 Mailing List</a> is a good place to send them.</p>
  58
  59 <p>Note that if you are reading this file from a Subversion checkout or the
  60 main LLVM web page, this document applies to the <i>next</i> release, not the
  61 current one.  To see the release notes for a specific release, please see the
  62 <a href="http://llvm.org/releases/">releases page</a>.</p>
  63
  64 </div>
  65
  66 <!-- Features that need text if they're finished for 3.1:
  67   ARM EHABI
  68   combiner-aa?
  69   strong phi elim
  70   loop dependence analysis
  71   CorrelatedValuePropagation
  72   lib/Transforms/IPO/MergeFunctions.cpp => consider for 3.1.
  73  -->
  74
  75 <!-- *********************************************************************** -->
  76 <h1>
  77   <a name="subproj">Sub-project Status Update</a>
  78 </h1>
  79 <!-- *********************************************************************** -->
  80
  81 <div class="doc_text">
  82 <p>
  83 The LLVM 2.9 distribution currently consists of code from the core LLVM
  84 repository (which roughly includes the LLVM optimizers, code generators
  85 and supporting tools), the Clang repository and the llvm-gcc repository.  In
  86 addition to this code, the LLVM Project includes other sub-projects that are in
  87 development.  Here we include updates on these subprojects.
  88 </p>
  89
  90 </div>
  91
  92
  93 <!--=========================================================================-->
  94 <h2>
  95 <a name="clang">Clang: C/C++/Objective-C Frontend Toolkit</a>
  96 </h2>
  97
  98 <div class="doc_text">
  99
 100 <p><a href="http://clang.llvm.org/">Clang</a> is an LLVM front end for the C,
 101 C++, and Objective-C languages. Clang aims to provide a better user experience
 102 through expressive diagnostics, a high level of conformance to language
 103 standards, fast compilation, and low memory use. Like LLVM, Clang provides a
 104 modular, library-based architecture that makes it suitable for creating or
 105 integrating with other development tools. Clang is considered a
 106 production-quality compiler for C, Objective-C, C++ and Objective-C++ on x86
 107 (32- and 64-bit), and for darwin/arm targets.</p>
 108
 109 <p>In the LLVM 2.9 time-frame, the Clang team has made many improvements in C,
 110 C++ and Objective-C support.  C++ support is now generally rock solid, has
 111 been exercised on a broad variety of code, and has several new <a
 112 href="http://clang.llvm.org/cxx_status.html#cxx0x">C++'0x features</a>
 113 implemented (such as rvalue references and variadic templates).  LLVM 2.9 has
 114 also brought in a large range of bug fixes and minor features (e.g. __label__
 115 support), and is much more compatible with the Linux Kernel.</p>
 116
 117 <p>If Clang rejects your code that is built with another compiler, please take a
 118 look at the <a href="http://clang.llvm.org/compatibility.html">language
 119 compatibility</a> guide to make sure the issue isn't intentional or a known
 120 issue.
 121 </p>
 122
 123 <ul>
 124 </ul>
 125 </div>
 126
 127 <!--=========================================================================-->
 128 <h2>
 129 <a name="dragonegg">DragonEgg: GCC front-ends, LLVM back-end</a>
 130 </h2>
 131
 132 <div class="doc_text">
 133 <p>
 134 <a href="http://dragonegg.llvm.org/">DragonEgg</a> is a
 135 <a href="http://gcc.gnu.org/wiki/plugins">gcc plugin</a> that replaces GCC's
 136 optimizers and code generators with LLVM's.
 137 Currently it requires a patched version of gcc-4.5.
 138 The plugin can target the x86-32 and x86-64 processor families and has been
 139 used successfully on the Darwin, FreeBSD and Linux platforms.
 140 The Ada, C, C++ and Fortran languages work well.
 141 The plugin is capable of compiling plenty of Obj-C, Obj-C++ and Java but it is
 142 not known whether the compiled code actually works or not!
 143 </p>
 144
 145 <p>
 146 The 2.9 release has the following notable changes:
 147 <ul>
 148 <li>The plugin is much more stable when compiling Fortran.</li>
 149 <li>Inline assembly where an asm output is tied to an input of a different size
 150 is now supported in many more cases.</li>
 151 <li>Basic support for the __float128 type was added.  It is now possible to
 152 generate LLVM IR from programs using __float128 but code generation does not
 153 work yet.</li>
 154 <li>Compiling Java programs no longer systematically crashes the plugin.</li>
 155 </ul>
 156
 157 </div>
 158
 159 <!--=========================================================================-->
 160 <h2>
 161 <a name="compiler-rt">compiler-rt: Compiler Runtime Library</a>
 162 </h2>
 163
 164 <div class="doc_text">
 165 <p>
 166 The new LLVM <a href="http://compiler-rt.llvm.org/">compiler-rt project</a>
 167 is a simple library that provides an implementation of the low-level
 168 target-specific hooks required by code generation and other runtime components.
 169 For example, when compiling for a 32-bit target, converting a double to a 64-bit
 170 unsigned integer is compiled into a runtime call to the "__fixunsdfdi"
 171 function. The compiler-rt library provides highly optimized implementations of
 172 this and other low-level routines (some are 3x faster than the equivalent
 173 libgcc routines).</p>
 174
 175 <p>In the LLVM 2.9 timeframe, compiler_rt has had several minor changes for
 176   better ARM support, and a fairly major license change.  All of the code in the
 177   compiler-rt project is now <a href="DeveloperPolicy.html#license">dual
 178   licensed</a> under MIT and UIUC license, which allows you to use compiler-rt
 179   in applications without the binary copyright reproduction clause.  If you
 180   prefer the LLVM/UIUC license, you are free to continue using it under that
 181   license as well.</p>
 182
 183 </div>
 184
 185 <!--=========================================================================-->
 186 <h2>
 187 <a name="lldb">LLDB: Low Level Debugger</a>
 188 </h2>
 189
 190 <div class="doc_text">
 191 <p>
 192 <a href="http://lldb.llvm.org/">LLDB</a> is a brand new member of the LLVM
 193 umbrella of projects. LLDB is a next generation, high-performance debugger. It
 194 is built as a set of reusable components which highly leverage existing
 195 libraries in the larger LLVM Project, such as the Clang expression parser, the
 196 LLVM disassembler and the LLVM JIT.</p>
 197
 198 <p>
 199 LLDB is has advanced by leaps and bounds in the 2.9 timeframe.  It is
 200 dramatically more stable and useful, and includes both a new <a
 201 href="http://lldb.llvm.org/tutorial.html">tutorial</a> and a <a
 202 href="http://lldb.llvm.org/lldb-gdb.html">side-by-side comparison with
 203 GDB</a>.</p>
 204
 205 </div>
 206
 207 <!--=========================================================================-->
 208 <h2>
 209 <a name="libc++">libc++: C++ Standard Library</a>
 210 </h2>
 211
 212 <div class="doc_text">
 213 <p>
 214 <a href="http://libcxx.llvm.org/">libc++</a> is another new member of the LLVM
 215 family.  It is an implementation of the C++ standard library, written from the
 216 ground up to specifically target the forthcoming C++'0X standard and focus on
 217 delivering great performance.</p>
 218
 219 <p>
 220 In the LLVM 2.9 timeframe, libc++ has had numerous bugs fixed, and is now being
 221 co-developed with Clang's C++'0x mode.</p>
 222
 223 <p>
 224 Like compiler_rt, libc++ is now <a href="DeveloperPolicy.html#license">dual
 225   licensed</a> under the MIT and UIUC license, allowing it to be used more
 226   permissively.
 227 </p>
 228
 229 </div>
 230
 231
 232
 233 <!--=========================================================================-->
 234 <!--
 235 <h2>
 236 <a name="klee">KLEE: A Symbolic Execution Virtual Machine</a>
 237 </h2>
 238
 239 <div class="doc_text">
 240 <p>
 241 <a href="http://klee.llvm.org/">KLEE</a> is a symbolic execution framework for
 242 programs in LLVM bitcode form. KLEE tries to symbolically evaluate "all" paths
 243 through the application and records state transitions that lead to fault
 244 states. This allows it to construct testcases that lead to faults and can even
 245 be used to verify some algorithms.
 246 </p>
 247
 248 <p>UPDATE!</p>
 249 </div>-->
 250
 251
 252 <!-- *********************************************************************** -->
 253 <h1>
 254   <a name="externalproj">External Open Source Projects Using LLVM 2.9</a>
 255 </h1>
 256 <!-- *********************************************************************** -->
 257
 258 <div class="doc_text">
 259
 260 <p>An exciting aspect of LLVM is that it is used as an enabling technology for
 261    a lot of other language and tools projects.  This section lists some of the
 262    projects that have already been updated to work with LLVM 2.9.</p>
 263 </div>
 264
 265
 266 <!--=========================================================================-->
 267 <h2>Crack Programming Language</h2>
 268
 269 <div class="doc_text">
 270 <p>
 271 <a href="http://code.google.com/p/crack-language/">Crack</a> aims to provide the
 272 ease of development of a scripting language with the performance of a compiled
 273 language. The language derives concepts from C++, Java and Python, incorporating
 274 object-oriented programming, operator overloading and strong typing.</p>
 275 </div>
 276
 277
 278 <!--=========================================================================-->
 279 <h2>TTA-based Codesign Environment (TCE)</h2>
 280
 281 <div class="doc_text">
 282 <p>TCE is a toolset for designing application-specific processors (ASP) based on
 283 the Transport triggered architecture (TTA). The toolset provides a complete
 284 co-design flow from C/C++ programs down to synthesizable VHDL and parallel
 285 program binaries. Processor customization points include the register files,
 286 function units, supported operations, and the interconnection network.</p>
 287
 288 <p>TCE uses Clang and LLVM for C/C++ language support, target independent
 289 optimizations and also for parts of code generation. It generates new LLVM-based
 290 code generators "on the fly" for the designed TTA processors and loads them in
 291 to the compiler backend as runtime libraries to avoid per-target recompilation
 292 of larger parts of the compiler chain.</p>
 293 </div>
 294
 295
 296
 297 <!--=========================================================================-->
 298 <h2>PinaVM</h2>
 299
 300 <div class="doc_text">
 301 <p><a href="http://gitorious.org/pinavm/pages/Home">PinaVM</a> is an open
 302 source, <a href="http://www.systemc.org/">SystemC</a> front-end. Unlike many
 303 other front-ends, PinaVM actually executes the elaboration of the
 304 program analyzed using LLVM's JIT infrastructure. It later enriches the
 305 bitcode with SystemC-specific information.</p>
 306 </div>
 307
 308 <!--=========================================================================-->
 309 <h2>Pure</h2>
 310
 311 <div class="doc_text">
 312 <p><a href="http://pure-lang.googlecode.com/">Pure</a> is an
 313   algebraic/functional
 314   programming language based on term rewriting. Programs are collections
 315   of equations which are used to evaluate expressions in a symbolic
 316   fashion. The interpreter uses LLVM as a backend to JIT-compile Pure
 317   programs to fast native code. Pure offers dynamic typing, eager and lazy
 318   evaluation, lexical closures, a hygienic macro system (also based on
 319   term rewriting), built-in list and matrix support (including list and
 320   matrix comprehensions) and an easy-to-use interface to C and other
 321   programming languages (including the ability to load LLVM bitcode
 322   modules, and inline C, C++, Fortran and Faust code in Pure programs if
 323   the corresponding LLVM-enabled compilers are installed).</p>
 324
 325 <p>Pure version 0.47 has been tested and is known to work with LLVM 2.9
 326   (and continues to work with older LLVM releases &gt;= 2.5).</p>
 327 </div>
 328
 329 <!--=========================================================================-->
 330 <h2 id="icedtea">IcedTea Java Virtual Machine Implementation</h2>
 331
 332 <div class="doc_text">
 333 <p>
 334 <a href="http://icedtea.classpath.org/wiki/Main_Page">IcedTea</a> provides a
 335 harness to build OpenJDK using only free software build tools and to provide
 336 replacements for the not-yet free parts of OpenJDK.  One of the extensions that
 337 IcedTea provides is a new JIT compiler named <a
 338 href="http://icedtea.classpath.org/wiki/ZeroSharkFaq">Shark</a> which uses LLVM
 339 to provide native code generation without introducing processor-dependent
 340 code.
 341 </p>
 342
 343 <p> OpenJDK 7 b112, IcedTea6 1.9 and IcedTea7 1.13 and later have been tested
 344 and are known to work with LLVM 2.9 (and continue to work with older LLVM
 345 releases &gt;= 2.6 as well).</p>
 346 </div>
 347
 348 <!--=========================================================================-->
 349 <h2>Glasgow Haskell Compiler (GHC)</h2>
 350
 351 <div class="doc_text">
 352 <p>GHC is an open source, state-of-the-art programming suite for Haskell,
 353 a standard lazy functional programming language. It includes an
 354 optimizing static compiler generating good code for a variety of
 355 platforms, together with an interactive system for convenient, quick
 356 development.</p>
 357
 358 <p>In addition to the existing C and native code generators, GHC 7.0 now
 359 supports an LLVM code generator. GHC supports LLVM 2.7 and later.</p>
 360 </div>
 361
 362 <!--=========================================================================-->
 363 <h2>Polly - Polyhedral optimizations for LLVM</h2>
 364
 365 <div class="doc_text">
 366 <p>Polly is a project that aims to provide advanced memory access optimizations
 367 to better take advantage of SIMD units, cache hierarchies, multiple cores or
 368 even vector accelerators for LLVM. Built around an abstract mathematical
 369 description based on Z-polyhedra, it provides the infrastructure to develop
 370 advanced optimizations in LLVM and to connect complex external optimizers. In
 371 its first year of existence Polly already provides an exact value-based
 372 dependency analysis as well as basic SIMD and OpenMP code generation support.
 373 Furthermore, Polly can use PoCC(Pluto) an advanced optimizer for data-locality
 374 and parallelism.</p>
 375 </div>
 376
 377
 378 <!-- *********************************************************************** -->
 379 <h1>
 380   <a name="whatsnew">What's New in LLVM 2.9?</a>
 381 </h1>
 382 <!-- *********************************************************************** -->
 383
 384 <div class="doc_text">
 385
 386 <p>This release includes a huge number of bug fixes, performance tweaks and
 387 minor improvements.  Some of the major improvements and new features are listed
 388 in this section.
 389 </p>
 390
 391 </div>
 392
 393 <!--=========================================================================-->
 394 <h2>
 395 <a name="majorfeatures">Major New Features</a>
 396 </h2>
 397
 398 <div class="doc_text">
 399
 400 <p>LLVM 2.9 includes several major new capabilities:</p>
 401
 402 <ul>
 403
 404 <li>Type Based Alias Analysis (TBAA) is now implemented and turned on by default
 405   in Clang.  This allows substantially better load/store optimization in some
 406   cases.  TBAA can be disabled by passing -fno-strict-aliasing.
 407 </li>
 408
 409 <li>This release has seen a continued focus on quality of debug information.
 410   LLVM now generates much higher fidelity debug information, particularly when
 411   debugging optimized code.</li>
 412
 413 <li>Inline assembly now supports multiple alternative constraints.</li>
 414
 415 <li>A new backend for the NVIDIA PTX virtual ISA (used to target its GPUs) is
 416   under rapid development.  It is not generally useful in 2.9, but is making
 417   rapid progress.</li>
 418
 419 </ul>
 420
 421 </div>
 422
 423 <!--=========================================================================-->
 424 <h2>
 425 <a name="coreimprovements">LLVM IR and Core Improvements</a>
 426 </h2>
 427
 428 <div class="doc_text">
 429 <p>LLVM IR has several new features for better support of new targets and that
 430 expose new optimization opportunities:</p>
 431
 432 <ul>
 433 <li>The <a href="LangRef.html#bitwiseops">udiv, ashr, lshr, and shl</a>
 434   instructions now have support exact and nuw/nsw bits to indicate that they
 435   don't overflow or shift out bits.  This is useful for optimization of <a
 436     href="http://llvm.org/PR8862">pointer differences</a> and other cases.</li>
 437
 438 <li>LLVM IR now supports the <a href="LangRef.html#globalvars">unnamed_addr</a>
 439   attribute to indicate that constant global variables with identical
 440   initializers can be merged.  This fixed <a href="http://llvm.org/PR8927">an
 441   issue</a> where LLVM would incorrectly merge two globals which were supposed
 442   to have distinct addresses.</li>
 443
 444 <li>The new <a href="LangRef.html#fnattrs">hotpatch attribute</a> has been added
 445   to allow runtime patching of functions.</li>
 446 </ul>
 447
 448 </div>
 449
 450 <!--=========================================================================-->
 451 <h2>
 452 <a name="optimizer">Optimizer Improvements</a>
 453 </h2>
 454
 455 <div class="doc_text">
 456
 457 <p>In addition to a large array of minor performance tweaks and bug fixes, this
 458 release includes a few major enhancements and additions to the optimizers:</p>
 459
 460 <ul>
 461 <li>Link Time Optimization (LTO) has been improved to use MC for parsing inline
 462   assembly and now can build large programs like Firefox 4 on both Mac OS X and
 463   Linux.</li>
 464
 465 <li>The new -loop-idiom pass recognizes memset/memcpy loops (and memset_pattern
 466   on darwin), turning them into library calls, which are typically better
 467   optimized than inline code.  If you are building a libc and notice that your
 468   memcpy and memset functions are compiled into infinite recursion, please build
 469   with -ffreestanding or -fno-builtin to disable this pass.</li>
 470
 471 <li>A new -early-cse pass does a fast pass over functions to fold constants,
 472   simplify expressions, perform simple dead store elimination, and perform
 473   common subexpression elimination.  It does a good job at catching some of the
 474   trivial redundancies that exist in unoptimized code, making later passes more
 475   effective.<,/li>
 476
 477 <li>A new -loop-instsimplify pass is used to clean up loop bodies in the loop
 478   optimizer.</li>
 479
 480 <li>The new TargetLibraryInfo interface allows mid-level optimizations to know
 481   whether the current target's runtime library has certain functions.  For
 482   example, the optimizer can now transform integer-only printf calls to call
 483   iprintf, allowing reduced code size for embedded C libraries (e.g. newlib).
 484 </li>
 485
 486 <li>LLVM has a new <a href="WritingAnLLVMPass.html#RegionPass">RegionPass</a>
 487   infrastructure for region-based optimizations.</li>
 488
 489 <li>Several optimizer passes have been substantially sped up:
 490   GVN is much faster on functions with deep dominator trees and lots of basic
 491   blocks.  The dominator tree and dominance frontier passes are much faster to
 492   compute, and preserved by more passes (so they are computed less often).  The
 493   -scalar-repl pass is also much faster and doesn't use DominanceFrontier.
 494 </li>
 495
 496 <li>The Dead Store Elimination pass is more aggressive optimizing stores of
 497   different types: e.g. a large store following a small one to the same address.
 498   The MemCpyOptimizer pass handles several new forms of memcpy elimination.</li>
 499
 500 <li>LLVM now optimizes various idioms for overflow detection into check of the
 501   flag register on various CPUs.  For example, we now compile:
 502
 503   <pre>
 504    unsigned long t = a+b;
 505    if (t &lt; a) ...
 506   </pre>
 507   into:
 508   <pre>
 509    addq %rdi, %rbx
 510    jno  LBB0_2
 511   </pre>
 512 </li>
 513
 514 </ul>
 515
 516 </div>
 517
 518 <!--=========================================================================-->
 519 <h2>
 520 <a name="mc">MC Level Improvements</a>
 521 </h2>
 522
 523 <div class="doc_text">
 524 <p>
 525 The LLVM Machine Code (aka MC) subsystem was created to solve a number
 526 of problems in the realm of assembly, disassembly, object file format handling,
 527 and a number of other related areas that CPU instruction-set level tools work
 528 in.</p>
 529
 530 <ul>
 531 <li>ELF MC support has matured enough for the integrated assembler to be turned
 532   on by default in Clang on X86-32 and X86-64 ELF systems.</li>
 533
 534 <li>MC supports and CodeGen uses the <tt>.file</tt> and <tt>.loc</tt> directives
 535   for producing line number debug info. This produces more compact line
 536   tables and easier to read .s files.</li>
 537
 538 <li>MC supports the <tt>.cfi_*</tt> directives for producing DWARF
 539   frame information, but it is still not used by CodeGen by default.</li>
 540
 541
 542 <li>The MC assembler now generates much better diagnostics for common errors,
 543   is much faster at matching instructions, is much more bug-compatible with
 544   the GAS assembler, and is now generally useful for a broad range of X86
 545   assembly.</li>
 546
 547 <li>We now have some basic <a href="CodeGenerator.html#mc">internals
 548   documentation</a> for MC.</li>
 549
 550 <li>.td files can now specify assembler aliases directly with the <a
 551    href="CodeGenerator.html#na_instparsing">MnemonicAlias and InstAlias</a>
 552    tblgen classes.</li>
 553
 554 <li>LLVM now has an experimental format-independent object file manipulation
 555   library (lib/Object).  It supports both PE/COFF and ELF.  The llvm-nm tool has
 556   been extended to work with native object files, and the new llvm-objdump tool
 557   supports disassembly of object files (but no relocations are displayed yet).
 558 </li>
 559
 560 <li>Win32 PE-COFF support in the MC assembler has made a lot of progress in the
 561   2.9 timeframe, but is still not generally useful.</li>
 562
 563 </ul>
 564
 565 <p>For more information, please see the <a
 566 href="http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html">Intro to the
 567 LLVM MC Project Blog Post</a>.
 568 </p>
 569
 570 </div>
 571
 572 <!--=========================================================================-->
 573 <h2>
 574 <a name="codegen">Target Independent Code Generator Improvements</a>
 575 </h2>
 576
 577 <div class="doc_text">
 578
 579 <p>We have put a significant amount of work into the code generator
 580 infrastructure, which allows us to implement more aggressive algorithms and make
 581 it run faster:</p>
 582
 583 <ul>
 584 <li>The pre-register-allocation (preRA) instruction scheduler models register
 585   pressure much more accurately in some cases. This allows the adoption of more
 586   aggressive scheduling heuristics without causing spills to be generated.
 587 </li>
 588
 589 <li>LiveDebugVariables is a new pass that keeps track of debugging information
 590   for user variables that are promoted to registers in optimized builds.</li>
 591
 592 <li>The scheduler now models operand latency and pipeline forwarding.</li>
 593
 594 <li>A major register allocator infrastructure rewrite is underway.  It is not on
 595     by default for 2.9 and you are not advised to use it, but it has made
 596     substantial progress in the 2.9 timeframe:
 597   <ul>
 598   <li>A new -regalloc=basic "basic" register allocator can be used as a simple
 599       fallback when debugging.  It uses the new infrastructure.</li>
 600   <li>New infrastructure is in place for live range splitting.  "SplitKit" can
 601       break a live interval into smaller pieces while preserving SSA form, and
 602       SpillPlacement can help find the best split points. This is a work in
 603       progress so the API is changing quickly.</li>
 604    <li>The inline spiller has learned to clean up after live range splitting. It
 605       can hoist spills out of loops, and it can eliminate redundant spills.</li>
 606    <li>Rematerialization works with live range splitting.</li>
 607    <li>The new "greedy" register allocator using live range splitting. This will
 608      be the default register allocator in the next LLVM release, but it is not
 609      turned on by default in 2.9.</li>
 610    </ul>
 611 </li>
 612 </ul>
 613 </div>
 614
 615 <!--=========================================================================-->
 616 <h2>
 617 <a name="x86">X86-32 and X86-64 Target Improvements</a>
 618 </h2>
 619
 620 <div class="doc_text">
 621 <p>New features and major changes in the X86 target include:
 622 </p>
 623
 624 <ul>
 625 <li>LLVM 2.9 includes a complete reimplementation of the MMX instruction set.
 626   The reimplementation uses a new LLVM IR <a
 627   href="LangRef.html#t_x86mmx">x86_mmx</a> type to ensure that MMX operations
 628   are <em>only</em> generated from source that uses MMX builtin operations. With
 629   this, random types like &lt;2 x i32&gt; are not turned into to MMX operations
 630   (which can be catastrophic without proper "emms" insertion).  Because the X86
 631   code generator always generates reliable code, the -disable-mmx flag is now
 632   removed.
 633 </li>
 634
 635 <li>X86 support for FS/GS relative loads and stores using <a
 636     href="CodeGenerator.html#x86_memory">address space 256/257</a> work reliably
 637     now.</li>
 638
 639 <li>LLVM 2.9 generates much better code in several cases by using adc/sbb to
 640    avoid generation of conditional move instructions for conditional increment
 641    and other idioms.</li>
 642
 643 <li>The X86 backend has adopted a new preRA scheduling mode, "list-ilp", to
 644   shorten the height of instruction schedules without inducing register spills.
 645 </li>
 646
 647 <li>The MC assembler support for 3dNow! and 3DNowA instructions.</li>
 648
 649 <li>Several bugs have been fixed for Windows x64 code generator.</li>
 650 </ul>
 651
 652 </div>
 653
 654 <!--=========================================================================-->
 655 <h2>
 656 <a name="ARM">ARM Target Improvements</a>
 657 </h2>
 658
 659 <div class="doc_text">
 660 <p>New features of the ARM target include:
 661 </p>
 662
 663 <ul>
 664 <li>The ARM backend now has a fast instruction selector, which dramatically
 665      improves -O0 compile times.</li>
 666 <li>The ARM backend has new tuning for Cortex-A8 and Cortex-A9 CPUs.</li>
 667 <li>The __builtin_prefetch builtin (and llvm.prefetch intrinsic) is compiled
 668     into prefetch instructions instead of being discarded.</li>
 669
 670 <li>  The ARM backend preRA scheduler now models machine resources at cycle
 671   granularity. This allows the scheduler to both accurately model
 672   instruction latency and avoid overcommitting functional units.</li>
 673
 674 <li>Countless ARM microoptimizations have landed in LLVM 2.9.</li>
 675 </ul>
 676 </div>
 677
 678 <!--=========================================================================-->
 679 <h2>
 680 <a name="OtherTS">Other Target Specific Improvements</a>
 681 </h2>
 682
 683 <div class="doc_text">
 684 <ul>
 685 <li>MicroBlaze: major updates for aggressive delay slot filler, MC-based
 686   assembly printing, assembly instruction parsing, ELF .o file emission, and MC
 687   instruction disassembler have landed.</li>
 688
 689 <li>SPARC: Many improvements, including using the Y registers for
 690   multiplications and addition of a simple delay slot filler.</li>
 691
 692 <li>PowerPC: The backend has been largely MC'ized and is ready to support
 693   directly writing out mach-o object files.  Noone seems interested in finishing
 694   this final step though.</li>
 695
 696 </ul>
 697 </div>
 698
 699 <!--=========================================================================-->
 700 <h2>
 701 <a name="changes">Major Changes and Removed Features</a>
 702 </h2>
 703
 704 <div class="doc_text">
 705
 706 <p>If you're already an LLVM user or developer with out-of-tree changes based
 707 on LLVM 2.8, this section lists some "gotchas" that you may run into upgrading
 708 from the previous release.</p>
 709
 710 <ul>
 711 <li><b>This is the last release to support the llvm-gcc frontend.</b></li>
 712
 713 <li>LLVM has a new <a href="CodingStandards.html#ll_naming">naming
 714   convention standard</a>, though the codebase hasn't fully adopted it yet.</li>
 715
 716 <li>The new DIBuilder class provides a simpler interface for front ends to
 717     encode debug info in LLVM IR, and has replaced DIFactory.</li>
 718
 719 <li>LLVM IR and other tools always work on normalized target triples (which have
 720   been run through <tt>Triple::normalize</tt>).</li>
 721
 722 <li>The target triple x86_64--mingw64 is obsoleted. Use x86_64--mingw32
 723   instead.</li>
 724
 725 <li>The PointerTracking pass has been removed from mainline, and moved to The
 726   ClamAV project (its only client).</li>
 727
 728 <li>The LoopIndexSplit, LiveValues, SimplifyHalfPowrLibCalls, GEPSplitter, and
 729   PartialSpecialization passes were removed.  They were unmaintained,
 730   buggy, or decided to be a bad idea.</li>
 731 </ul>
 732
 733 </div>
 734
 735 <!--=========================================================================-->
 736 <h2>
 737 <a name="api_changes">Internal API Changes</a>
 738 </h2>
 739
 740 <div class="doc_text">
 741
 742 <p>In addition, many APIs have changed in this release.  Some of the major
 743   LLVM API changes are:</p>
 744
 745 <ul>
 746 <li>include/llvm/System merged into include/llvm/Support.</li>
 747 <li>The <a href="http://llvm.org/PR5207">llvm::APInt API</a> was significantly
 748   cleaned up.</li>
 749
 750 <li>In the code generator, MVT::Flag was renamed to MVT::Glue to more accurately
 751   describe its behavior.</li>
 752
 753 <li>The system_error header from C++0x was added, and is now pervasively used to
 754   capture and handle i/o and other errors in LLVM.</li>
 755
 756 <li>The old sys::Path API has been deprecated in favor of the new PathV2 API,
 757     which is more efficient and flexible.</li>
 758 </ul>
 759 </div>
 760
 761 <!-- *********************************************************************** -->
 762 <h1>
 763   <a name="knownproblems">Known Problems</a>
 764 </h1>
 765 <!-- *********************************************************************** -->
 766
 767 <div class="doc_text">
 768
 769 <p>This section contains significant known problems with the LLVM system,
 770 listed by component.  If you run into a problem, please check the <a
 771 href="http://llvm.org/bugs/">LLVM bug database</a> and submit a bug if
 772 there isn't already one.</p>
 773
 774 </div>
 775
 776 <!-- ======================================================================= -->
 777 <h2>
 778   <a name="experimental">Experimental features included with this release</a>
 779 </h2>
 780
 781 <div class="doc_text">
 782
 783 <p>The following components of this LLVM release are either untested, known to
 784 be broken or unreliable, or are in early development.  These components should
 785 not be relied on, and bugs should not be filed against them, but they may be
 786 useful to some people.  In particular, if you would like to work on one of these
 787 components, please contact us on the <a
 788 href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev list</a>.</p>
 789
 790 <ul>
 791 <li>The Alpha, Blackfin, CellSPU, MicroBlaze, MSP430, MIPS, PTX, SystemZ
 792     and XCore backends are experimental.</li>
 793 <li><tt>llc</tt> "<tt>-filetype=obj</tt>" is experimental on all targets
 794     other than darwin and ELF X86 systems.</li>
 795
 796 </ul>
 797
 798 </div>
 799
 800 <!-- ======================================================================= -->
 801 <h2>
 802   <a name="x86-be">Known problems with the X86 back-end</a>
 803 </h2>
 804
 805 <div class="doc_text">
 806
 807 <ul>
 808   <li>The X86 backend does not yet support
 809     all <a href="http://llvm.org/PR879">inline assembly that uses the X86
 810     floating point stack</a>.  It supports the 'f' and 't' constraints, but not
 811     'u'.</li>
 812   <li>The X86-64 backend does not yet support the LLVM IR instruction
 813       <tt>va_arg</tt>. Currently, front-ends support variadic
 814       argument constructs on X86-64 by lowering them manually.</li>
 815   <li>Windows x64 (aka Win64) code generator has a few issues.
 816     <ul>
 817       <li>llvm-gcc cannot build the mingw-w64 runtime currently
 818        due to lack of support for the 'u' inline assembly
 819        constraint and for X87 floating point inline assembly.</li>
 820       <li>On mingw-w64, you will see unresolved symbol <tt>__chkstk</tt>
 821        due to <a href="http://llvm.org/bugs/show_bug.cgi?id=8919">Bug 8919</a>.
 822        It is fixed in <a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110321/118499.html">r128206</a>.</li>
 823       <li>Miss-aligned MOVDQA might crash your program. It is due to
 824        <a href="http://llvm.org/bugs/show_bug.cgi?id=9483">Bug 9483</a>,
 825        lack of handling aligned internal globals.</li>
 826       </ul>
 827   </li>
 828
 829 </ul>
 830
 831 </div>
 832
 833 <!-- ======================================================================= -->
 834 <h2>
 835   <a name="ppc-be">Known problems with the PowerPC back-end</a>
 836 </h2>
 837
 838 <div class="doc_text">
 839
 840 <ul>
 841 <li>The Linux PPC32/ABI support needs testing for the interpreter and static
 842 compilation, and lacks support for debug information.</li>
 843 </ul>
 844
 845 </div>
 846
 847 <!-- ======================================================================= -->
 848 <h2>
 849   <a name="arm-be">Known problems with the ARM back-end</a>
 850 </h2>
 851
 852 <div class="doc_text">
 853
 854 <ul>
 855 <li>Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6
 856 processors, thumb programs can crash or produce wrong
 857 results (<a href="http://llvm.org/PR1388">PR1388</a>).</li>
 858 <li>Compilation for ARM Linux OABI (old ABI) is supported but not fully tested.
 859 </li>
 860 </ul>
 861
 862 </div>
 863
 864 <!-- ======================================================================= -->
 865 <h2>
 866   <a name="sparc-be">Known problems with the SPARC back-end</a>
 867 </h2>
 868
 869 <div class="doc_text">
 870
 871 <ul>
 872 <li>The SPARC backend only supports the 32-bit SPARC ABI (-m32); it does not
 873     support the 64-bit SPARC ABI (-m64).</li>
 874 </ul>
 875
 876 </div>
 877
 878 <!-- ======================================================================= -->
 879 <h2>
 880   <a name="mips-be">Known problems with the MIPS back-end</a>
 881 </h2>
 882
 883 <div class="doc_text">
 884
 885 <ul>
 886 <li>64-bit MIPS targets are not supported yet.</li>
 887 </ul>
 888
 889 </div>
 890
 891 <!-- ======================================================================= -->
 892 <h2>
 893   <a name="alpha-be">Known problems with the Alpha back-end</a>
 894 </h2>
 895
 896 <div class="doc_text">
 897
 898 <ul>
 899
 900 <li>On 21164s, some rare FP arithmetic sequences which may trap do not have the
 901 appropriate nops inserted to ensure restartability.</li>
 902
 903 </ul>
 904 </div>
 905
 906 <!-- ======================================================================= -->
 907 <h2>
 908   <a name="c-be">Known problems with the C back-end</a>
 909 </h2>
 910
 911 <div class="doc_text">
 912
 913 <p>The C backend has numerous problems and is not being actively maintained.
 914 Depending on it for anything serious is not advised.</p>
 915
 916 <ul>
 917 <li><a href="http://llvm.org/PR802">The C backend has only basic support for
 918     inline assembly code</a>.</li>
 919 <li><a href="http://llvm.org/PR1658">The C backend violates the ABI of common
 920     C++ programs</a>, preventing intermixing between C++ compiled by the CBE and
 921     C++ code compiled with <tt>llc</tt> or native compilers.</li>
 922 <li>The C backend does not support all exception handling constructs.</li>
 923 <li>The C backend does not support arbitrary precision integers.</li>
 924 </ul>
 925
 926 </div>
 927
 928
 929 <!-- ======================================================================= -->
 930 <h2>
 931   <a name="llvm-gcc">Known problems with the llvm-gcc front-end</a>
 932 </h2>
 933
 934 <div class="doc_text">
 935
 936 <p><b>LLVM 2.9 will be the last release of llvm-gcc.</b></p>
 937
 938 <p>llvm-gcc is generally very stable for the C family of languages.  The only
 939    major language feature of GCC not supported by llvm-gcc is the
 940    <tt>__builtin_apply</tt> family of builtins.   However, some extensions
 941    are only supported on some targets.  For example, trampolines are only
 942    supported on some targets (these are used when you take the address of a
 943    nested function).</p>
 944
 945 <p>Fortran support generally works, but there are still several unresolved bugs
 946    in <a href="http://llvm.org/bugs/">Bugzilla</a>.  Please see the
 947    tools/gfortran component for details.  Note that llvm-gcc is missing major
 948    Fortran performance work in the frontend and library that went into GCC after
 949    4.2.  If you are interested in Fortran, we recommend that you consider using
 950    <a href="#dragonegg">dragonegg</a> instead.</p>
 951
 952 <p>The llvm-gcc 4.2 Ada compiler has basic functionality, but is no longer being
 953 actively maintained.  If you are interested in Ada, we recommend that you
 954 consider using <a href="#dragonegg">dragonegg</a> instead.</p>
 955 </div>
 956
 957 <!-- *********************************************************************** -->
 958 <h1>
 959   <a name="additionalinfo">Additional Information</a>
 960 </h1>
 961 <!-- *********************************************************************** -->
 962
 963 <div class="doc_text">
 964
 965 <p>A wide variety of additional information is available on the <a
 966 href="http://llvm.org">LLVM web page</a>, in particular in the <a
 967 href="http://llvm.org/docs/">documentation</a> section.  The web page also
 968 contains versions of the API documentation which is up-to-date with the
 969 Subversion version of the source code.
 970 You can access versions of these documents specific to this release by going
 971 into the "<tt>llvm/doc/</tt>" directory in the LLVM tree.</p>
 972
 973 <p>If you have any questions or comments about LLVM, please feel free to contact
 974 us via the <a href="http://llvm.org/docs/#maillist"> mailing
 975 lists</a>.</p>
 976
 977 </div>
 978
 979 <!-- *********************************************************************** -->
 980
 981 <hr>
 982 <address>
 983   <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
 984   src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
 985   <a href="http://validator.w3.org/check/referer"><img
 986   src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
 987
 988   <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br>
 989   Last modified: $Date$
 990 </address>
 991
 992 </body>
 993 </html>