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