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.8 Release Notes</title>
   8 </head>
   9 <body>
  10
  11 <div class="doc_title">LLVM 2.8 Release Notes</div>
  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.8</a></li>
  20   <li><a href="#whatsnew">What's New in LLVM 2.8?</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.8
  32 release.<br>
  33 You may prefer the
  34 <a href="http://llvm.org/releases/2.7/docs/ReleaseNotes.html">LLVM 2.7
  35 Release Notes</a>.</h1>
  36 -->
  37
  38 <!-- *********************************************************************** -->
  39 <div class="doc_section">
  40   <a name="intro">Introduction</a>
  41 </div>
  42 <!-- *********************************************************************** -->
  43
  44 <div class="doc_text">
  45
  46 <p>This document contains the release notes for the LLVM Compiler
  47 Infrastructure, release 2.8.  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
  66 <!--
  67 Almost dead code.
  68   include/llvm/Analysis/LiveValues.h => Dan
  69   lib/Transforms/IPO/MergeFunctions.cpp => consider for 2.8.
  70   GEPSplitterPass
  71 -->
  72
  73
  74 <!-- Features that need text if they're finished for 2.9:
  75   combiner-aa?
  76   strong phi elim
  77   loop dependence analysis
  78   TBAA
  79   CorrelatedValuePropagation
  80  -->
  81
  82  <!-- Announcement, lldb, libc++ -->
  83
  84
  85 <!-- *********************************************************************** -->
  86 <div class="doc_section">
  87   <a name="subproj">Sub-project Status Update</a>
  88 </div>
  89 <!-- *********************************************************************** -->
  90
  91 <div class="doc_text">
  92 <p>
  93 The LLVM 2.8 distribution currently consists of code from the core LLVM
  94 repository (which roughly includes the LLVM optimizers, code generators
  95 and supporting tools), the Clang repository and the llvm-gcc repository.  In
  96 addition to this code, the LLVM Project includes other sub-projects that are in
  97 development.  Here we include updates on these subprojects.
  98 </p>
  99
 100 </div>
 101
 102
 103 <!--=========================================================================-->
 104 <div class="doc_subsection">
 105 <a name="clang">Clang: C/C++/Objective-C Frontend Toolkit</a>
 106 </div>
 107
 108 <div class="doc_text">
 109
 110 <p><a href="http://clang.llvm.org/">Clang</a> is an LLVM front end for the C,
 111 C++, and Objective-C languages. Clang aims to provide a better user experience
 112 through expressive diagnostics, a high level of conformance to language
 113 standards, fast compilation, and low memory use. Like LLVM, Clang provides a
 114 modular, library-based architecture that makes it suitable for creating or
 115 integrating with other development tools. Clang is considered a
 116 production-quality compiler for C, Objective-C, C++ and Objective-C++ on x86
 117 (32- and 64-bit), and for darwin-arm targets.</p>
 118
 119 <p>In the LLVM 2.8 time-frame, the Clang team has made many improvements:</p>
 120
 121 <ul>
 122 <li>Surely these guys have done something</li>
 123 <li>X86-64 abi improvements? Did they make it in?</li>
 124 </ul>
 125 </div>
 126
 127 <!--=========================================================================-->
 128 <div class="doc_subsection">
 129 <a name="clangsa">Clang Static Analyzer</a>
 130 </div>
 131
 132 <div class="doc_text">
 133
 134 <p>The <a href="http://clang-analyzer.llvm.org/">Clang Static Analyzer</a>
 135    project is an effort to use static source code analysis techniques to
 136    automatically find bugs in C and Objective-C programs (and hopefully <a
 137    href="http://clang-analyzer.llvm.org/dev_cxx.html">C++ in the
 138    future</a>!).  The tool is very good at finding bugs that occur on specific
 139    paths through code, such as on error conditions.</p>
 140
 141 <p>The LLVM 2.8 release fixes a number of bugs and slightly improves precision
 142    over 2.7, but there are no major new features in the release.
 143 </p>
 144
 145 </div>
 146
 147 <!--=========================================================================-->
 148 <div class="doc_subsection">
 149 <a name="vmkit">VMKit: JVM/CLI Virtual Machine Implementation</a>
 150 </div>
 151
 152 <div class="doc_text">
 153 <p>
 154 The <a href="http://vmkit.llvm.org/">VMKit project</a> is an implementation of
 155 a JVM and a CLI Virtual Machine (Microsoft .NET is an
 156 implementation of the CLI) using LLVM for static and just-in-time
 157 compilation.</p>
 158
 159 <p>With the release of LLVM 2.8, ...</p>
 160
 161 </div>
 162
 163
 164 <!--=========================================================================-->
 165 <div class="doc_subsection">
 166 <a name="compiler-rt">compiler-rt: Compiler Runtime Library</a>
 167 </div>
 168
 169 <div class="doc_text">
 170 <p>
 171 The new LLVM <a href="http://compiler-rt.llvm.org/">compiler-rt project</a>
 172 is a simple library that provides an implementation of the low-level
 173 target-specific hooks required by code generation and other runtime components.
 174 For example, when compiling for a 32-bit target, converting a double to a 64-bit
 175 unsigned integer is compiled into a runtime call to the "__fixunsdfdi"
 176 function. The compiler-rt library provides highly optimized implementations of
 177 this and other low-level routines (some are 3x faster than the equivalent
 178 libgcc routines).</p>
 179
 180 <p>
 181 All of the code in the compiler-rt project is available under the standard LLVM
 182 License, a "BSD-style" license.  New in LLVM 2.8, compiler_rt now supports
 183 soft floating point (for targets that don't have a real floating point unit),
 184 and includes an extensive testsuite for the "blocks" language feature and the
 185 blocks runtime included in compiler_rt.</p>
 186
 187 </div>
 188
 189 <!--=========================================================================-->
 190 <div class="doc_subsection">
 191 <a name="dragonegg">DragonEgg: llvm-gcc ported to gcc-4.5</a>
 192 </div>
 193
 194 <div class="doc_text">
 195 <p>
 196 <a href="http://dragonegg.llvm.org/">DragonEgg</a> is a port of llvm-gcc to
 197 gcc-4.5.  Unlike llvm-gcc, dragonegg in theory does not require any gcc-4.5
 198 modifications whatsoever (currently one small patch is needed) thanks to the
 199 new <a href="http://gcc.gnu.org/wiki/plugins">gcc plugin architecture</a>.
 200 DragonEgg is a gcc plugin that makes gcc-4.5 use the LLVM optimizers and code
 201 generators instead of gcc's, just like with llvm-gcc.
 202 </p>
 203
 204 <p>
 205 DragonEgg is still a work in progress, but it is able to compile a lot of code,
 206 for example all of gcc, LLVM and clang.  Currently Ada, C, C++ and Fortran work
 207 well, while all other languages either don't work at all or only work poorly.
 208 For the moment only the x86-32 and x86-64 targets are supported, and only on
 209 linux and darwin (darwin may need additional gcc patches).
 210 </p>
 211
 212 <p>
 213 The 2.8 release has the following notable changes:
 214 <ul>
 215 <li>The plugin loads faster due to exporting fewer symbols.</li>
 216 <li>Additional vector operations such as addps256 are now supported.</li>
 217 <li>Ada global variables with no initial value are no longer zero initialized,
 218 resulting in better optimization.</li>
 219 <li>The '-fplugin-arg-dragonegg-enable-gcc-optzns' flag now runs all gcc
 220 optimizers, rather than just a handful.</li>
 221 <li>Fortran programs using common variables now link correctly.</li>
 222 <li>GNU OMP constructs no longer crash the compiler.</li>
 223 </ul>
 224 </p>
 225
 226 </div>
 227
 228
 229 <!--=========================================================================-->
 230 <div class="doc_subsection">
 231 <a name="lldb">LLDB: Low Level Debugger</a>
 232 </div>
 233
 234 <div class="doc_text">
 235 <p>
 236 <a href="http://lldb.llvm.org/">LLDB</a> is</p>
 237
 238 <p>
 239 </p>
 240
 241 <p>
 242 2.8 status here.
 243 </p>
 244
 245 </div>
 246
 247 <!--=========================================================================-->
 248 <div class="doc_subsection">
 249 <a name="libc++">libc++: C++ Standard Library</a>
 250 </div>
 251
 252 <div class="doc_text">
 253 <p>
 254 <a href="http://libc++.llvm.org/">libc++</a> is</p>
 255
 256 <p>
 257 </p>
 258
 259 <p>
 260 2.8 status here.
 261 </p>
 262
 263 </div>
 264
 265
 266 <!-- *********************************************************************** -->
 267 <div class="doc_section">
 268   <a name="externalproj">External Open Source Projects Using LLVM 2.8</a>
 269 </div>
 270 <!-- *********************************************************************** -->
 271
 272 <div class="doc_text">
 273
 274 <p>An exciting aspect of LLVM is that it is used as an enabling technology for
 275    a lot of other language and tools projects.  This section lists some of the
 276    projects that have already been updated to work with LLVM 2.8.</p>
 277 </div>
 278
 279 <!--=========================================================================-->
 280 <div class="doc_subsection">
 281 <a name="tce">TTA-based Codesign Environment (TCE)</a>
 282 </div>
 283
 284 <div class="doc_text">
 285 <p>
 286 <a href="http://tce.cs.tut.fi/">TCE</a> is a toolset for designing
 287 application-specific processors (ASP) based on the Transport triggered
 288 architecture (TTA). The toolset provides a complete co-design flow from C/C++
 289 programs down to synthesizable VHDL and parallel program binaries. Processor
 290 customization points include the register files, function units, supported
 291 operations, and the interconnection network.</p>
 292
 293 <p>TCE uses llvm-gcc/Clang and LLVM for C/C++ language support, target
 294 independent optimizations and also for parts of code generation. It generates
 295 new LLVM-based code generators "on the fly" for the designed TTA processors and
 296 loads them in to the compiler backend as runtime libraries to avoid per-target
 297 recompilation of larger parts of the compiler chain.</p>
 298
 299 </div>
 300
 301 <!--=========================================================================-->
 302 <div class="doc_subsection">
 303 <a name="Horizon">Horizon Bytecode Compiler</a>
 304 </div>
 305
 306 <div class="doc_text">
 307 <p>
 308 <a href="http://www.quokforge.org/projects/horizon">Horizon</a> is a bytecode
 309 language and compiler written on top of LLVM, intended for producing
 310 single-address-space managed code operating systems that
 311 run faster than the equivalent multiple-address-space C systems.
 312 More in-depth blurb is available on <a
 313 href="http://www.quokforge.org/projects/horizon/wiki/Wiki">the wiki</a>.</p>
 314
 315 </div>
 316
 317 <!--=========================================================================-->
 318 <div class="doc_subsection">
 319 <a name="clamav">Clam AntiVirus</a>
 320 </div>
 321
 322 <div class="doc_text">
 323 <p>
 324 <a href=http://www.clamav.net>Clam AntiVirus</a> is an open source (GPL)
 325 anti-virus toolkit for UNIX, designed especially for e-mail scanning on mail
 326 gateways.  Since version 0.96 it has <a
 327 href="http://vrt-sourcefire.blogspot.com/2010/09/introduction-to-clamavs-low-level.html">bytecode
 328 signatures</a> that allow writing detections for complex malware. It
 329 uses LLVM's JIT to speed up the execution of bytecode on
 330 X86,X86-64,PPC32/64, falling back to its own interpreter otherwise.
 331 The git version was updated to work with LLVM 2.8
 332 </p>
 333
 334 <p>The <a
 335 href="http://git.clamav.net/gitweb?p=clamav-bytecode-compiler.git;a=blob_plain;f=docs/user/clambc-user.pdf">
 336 ClamAV bytecode compiler</a> uses Clang and LLVM to compile a C-like
 337 language, insert runtime checks, and generate ClamAV bytecode.</p>
 338
 339 </div>
 340
 341 <!--=========================================================================-->
 342 <div class="doc_subsection">
 343 <a name="pure">Pure</a>
 344 </div>
 345
 346 <div class="doc_text">
 347 <p>
 348 <a href="http://pure-lang.googlecode.com/">Pure</a>
 349 is an algebraic/functional
 350 programming language based on term rewriting. Programs are collections
 351 of equations which are used to evaluate expressions in a symbolic
 352 fashion. Pure offers dynamic typing, eager and lazy evaluation, lexical
 353 closures, a hygienic macro system (also based on term rewriting),
 354 built-in list and matrix support (including list and matrix
 355 comprehensions) and an easy-to-use C interface. The interpreter uses
 356 LLVM as a backend to JIT-compile Pure programs to fast native code.</p>
 357
 358 <p>Pure versions 0.44 and later have been tested and are known to work with
 359 LLVM 2.8 (and continue to work with older LLVM releases >= 2.5).</p>
 360
 361 </div>
 362
 363 <!--=========================================================================-->
 364 <div class="doc_subsection">
 365 <a name="GHC">Glasgow Haskell Compiler (GHC)</a>
 366 </div>
 367
 368 <div class="doc_text">
 369 <p>
 370 <a href="http://www.haskell.org/ghc/">GHC</a> is an open source,
 371 state-of-the-art programming suite for
 372 Haskell, a standard lazy functional programming language. It includes
 373 an optimizing static compiler generating good code for a variety of
 374 platforms, together with an interactive system for convenient, quick
 375 development.</p>
 376
 377 <p>In addition to the existing C and native code generators, GHC 7.0 now
 378 supports an <a
 379 href="http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM">LLVM
 380 code generator</a>. GHC supports LLVM 2.7 and later.</p>
 381
 382 </div>
 383
 384 <!--=========================================================================-->
 385 <div class="doc_subsection">
 386 <a name="Clay">Clay Programming Language</a>
 387 </div>
 388
 389 <div class="doc_text">
 390 <p>
 391 <a href="http://tachyon.in/clay/">Clay</a> is a new systems programming
 392 language that is specifically designed for generic programming. It makes
 393 generic programming very concise thanks to whole program type propagation. It
 394 uses LLVM as its backend.</p>
 395
 396 </div>
 397
 398 <!--=========================================================================-->
 399 <div class="doc_subsection">
 400 <a name="llvm-py">llvm-py Python Bindings for LLVM</a>
 401 </div>
 402
 403 <div class="doc_text">
 404 <p>
 405 <a href="http://www.mdevan.org/llvm-py/">llvm-py</a> has been updated to work
 406 with LLVM 2.8.  llvm-py provides Python bindings for LLVM, allowing you to write a
 407 compiler backend or a VM in Python.</p>
 408
 409 </div>
 410
 411
 412
 413 <!-- *********************************************************************** -->
 414 <div class="doc_section">
 415   <a name="whatsnew">What's New in LLVM 2.8?</a>
 416 </div>
 417 <!-- *********************************************************************** -->
 418
 419 <div class="doc_text">
 420
 421 <p>This release includes a huge number of bug fixes, performance tweaks and
 422 minor improvements.  Some of the major improvements and new features are listed
 423 in this section.
 424 </p>
 425
 426 </div>
 427
 428 <!--=========================================================================-->
 429 <div class="doc_subsection">
 430 <a name="orgchanges">LLVM Community Changes</a>
 431 </div>
 432
 433 <div class="doc_text">
 434
 435 <p>In addition to changes to the code, between LLVM 2.7 and 2.8, a number of
 436 organization changes have happened:
 437 </p>
 438
 439 <ul>
 440 <li>libc++ and lldb are new</li>
 441 <li>Debugging optimized code support.</li>
 442 </ul>
 443 </div>
 444
 445 <!--=========================================================================-->
 446 <div class="doc_subsection">
 447 <a name="majorfeatures">Major New Features</a>
 448 </div>
 449
 450 <div class="doc_text">
 451
 452 <p>LLVM 2.8 includes several major new capabilities:</p>
 453
 454 <ul>
 455 <li>llvm-diff</li>
 456 <li>Direct .o file writing support for darwin/x86[64].</li>
 457 </ul>
 458
 459 </div>
 460
 461 <!--=========================================================================-->
 462 <div class="doc_subsection">
 463 <a name="coreimprovements">LLVM IR and Core Improvements</a>
 464 </div>
 465
 466 <div class="doc_text">
 467 <p>LLVM IR has several new features for better support of new targets and that
 468 expose new optimization opportunities:</p>
 469
 470 <ul>
 471
 472   memcpy, memmove, and memset now take address space qualified pointers + volatile.
 473   per-instruction debug info metadata is much faster and uses less space (new DebugLoc class).
 474   New "trap values" concept: http://llvm.org/docs/LangRef.html#trapvalues
 475   New linker_private_weak and linker_private_weak_def_auto linkage types
 476   Triples are now stored in normalized form.  Triple::normalize.
 477
 478 </ul>
 479
 480 </div>
 481
 482 <!--=========================================================================-->
 483 <div class="doc_subsection">
 484 <a name="optimizer">Optimizer Improvements</a>
 485 </div>
 486
 487 <div class="doc_text">
 488
 489 <p>In addition to a large array of minor performance tweaks and bug fixes, this
 490 release includes a few major enhancements and additions to the optimizers:</p>
 491
 492 <ul>
 493
 494 <li></li>
 495   Preliminary work on TBAA but not usable in 2.8.
 496   New CorrelatedValuePropagation pass, not on by default in 2.8 yet.
 497   JumpThreading much more aggressive about implied value relations.
 498   New RegionInfo pass  "opt -regions analyze" or "opt -view-regions".
 499   Improved trip count analysis for <= and >= loops, and uses sign overflow info.
 500   llvm.dbg.value: variable debug info for optimized code
 501   Now iterate function passes when a cgsccpassmanager detects a devirtualization
 502   Atomic lowering patch: -loweratomic (see Passes.html#loweratomic)
 503
 504 </ul>
 505
 506 </div>
 507
 508
 509 <!--=========================================================================-->
 510 <div class="doc_subsection">
 511 <a name="executionengine">Interpreter and JIT Improvements</a>
 512 </div>
 513
 514 <div class="doc_text">
 515
 516 <ul>
 517 <li></li>
 518
 519 </ul>
 520
 521 </div>
 522
 523 <!--=========================================================================-->
 524 <div class="doc_subsection">
 525 <a name="mc">MC Level Improvements</a>
 526 </div>
 527
 528 <div class="doc_text">
 529 <p>
 530 The LLVM Machine Code (aka MC) subsystem was created to solve a number
 531 of problems in the realm of assembly, disassembly, object file format handling,
 532 and a number of other related areas that CPU instruction-set level tools work
 533 in.</p>
 534
 535 <p>The MC subproject has made great leaps in LLVM 2.8.  For example, support for
 536    directly writing .o files from LLC (and clang) now works reliably for
 537    darwin/x86[-64] (including inline assembly support) and the integrated
 538    assembler is turned on by default in Clang for these targets.  This provides
 539    improved compile times among other things.</p>
 540
 541 <ul>
 542 <li>The entire compiler has converted over to using the MCStreamer assembler API
 543     instead of writing out a .s file textually.</li>
 544 <li>The "assembler parser" is far more mature than in 2.7, supporting a full
 545     complement of directives, now supports assembler macros, etc.</li>
 546 <li>The "assembler backend" has been completed, including support for relaxation
 547     relocation processing and all the other things that an assembler does.</li>
 548 <li>The MachO file format support is now fully functional and works.</li>
 549 <li>The MC disassembler now fully supports ARM and Thumb.  ARM assembler support
 550     is still in early development though.</li>
 551 <li>The X86 MC assembler now supports the X86 AES and AVX instruction set.</li>
 552 <li>Work on ELF and COFF support is well underway, but isn't useful yet in LLVM
 553     2.8.  Please contact the llvmdev mailing list if you're interested in
 554     this.</li>
 555 </ul>
 556
 557 <p>For more information, please see the <a
 558 href="http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html">Intro to the
 559 LLVM MC Project Blog Post</a>.
 560 </p>
 561
 562 </div>
 563
 564
 565
 566 <!--=========================================================================-->
 567 <div class="doc_subsection">
 568 <a name="codegen">Target Independent Code Generator Improvements</a>
 569 </div>
 570
 571 <div class="doc_text">
 572
 573 <p>We have put a significant amount of work into the code generator
 574 infrastructure, which allows us to implement more aggressive algorithms and make
 575 it run faster:</p>
 576
 577 <ul>
 578 <li></li>
 579
 580   MachineCSE tuned and on by default.
 581
 582   Rewrote tblgen's type inference for backends to be more consistent and
 583      diagnose more target bugs.  This also allows limited support for writing
 584      patterns for instructions that return multiple results, e.g. a virtual
 585      register and a flag result.  Stuff that used 'parallel' before should use
 586      this.
 587
 588   New -regalloc=fast,  =local got removed
 589   New -regalloc=default option that chooses a register allocator based on the -O optimization level.
 590   New SubRegIndex tblgen class for targets -> jakob
 591
 592   Bottom up fast isel.  Simple Load reuse.  No more machinedce.
 593   IR ABI: <3 x float> is passed as <4 x float> instead of 3 floats.
 594
 595   New COPY instruction. copyRegToReg -> copyPhysReg, isMoveInstr is gone.
 596   RenderMachineFunction: -rendermf
 597   SplitKit?
 598   Evan: Teach bottom up pre-ra scheduler to track register pressure. Work in progress.
 599   Evan: Add an ILP scheduler.  On x86_64, this is a win for all tests in CFP2000. It also sped up 256.bzip2 by 16%.
 600
 601   New OptimizeExts+OptimizeCmps -> PeepholeOptimizer pass
 602   New LocalStackSlotAllocation.cpp pass (jimg)
 603   Atomics now get legalized when not natively supported (jim g)
 604
 605   -ffunction-sections and -fdata-sections are supported on ELF targets.
 606   -momit-leaf-frame-pointer now supported.
 607
 608 </ul>
 609 </div>
 610
 611 <!--=========================================================================-->
 612 <div class="doc_subsection">
 613 <a name="x86">X86-32 and X86-64 Target Improvements</a>
 614 </div>
 615
 616 <div class="doc_text">
 617 <p>New features of the X86 target include:
 618 </p>
 619
 620 <ul>
 621 <li>The X86 backend now supports holding X87 floating point stack values
 622     in registers across basic blocks, dramatically improving performance of code
 623     that uses long double, and when targetting CPUs that don't support SSE.</li>
 624
 625   New SSEDomainFix pass:
 626     On Nehalem and newer CPUs there is a 2 cycle latency penalty on using a
 627     register in a different domain than where it was defined. Some instructions
 628     have equvivalents for different domains, like por/orps/orpd.  The
 629     SSEDomainFix pass tries to minimize the number of domain crossings by
 630     changing between equvivalent opcodes where possible.
 631
 632   X86 backend attempts to promote 16-bit integer operations to 32-bits to avoid
 633      0x66 prefixes, which are slow on some microarchitectures and bloat the code
 634      on others.
 635
 636   New support for X86 "thiscall" calling convention (x86_thiscallcc in IR) for windows.
 637
 638   New llvm.x86.int intrinsic (for int $42 and int3)
 639
 640   Verbose assembly decodes X86 shuffle instructions, e.g.:
 641         insertps        $113, %xmm3, %xmm0     ## xmm0 = zero,xmm0[1,2],xmm3[1]
 642         unpcklps        %xmm1, %xmm0    ## xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
 643         pshufd  $1, %xmm1, %xmm1        ## xmm1 = xmm1[1,0,0,0]
 644
 645   X86 ABI:  <2 x float> in IR no longer maps onto MMX, it turns into <4 x float>
 646
 647   new GHC calling convention
 648
 649 </ul>
 650
 651 </div>
 652
 653 <!--=========================================================================-->
 654 <div class="doc_subsection">
 655 <a name="ARM">ARM Target Improvements</a>
 656 </div>
 657
 658 <div class="doc_text">
 659 <p>New features of the ARM target include:
 660 </p>
 661
 662 <ul>
 663
 664   NEON: Better performance for QQQQ (4-consecutive Q register) instructions.  New reg sequence abstraction?
 665   ARM: Better scheduling (list-hybrid, hybrid?)
 666   ARM: Tail call support.
 667   ARM: General performance work and tuning.
 668
 669   ARM: Half float support through intrinsics LangRef.html#int_fp16
 670 <li>ARMGlobalMerge: <!-- Anton --> </li>
 671
 672 <li>The ARM NEON intrinsics have been substantially reworked to reduce
 673     redundancy and improve code generation.  Some of the major changes are:
 674   <ol>
 675   <li>
 676     All of the NEON load and store intrinsics (llvm.arm.neon.vld* and
 677     llvm.arm.neon.vst*) take an extra parameter to specify the alignment in bytes
 678     of the memory being accessed.
 679   </li>
 680   <li>
 681     The llvm.arm.neon.vaba intrinsic (vector absolute difference and
 682     accumulate) has been removed.  This operation is now represented using
 683     the llvm.arm.neon.vabd intrinsic (vector absolute difference) followed by a
 684     vector add.
 685   </li>
 686   <li>
 687     The llvm.arm.neon.vabdl and llvm.arm.neon.vabal intrinsics (lengthening
 688     vector absolute difference with and without accumlation) have been removed.
 689     They are represented using the llvm.arm.neon.vabd intrinsic (vector absolute
 690     difference) followed by a vector zero-extend operation, and for vabal,
 691     a vector add.
 692   </li>
 693   <li>
 694     The llvm.arm.neon.vmovn intrinsic has been removed.  Calls of this intrinsic
 695     are now replaced by vector truncate operations.
 696   </li>
 697   <li>
 698     The llvm.arm.neon.vmovls and llvm.arm.neon.vmovlu intrinsics have been
 699     removed.  They are now represented as vector sign-extend (vmovls) and
 700     zero-extend (vmovlu) operations.
 701   </li>
 702   <li>
 703     The llvm.arm.neon.vaddl*, llvm.arm.neon.vaddw*, llvm.arm.neon.vsubl*, and
 704     llvm.arm.neon.vsubw* intrinsics (lengthening vector add and subtract) have
 705     been removed.  They are replaced by vector add and vector subtract operations
 706     where one (vaddw, vsubw) or both (vaddl, vsubl) of the operands are either
 707     sign-extended or zero-extended.
 708   </li>
 709   <li>
 710     The llvm.arm.neon.vmulls, llvm.arm.neon.vmullu, llvm.arm.neon.vmlal*, and
 711     llvm.arm.neon.vmlsl* intrinsics (lengthening vector multiply with and without
 712     accumulation and subtraction) have been removed.  These operations are now
 713     represented as vector multiplications where the operands are either
 714     sign-extended or zero-extended, followed by a vector add for vmlal or a
 715     vector subtract for vmlsl.  Note that the polynomial vector multiply
 716     intrinsic, llvm.arm.neon.vmullp, remains unchanged.
 717   </li>
 718   </ol>
 719 </li>
 720 </ul>
 721 </div>
 722
 723 <!--=========================================================================-->
 724 <div class="doc_subsection">
 725 <a name="newapis">New Useful APIs</a>
 726 </div>
 727
 728 <div class="doc_text">
 729
 730 <p>This release includes a number of new APIs that are used internally, which
 731    may also be useful for external clients.
 732 </p>
 733
 734 <ul>
 735 <li></li>
 736 </ul>
 737
 738
 739 </div>
 740
 741 <!--=========================================================================-->
 742 <div class="doc_subsection">
 743 <a name="otherimprovements">Other Improvements and New Features</a>
 744 </div>
 745
 746 <div class="doc_text">
 747 <p>Other miscellaneous features include:</p>
 748
 749 <ul>
 750 <li></li>
 751 </ul>
 752
 753 </div>
 754
 755
 756 <!--=========================================================================-->
 757 <div class="doc_subsection">
 758 <a name="changes">Major Changes and Removed Features</a>
 759 </div>
 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.7, this section lists some "gotchas" that you may run into upgrading
 765 from the previous release.</p>
 766
 767
 768   renamed "Release" -> "Release+Asserts"; "Release-Asserts" -> "Release etc.
 769
 770
 771 <ul>
 772 <li>.ll file doesn't produce #uses comments anymore, to get them, run a .bc file
 773    through "llvm-dis --show-annotations".</li>
 774 <li>MSIL Backend removed.</li>
 775 <li>ABCD and SSI passes removed.</li>
 776 <li>'Union' LLVM IR feature removed.</li>
 777 <li>SCCVN pass removed.</li>
 778 </ul>
 779
 780 <p>In addition, many APIs have changed in this release.  Some of the major LLVM
 781 API changes are:</p>
 782 <ul>
 783
 784   RegisterPass<> -> INTIALIZE_PASS()
 785
 786
 787
 788 <li>LLVM 2.8 changes the internal order of operands in <a
 789   href="http://llvm.org/doxygen/classllvm_1_1InvokeInst.html"><tt>InvokeInst</tt></a>
 790   and <a href="http://llvm.org/doxygen/classllvm_1_1CallInst.html"><tt>CallInst</tt></a>.
 791   To be portable across releases, resort to <tt>CallSite</tt> and the
 792   high-level accessors, such as <tt>getCalledValue</tt> and <tt>setUnwindDest</tt>.
 793 </li>
 794 <li>
 795   You can no longer pass use_iterators directly to cast<> (and similar), because
 796   these routines tend to perform costly dereference operations more than once. You
 797   have to dereference the iterators yourself and pass them in.
 798 </li>
 799 <li>
 800   llvm.memcpy.*, llvm.memset.*, llvm.memmove.* (and possibly other?) intrinsics
 801   take an extra parameter now (i1 isVolatile), totaling 5 parameters.
 802   If you were creating these intrinsic calls and prototypes yourself (as opposed
 803   to using Intrinsic::getDeclaration), you can use UpgradeIntrinsicFunction/UpgradeIntrinsicCall
 804   to be portable accross releases.
 805   Note that you cannot use Intrinsic::getDeclaration() in a backwards compatible
 806   way (needs 2/3 types now, in 2.7 it needed just 1).
 807 </li>
 808 <li>
 809   SetCurrentDebugLocation takes a DebugLoc now instead of a MDNode.
 810   Change your code to use
 811   SetCurrentDebugLocation(DebugLoc::getFromDILocation(...)).
 812 </li>
 813 <li>
 814   VISIBILITY_HIDDEN is gone.
 815 </li>
 816 <li>
 817   The <tt>RegisterPass</tt> and <tt>RegisterAnalysisGroup</tt> templates are
 818   considered deprecated, but continue to function in LLVM 2.8.  Clients are
 819   strongly advised to use the upcoming <tt>INITIALIZE_PASS()</tt> and
 820   <tt>INITIALIZE_AG_PASS()</tt> macros instead.
 821 <li>
 822   SMDiagnostic takes different parameters now. //FIXME: how to upgrade?
 823 </li>
 824 <li>
 825   The constructor for the Triple class no longer tries to understand odd triple
 826   specifications.  Frontends should ensure that they only pass valid triples to
 827   LLVM.  The Triple::normalize utility method has been added to help front-ends
 828   deal with funky triples.
 829 <li>
 830   Some APIs got renamed:
 831   <ul>
 832       <li>llvm_report_error -&gt; report_fatal_error</li>
 833       <li>llvm_install_error_handler -&gt; install_fatal_error_handler</li>
 834       <li>llvm::DwarfExceptionHandling -&gt; llvm::JITExceptionHandling</li>
 835   </ul>
 836 </li>
 837
 838 </ul>
 839
 840 </div>
 841
 842
 843 <!-- *********************************************************************** -->
 844 <div class="doc_section">
 845   <a name="knownproblems">Known Problems</a>
 846 </div>
 847 <!-- *********************************************************************** -->
 848
 849 <div class="doc_text">
 850
 851 <p>This section contains significant known problems with the LLVM system,
 852 listed by component.  If you run into a problem, please check the <a
 853 href="http://llvm.org/bugs/">LLVM bug database</a> and submit a bug if
 854 there isn't already one.</p>
 855
 856 </div>
 857
 858 <!-- ======================================================================= -->
 859 <div class="doc_subsection">
 860   <a name="experimental">Experimental features included with this release</a>
 861 </div>
 862
 863 <div class="doc_text">
 864
 865 <p>The following components of this LLVM release are either untested, known to
 866 be broken or unreliable, or are in early development.  These components should
 867 not be relied on, and bugs should not be filed against them, but they may be
 868 useful to some people.  In particular, if you would like to work on one of these
 869 components, please contact us on the <a
 870 href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev list</a>.</p>
 871
 872 <ul>
 873 <li>The Alpha, SPU, MIPS, PIC16, Blackfin, MSP430, SystemZ and MicroBlaze
 874     backends are experimental.</li>
 875 <li><tt>llc</tt> "<tt>-filetype=obj</tt>" is experimental on all targets
 876     other than darwin-i386 and darwin-x86_64.</li>
 877 </ul>
 878
 879 </div>
 880
 881 <!-- ======================================================================= -->
 882 <div class="doc_subsection">
 883   <a name="x86-be">Known problems with the X86 back-end</a>
 884 </div>
 885
 886 <div class="doc_text">
 887
 888 <ul>
 889   <li>The X86 backend does not yet support
 890     all <a href="http://llvm.org/PR879">inline assembly that uses the X86
 891     floating point stack</a>.  It supports the 'f' and 't' constraints, but not
 892     'u'.</li>
 893   <li>Win64 code generation wasn't widely tested. Everything should work, but we
 894     expect small issues to happen. Also, llvm-gcc cannot build the mingw64
 895     runtime currently due to lack of support for the 'u' inline assembly
 896     constraint and for X87 floating point inline assembly.</li>
 897   <li>The X86-64 backend does not yet support the LLVM IR instruction
 898       <tt>va_arg</tt>. Currently, front-ends support variadic
 899       argument constructs on X86-64 by lowering them manually.</li>
 900 </ul>
 901
 902 </div>
 903
 904 <!-- ======================================================================= -->
 905 <div class="doc_subsection">
 906   <a name="ppc-be">Known problems with the PowerPC back-end</a>
 907 </div>
 908
 909 <div class="doc_text">
 910
 911 <ul>
 912 <li>The Linux PPC32/ABI support needs testing for the interpreter and static
 913 compilation, and lacks support for debug information.</li>
 914 </ul>
 915
 916 </div>
 917
 918 <!-- ======================================================================= -->
 919 <div class="doc_subsection">
 920   <a name="arm-be">Known problems with the ARM back-end</a>
 921 </div>
 922
 923 <div class="doc_text">
 924
 925 <ul>
 926 <li>Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6
 927 processors, thumb programs can crash or produce wrong
 928 results (<a href="http://llvm.org/PR1388">PR1388</a>).</li>
 929 <li>Compilation for ARM Linux OABI (old ABI) is supported but not fully tested.
 930 </li>
 931 </ul>
 932
 933 </div>
 934
 935 <!-- ======================================================================= -->
 936 <div class="doc_subsection">
 937   <a name="sparc-be">Known problems with the SPARC back-end</a>
 938 </div>
 939
 940 <div class="doc_text">
 941
 942 <ul>
 943 <li>The SPARC backend only supports the 32-bit SPARC ABI (-m32); it does not
 944     support the 64-bit SPARC ABI (-m64).</li>
 945 </ul>
 946
 947 </div>
 948
 949 <!-- ======================================================================= -->
 950 <div class="doc_subsection">
 951   <a name="mips-be">Known problems with the MIPS back-end</a>
 952 </div>
 953
 954 <div class="doc_text">
 955
 956 <ul>
 957 <li>64-bit MIPS targets are not supported yet.</li>
 958 </ul>
 959
 960 </div>
 961
 962 <!-- ======================================================================= -->
 963 <div class="doc_subsection">
 964   <a name="alpha-be">Known problems with the Alpha back-end</a>
 965 </div>
 966
 967 <div class="doc_text">
 968
 969 <ul>
 970
 971 <li>On 21164s, some rare FP arithmetic sequences which may trap do not have the
 972 appropriate nops inserted to ensure restartability.</li>
 973
 974 </ul>
 975 </div>
 976
 977 <!-- ======================================================================= -->
 978 <div class="doc_subsection">
 979   <a name="c-be">Known problems with the C back-end</a>
 980 </div>
 981
 982 <div class="doc_text">
 983
 984 <p>The C backend has numerous problems and is not being actively maintained.
 985 Depending on it for anything serious is not advised.</p>
 986
 987 <ul>
 988 <li><a href="http://llvm.org/PR802">The C backend has only basic support for
 989     inline assembly code</a>.</li>
 990 <li><a href="http://llvm.org/PR1658">The C backend violates the ABI of common
 991     C++ programs</a>, preventing intermixing between C++ compiled by the CBE and
 992     C++ code compiled with <tt>llc</tt> or native compilers.</li>
 993 <li>The C backend does not support all exception handling constructs.</li>
 994 <li>The C backend does not support arbitrary precision integers.</li>
 995 </ul>
 996
 997 </div>
 998
 999
1000 <!-- ======================================================================= -->
1001 <div class="doc_subsection">
1002   <a name="llvm-gcc">Known problems with the llvm-gcc front-end</a>
1003 </div>
1004
1005 <div class="doc_text">
1006
1007 <p>llvm-gcc is generally very stable for the C family of languages.  The only
1008    major language feature of GCC not supported by llvm-gcc is the
1009    <tt>__builtin_apply</tt> family of builtins.   However, some extensions
1010    are only supported on some targets.  For example, trampolines are only
1011    supported on some targets (these are used when you take the address of a
1012    nested function).</p>
1013
1014 <p>Fortran support generally works, but there are still several unresolved bugs
1015    in <a href="http://llvm.org/bugs/">Bugzilla</a>.  Please see the
1016    tools/gfortran component for details.  Note that llvm-gcc is missing major
1017    Fortran performance work in the frontend and library that went into GCC after
1018    4.2.  If you are interested in Fortran, we recommend that you consider using
1019    <a href="#dragonegg">dragonegg</a> instead.</p>
1020
1021 <p>The llvm-gcc 4.2 Ada compiler has basic functionality. However, this is not a
1022 mature technology, and problems should be expected.  For example:</p>
1023 <ul>
1024 <li>The Ada front-end currently only builds on X86-32.  This is mainly due
1025 to lack of trampoline support (pointers to nested functions) on other platforms.
1026 However, it <a href="http://llvm.org/PR2006">also fails to build on X86-64</a>
1027 which does support trampolines.</li>
1028 <li>The Ada front-end <a href="http://llvm.org/PR2007">fails to bootstrap</a>.
1029 This is due to lack of LLVM support for <tt>setjmp</tt>/<tt>longjmp</tt> style
1030 exception handling, which is used internally by the compiler.
1031 Workaround: configure with <tt>--disable-bootstrap</tt>.</li>
1032 <li>The c380004, <a href="http://llvm.org/PR2010">c393010</a>
1033 and <a href="http://llvm.org/PR2421">cxg2021</a> ACATS tests fail
1034 (c380004 also fails with gcc-4.2 mainline).
1035 If the compiler is built with checks disabled then <a href="http://llvm.org/PR2010">c393010</a>
1036 causes the compiler to go into an infinite loop, using up all system memory.</li>
1037 <li>Some GCC specific Ada tests continue to crash the compiler.</li>
1038 <li>The <tt>-E</tt> binder option (exception backtraces)
1039 <a href="http://llvm.org/PR1982">does not work</a> and will result in programs
1040 crashing if an exception is raised.  Workaround: do not use <tt>-E</tt>.</li>
1041 <li>Only discrete types <a href="http://llvm.org/PR1981">are allowed to start
1042 or finish at a non-byte offset</a> in a record.  Workaround: do not pack records
1043 or use representation clauses that result in a field of a non-discrete type
1044 starting or finishing in the middle of a byte.</li>
1045 <li>The <tt>lli</tt> interpreter <a href="http://llvm.org/PR2009">considers
1046 'main' as generated by the Ada binder to be invalid</a>.
1047 Workaround: hand edit the file to use pointers for <tt>argv</tt> and
1048 <tt>envp</tt> rather than integers.</li>
1049 <li>The <tt>-fstack-check</tt> option <a href="http://llvm.org/PR2008">is
1050 ignored</a>.</li>
1051 </ul>
1052 </div>
1053
1054 <!-- *********************************************************************** -->
1055 <div class="doc_section">
1056   <a name="additionalinfo">Additional Information</a>
1057 </div>
1058 <!-- *********************************************************************** -->
1059
1060 <div class="doc_text">
1061
1062 <p>A wide variety of additional information is available on the <a
1063 href="http://llvm.org">LLVM web page</a>, in particular in the <a
1064 href="http://llvm.org/docs/">documentation</a> section.  The web page also
1065 contains versions of the API documentation which is up-to-date with the
1066 Subversion version of the source code.
1067 You can access versions of these documents specific to this release by going
1068 into the "<tt>llvm/doc/</tt>" directory in the LLVM tree.</p>
1069
1070 <p>If you have any questions or comments about LLVM, please feel free to contact
1071 us via the <a href="http://llvm.org/docs/#maillist"> mailing
1072 lists</a>.</p>
1073
1074 </div>
1075
1076 <!-- *********************************************************************** -->
1077
1078 <hr>
1079 <address>
1080   <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
1081   src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
1082   <a href="http://validator.w3.org/check/referer"><img
1083   src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
1084
1085   <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br>
1086   Last modified: $Date$
1087 </address>
1088
1089 </body>
1090 </html>