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