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