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.7 Release Notes</title>
   8 </head>
   9 <body>
  10
  11 <div class="doc_title">LLVM 2.7 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.7</a></li>
  20   <li><a href="#whatsnew">What's New in LLVM 2.7?</a></li>
  21   <li><a href="GettingStarted.html">Installation Instructions</a></li>
  22   <li><a href="#portability">Portability and Supported Platforms</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.8
  33 release.<br>
  34 You may prefer the
  35 <a href="http://llvm.org/releases/2.6/docs/ReleaseNotes.html">LLVM 2.7
  36 Release Notes</a>.</h1>-->
  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.7.  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   llvm/Analysis/PointerTracking.h => Edwin wants this, consider for 2.8.
  71   ABCD, GEPSplitterPass
  72   MSIL backend?
  73   lib/Transforms/Utils/SSI.cpp  -> ABCD depends on it.
  74 -->
  75
  76
  77 <!-- Features that need text if they're finished for 2.7:
  78   combiner-aa?
  79   strong phi elim
  80   llvm.dbg.value: variable debug info for optimized code
  81   loop dependence analysis
  82  -->
  83
  84  <!-- for announcement email:
  85  Logo web page.
  86  llvm devmtg
  87  compiler_rt
  88  KLEE web page at klee.llvm.org
  89  Many new papers added to /pubs/
  90  Mention gcc plugin.
  91    -->
  92
  93 <!-- *********************************************************************** -->
  94 <div class="doc_section">
  95   <a name="subproj">Sub-project Status Update</a>
  96 </div>
  97 <!-- *********************************************************************** -->
  98
  99 <div class="doc_text">
 100 <p>
 101 The LLVM 2.7 distribution currently consists of code from the core LLVM
 102 repository (which roughly includes the LLVM optimizers, code generators
 103 and supporting tools), the Clang repository and the llvm-gcc repository.  In
 104 addition to this code, the LLVM Project includes other sub-projects that are in
 105 development.  Here we include updates on these subprojects.
 106 </p>
 107
 108 </div>
 109
 110
 111 <!--=========================================================================-->
 112 <div class="doc_subsection">
 113 <a name="clang">Clang: C/C++/Objective-C Frontend Toolkit</a>
 114 </div>
 115
 116 <div class="doc_text">
 117
 118 <p><a href="http://clang.llvm.org/">Clang</a> is an LLVM front end for the C,
 119 C++, and Objective-C languages. Clang aims to provide a better user experience
 120 through expressive diagnostics, a high level of conformance to language
 121 standards, fast compilation, and low memory use. Like LLVM, Clang provides a
 122 modular, library-based architecture that makes it suitable for creating or
 123 integrating with other development tools. Clang is considered a
 124 production-quality compiler for C and Objective-C on x86 (32- and 64-bit).</p>
 125
 126 <p>In the LLVM 2.7 time-frame, the Clang team has made many improvements:</p>
 127
 128 <ul>
 129
 130 <li>C++ Support: Clang is now capable of self-hosting! While still
 131 alpha-quality, Clang's C++ support has matured enough to build LLVM and Clang,
 132 and C++ is now enabled by default. See the <a
 133 href="http://clang.llvm.org/cxx_compatibility.html">Clang C++ compatibility
 134 page</a> for common C++ migration issues.</li>
 135
 136 <li>Objective-C: Clang now includes experimental support for an updated
 137 Objective-C ABI on non-Darwin platforms.  This includes support for non-fragile
 138 instance variables and accelerated proxies, as well as greater potential for
 139 future optimisations.  The new ABI is used when compiling with the
 140 -fobjc-nonfragile-abi and -fgnu-runtime options.  Code compiled with these
 141 options may be mixed with code compiled with GCC or clang using the old GNU ABI,
 142 but requires the libobjc2 runtime from the GNUstep project.</li>
 143
 144 <li>New warnings: Clang contains a number of new warnings, including
 145 control-flow warnings (unreachable code, missing return statements in a
 146 non-<code>void</code> function, etc.), sign-comparison warnings, and improved
 147 format-string warnings.</li>
 148
 149 <li>CIndex API and Python bindings: Clang now includes a C API as part of the
 150 CIndex library. Although we may make some changes to the API in the future, it
 151 is intended to be stable and has been designed for use by external projects. See
 152 the Clang
 153 doxygen <a href="http://clang.llvm.org/doxygen/group__CINDEX.html">CIndex</a>
 154 documentation for more details. The CIndex API also includes a preliminary
 155 set of Python bindings.</li>
 156
 157 <li>ARM Support: Clang now has ABI support for both the Darwin and Linux ARM
 158 ABIs. Coupled with many improvements to the LLVM ARM backend, Clang is now
 159 suitable for use as a beta quality ARM compiler.</li>
 160
 161 </ul>
 162 </div>
 163
 164 <!--=========================================================================-->
 165 <div class="doc_subsection">
 166 <a name="clangsa">Clang Static Analyzer</a>
 167 </div>
 168
 169 <div class="doc_text">
 170
 171 <p>The <a href="http://clang-analyzer.llvm.org/">Clang Static Analyzer</a>
 172    project is an effort to use static source code analysis techniques to
 173    automatically find bugs in C and Objective-C programs (and hopefully <a
 174    href="http://clang-analyzer.llvm.org/dev_cxx.html">C++ in the
 175    future</a>!).  The tool is very good at finding bugs that occur on specific
 176    paths through code, such as on error conditions.</p>
 177
 178 <p>In the LLVM 2.7 time-frame, the analyzer core has made several major and
 179    minor improvements, including better support for tracking the fields of
 180    structures, initial support (not enabled by default yet) for doing
 181    interprocedural (cross-function) analysis, and new checks have been added.
 182 </p>
 183
 184 </div>
 185
 186 <!--=========================================================================-->
 187 <div class="doc_subsection">
 188 <a name="vmkit">VMKit: JVM/CLI Virtual Machine Implementation</a>
 189 </div>
 190
 191 <div class="doc_text">
 192 <p>
 193 The <a href="http://vmkit.llvm.org/">VMKit project</a> is an implementation of
 194 a JVM and a CLI Virtual Machine (Microsoft .NET is an
 195 implementation of the CLI) using LLVM for static and just-in-time
 196 compilation.</p>
 197
 198 <p>
 199 With the release of LLVM 2.7, VMKit has shifted to a great framework for writing
 200 virtual machines. VMKit now offers precise and efficient garbage collection with
 201 multi-threading support, thanks to the MMTk memory management toolkit, as well
 202 as just in time and ahead of time compilation with LLVM.  The major changes in
 203 VMKit 0.27 are:</p>
 204
 205 <ul>
 206
 207 <li>Garbage collection: VMKit now uses the MMTk toolkit for garbage collectors.
 208   The first collector to be ported is the MarkSweep collector, which is precise,
 209   and drastically improves the performance of VMKit.</li>
 210 <li>Line number information in the JVM: by using the debug metadata of LLVM, the
 211  JVM now supports precise line number information, useful when printing a stack
 212  trace.</li>
 213 <li>Interface calls in the JVM: we implemented a variant of the Interface Method
 214   Table technique for interface calls in the JVM.
 215 </li>
 216
 217 </ul>
 218 </div>
 219
 220
 221 <!--=========================================================================-->
 222 <div class="doc_subsection">
 223 <a name="compiler-rt">compiler-rt: Compiler Runtime Library</a>
 224 </div>
 225
 226 <div class="doc_text">
 227 <p>
 228 The new LLVM <a href="http://compiler-rt.llvm.org/">compiler-rt project</a>
 229 is a simple library that provides an implementation of the low-level
 230 target-specific hooks required by code generation and other runtime components.
 231 For example, when compiling for a 32-bit target, converting a double to a 64-bit
 232 unsigned integer is compiled into a runtime call to the "__fixunsdfdi"
 233 function. The compiler-rt library provides highly optimized implementations of
 234 this and other low-level routines (some are 3x faster than the equivalent
 235 libgcc routines).</p>
 236
 237 <p>
 238 All of the code in the compiler-rt project is available under the standard LLVM
 239 License, a "BSD-style" license.  New in LLVM 2.7: compiler_rt now
 240 supports ARM targets.</p>
 241
 242 </div>
 243
 244 <!--=========================================================================-->
 245 <div class="doc_subsection">
 246 <a name="dragonegg">DragonEgg: llvm-gcc ported to gcc-4.5</a>
 247 </div>
 248
 249 <div class="doc_text">
 250 <p>
 251 <a href="http://dragonegg.llvm.org/">DragonEgg</a> is a port of llvm-gcc to
 252 gcc-4.5.  Unlike llvm-gcc, which makes many intrusive changes to the underlying
 253 gcc-4.2 code, dragonegg in theory does not require any gcc-4.5 modifications
 254 whatsoever (currently one small patch is needed).  This is thanks to the new
 255 <a href="http://gcc.gnu.org/wiki/plugins">gcc plugin architecture</a>, which
 256 makes it possible to modify the behaviour of gcc at runtime by loading a plugin,
 257 which is nothing more than a dynamic library which conforms to the gcc plugin
 258 interface.  DragonEgg is a gcc plugin that causes the LLVM optimizers to be run
 259 instead of the gcc optimizers, and the LLVM code generators instead of the gcc
 260 code generators, just like llvm-gcc.  To use it, you add
 261 "-fplugin=path/dragonegg.so" to the gcc-4.5 command line, and gcc-4.5 magically
 262 becomes llvm-gcc-4.5!
 263 </p>
 264
 265 <p>
 266 DragonEgg is still a work in progress.  Currently C works very well, while C++,
 267 Ada and Fortran work fairly well.  All other languages either don't work at all,
 268 or only work poorly.  For the moment only the x86-32 and x86-64 targets are
 269 supported, and only on linux and darwin (darwin needs an additional gcc patch).
 270 </p>
 271
 272 <p>
 273 DragonEgg is a new project which is seeing its first release with llvm-2.7.
 274 </p>
 275
 276 </div>
 277
 278
 279 <!--=========================================================================-->
 280 <div class="doc_subsection">
 281 <a name="mc">llvm-mc: Machine Code Toolkit</a>
 282 </div>
 283
 284 <div class="doc_text">
 285 <p>
 286 The LLVM Machine Code (aka MC) sub-project of LLVM was created to solve a number
 287 of problems in the realm of assembly, disassembly, object file format handling,
 288 and a number of other related areas that CPU instruction-set level tools work
 289 in. It is a sub-project of LLVM which provides it with a number of advantages
 290 over other compilers that do not have tightly integrated assembly-level tools.
 291 For a gentle introduction, please see the <a
 292 href="http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html">Intro to the
 293 LLVM MC Project Blog Post</a>.
 294 </p>
 295
 296 <p>2.7 includes major parts of the work required by the new MC Project.  A few
 297    targets have been refactored to support it, and work is underway to support a
 298    native assembler in LLVM.  This work is not complete in LLVM 2.7, but it has
 299    made substantially more progress on LLVM mainline.</p>
 300
 301 <p>One minor example of what MC can do is to transcode an AT&amp;T syntax
 302    X86 .s file into intel syntax.  You can do this with something like:</p>
 303 <pre>
 304   llvm-mc foo.s -output-asm-variant=1 -o foo-intel.s
 305 </pre>
 306
 307 </div>
 308
 309
 310 <!-- *********************************************************************** -->
 311 <div class="doc_section">
 312   <a name="externalproj">External Open Source Projects Using LLVM 2.7</a>
 313 </div>
 314 <!-- *********************************************************************** -->
 315
 316 <div class="doc_text">
 317
 318 <p>An exciting aspect of LLVM is that it is used as an enabling technology for
 319    a lot of other language and tools projects.  This section lists some of the
 320    projects that have already been updated to work with LLVM 2.7.</p>
 321 </div>
 322
 323 <!--=========================================================================-->
 324 <div class="doc_subsection">
 325 <a name="pure">Pure</a>
 326 </div>
 327
 328 <div class="doc_text">
 329 <p>
 330 <a href="http://pure-lang.googlecode.com/">Pure</a>
 331 is an algebraic/functional programming language based on term rewriting.
 332 Programs are collections of equations which are used to evaluate expressions in
 333 a symbolic fashion. Pure offers dynamic typing, eager and lazy evaluation,
 334 lexical closures, a hygienic macro system (also based on term rewriting),
 335 built-in list and matrix support (including list and matrix comprehensions) and
 336 an easy-to-use C interface. The interpreter uses LLVM as a backend to
 337  JIT-compile Pure programs to fast native code.</p>
 338
 339 <p>Pure versions 0.43 and later have been tested and are known to work with
 340 LLVM 2.7 (and continue to work with older LLVM releases >= 2.5).</p>
 341
 342 </div>
 343
 344 <!--=========================================================================-->
 345 <div class="doc_subsection">
 346 <a name="RoadsendPHP">Roadsend PHP</a>
 347 </div>
 348
 349 <div class="doc_text">
 350 <p>
 351 <a href="http://code.roadsend.com/rphp">Roadsend PHP</a> (rphp) is an open
 352 source implementation of the PHP programming
 353 language that uses LLVM for its optimizer, JIT and static compiler. This is a
 354 reimplementation of an earlier project that is now based on LLVM.
 355 </p>
 356 </div>
 357
 358 <!--=========================================================================-->
 359 <div class="doc_subsection">
 360 <a name="UnladenSwallow">Unladen Swallow</a>
 361 </div>
 362
 363 <div class="doc_text">
 364 <p>
 365 <a href="http://code.google.com/p/unladen-swallow/">Unladen Swallow</a> is a
 366 branch of <a href="http://python.org/">Python</a> intended to be fully
 367 compatible and significantly faster.  It uses LLVM's optimization passes and JIT
 368 compiler.
 369 </p>
 370 </div>
 371
 372 <!--=========================================================================-->
 373 <div class="doc_subsection">
 374 <a name="tce">TTA-based Codesign Environment (TCE)</a>
 375 </div>
 376
 377 <div class="doc_text">
 378 <p>
 379 <a href="http://tce.cs.tut.fi/">TCE</a> is a toolset for designing
 380 application-specific processors (ASP) based on the Transport triggered
 381 architecture (TTA). The toolset provides a complete co-design flow from C/C++
 382 programs down to synthesizable VHDL and parallel program binaries. Processor
 383 customization points include the register files, function units, supported
 384 operations, and the interconnection network.</p>
 385
 386 <p>TCE uses llvm-gcc/Clang and LLVM for C/C++ language support, target
 387 independent optimizations and also for parts of code generation. It generates
 388 new LLVM-based code generators "on the fly" for the designed TTA processors and
 389 loads them in to the compiler backend as runtime libraries to avoid per-target
 390 recompilation of larger parts of the compiler chain.</p>
 391
 392 </div>
 393
 394 <!--=========================================================================-->
 395 <div class="doc_subsection">
 396 <a name="safecode">SAFECode Compiler</a>
 397 </div>
 398
 399 <div class="doc_text">
 400 <p>
 401 <a href="http://safecode.cs.illinois.edu">SAFECode</a> is a memory safe C
 402 compiler built using LLVM.  It takes standard, unannotated C code, analyzes the
 403 code to ensure that memory accesses and array indexing operations are safe, and
 404 instruments the code with run-time checks when safety cannot be proven
 405 statically.
 406 </p>
 407 </div>
 408
 409 <!--=========================================================================-->
 410 <div class="doc_subsection">
 411 <a name="icedtea">IcedTea Java Virtual Machine Implementation</a>
 412 </div>
 413
 414 <div class="doc_text">
 415 <p>
 416 <a href="http://icedtea.classpath.org/wiki/Main_Page">IcedTea</a> provides a
 417 harness to build OpenJDK using only free software build tools and to provide
 418 replacements for the not-yet free parts of OpenJDK.  One of the extensions that
 419 IcedTea provides is a new JIT compiler named <a
 420 href="http://icedtea.classpath.org/wiki/ZeroSharkFaq">Shark</a> which uses LLVM
 421 to provide native code generation without introducing processor-dependent
 422 code.
 423 </p>
 424 <p>Icedtea6 1.8 and later have been tested and are known to work with
 425 LLVM 2.7 (and continue to work with older LLVM releases >= 2.6 as well).
 426 </p>
 427 </div>
 428
 429 <!--=========================================================================-->
 430 <div class="doc_subsection">
 431 <a name="llvm-lua">LLVM-Lua</a>
 432 </div>
 433
 434 <div class="doc_text">
 435 <p>
 436 <a href="http://code.google.com/p/llvm-lua/">LLVM-Lua</a> uses LLVM
 437  to add JIT and static compiling support to the Lua VM. Lua
 438 bytecode is analyzed to remove type checks, then LLVM is used to compile the
 439 bytecode down to machine code.
 440 </p>
 441 <p>LLVM-Lua 1.2.0  have been tested and is known to work with LLVM 2.7.
 442 </p>
 443 </div>
 444
 445 <!--=========================================================================-->
 446 <div class="doc_subsection">
 447 <a name="MacRuby">MacRuby</a>
 448 </div>
 449
 450 <div class="doc_text">
 451 <p>
 452 <a href="http://macruby.org">MacRuby</a> is an implementation of Ruby based on
 453 core Mac OS technologies, sponsored by Apple Inc.  It uses LLVM at runtime for
 454 optimization passes, JIT compilation and exception handling. It also allows
 455 static (ahead-of-time) compilation of Ruby code straight to machine code.
 456 </p>
 457 <p>The upcoming MacRuby 0.6 release works with LLVM 2.7.
 458 </p>
 459 </div>
 460
 461 <!--=========================================================================-->
 462 <div class="doc_subsection">
 463 <a name="GHC">Glasgow Haskell Compiler (GHC)</a>
 464 </div>
 465
 466 <div class="doc_text">
 467 <p>
 468 <a href="http://www.haskell.org/ghc/">GHC</a> is an open source,
 469 state-of-the-art programming suite for Haskell, a standard lazy
 470 functional programming language. It includes an optimizing static
 471 compiler generating good code for a variety of platforms, together
 472 with an interactive system for convenient, quick development.</p>
 473
 474 <p>In addition to the existing C and native code generators, GHC now
 475 supports an <a
 476 href="http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM">LLVM
 477 code generator</a>. GHC supports LLVM 2.7.</p>
 478
 479 </div>
 480
 481
 482 <!-- *********************************************************************** -->
 483 <div class="doc_section">
 484   <a name="whatsnew">What's New in LLVM 2.7?</a>
 485 </div>
 486 <!-- *********************************************************************** -->
 487
 488 <div class="doc_text">
 489
 490 <p>This release includes a huge number of bug fixes, performance tweaks and
 491 minor improvements.  Some of the major improvements and new features are listed
 492 in this section.
 493 </p>
 494
 495 </div>
 496
 497 <!--=========================================================================-->
 498 <div class="doc_subsection">
 499 <a name="orgchanges">LLVM Community Changes</a>
 500 </div>
 501
 502 <div class="doc_text">
 503
 504 <p>In addition to changes to the code, between LLVM 2.6 and 2.7, a number of
 505 organization changes have happened:
 506 </p>
 507
 508 <ul>
 509 <li>LLVM has a new <a href="http://llvm.org/Logo.html">official logo</a>!</li>
 510
 511 <li>Ted Kremenek and Doug Gregor have stepped forward as <a
 512  href="http://llvm.org/docs/DeveloperPolicy.html#owners">Code Owners</a> of the
 513  Clang static analyzer and the Clang frontend, respectively.</li>
 514
 515 <li>LLVM now has an <a href="http://blog.llvm.org">official Blog</a> at
 516     <a href="http://blog.llvm.org">http://blog.llvm.org</a>. This is a great way
 517     to learn about new LLVM-related features as they are implemented.  Several
 518     features in this release are already explained on the blog.</li>
 519
 520 <li>The LLVM web pages are now checked into the SVN server, in the "www",
 521     "www-pubs" and "www-releases" SVN modules.  Previously they were hidden in a
 522     largely inaccessible old CVS server.</li>
 523
 524 <li><a href="http://llvm.org">llvm.org</a> is now hosted on a new (and much
 525     faster) server.  It is still graciously hosted at the University of Illinois
 526     of Urbana Champaign.</li>
 527 </ul>
 528 </div>
 529
 530 <!--=========================================================================-->
 531 <div class="doc_subsection">
 532 <a name="majorfeatures">Major New Features</a>
 533 </div>
 534
 535 <div class="doc_text">
 536
 537 <p>LLVM 2.7 includes several major new capabilities:</p>
 538
 539 <ul>
 540 <li>2.7 includes initial support for the <a
 541   href="http://en.wikipedia.org/wiki/MicroBlaze">MicroBlaze</a> target.
 542   MicroBlaze is a soft processor core designed for Xilinx FPGAs.</li>
 543
 544 <li>2.7 includes a new LLVM IR "extensible metadata" feature.  This feature
 545  supports many different use cases, including allowing front-end authors to
 546  encode source level information into LLVM IR, which is consumed by later
 547  language-specific passes.  This is a great way to do high-level optimizations
 548  like devirtualization, type-based alias analysis, etc.  See the <a
 549  href="http://blog.llvm.org/2010/04/extensible-metadata-in-llvm-ir.html">
 550  Extensible Metadata Blog Post</a> for more information.</li>
 551
 552 <li>2.7 encodes <a href="SourceLevelDebugging.html">debug information</a>
 553 in a completely new way, built on extensible metadata.  The new implementation
 554 is much more memory efficient and paves the way for improvements to optimized
 555 code debugging experience.</li>
 556
 557 <li>2.7 now directly supports taking the address of a label and doing an
 558     indirect branch through a pointer.  This is particularly useful for
 559     interpreter loops, and is used to implement the GCC "address of label"
 560     extension.  For more information, see the <a
 561 href="http://blog.llvm.org/2010/01/address-of-label-and-indirect-branches.html">
 562 Address of Label and Indirect Branches in LLVM IR Blog Post</a>.
 563
 564 <li>2.7 is the first release to start supporting APIs for assembling and
 565     disassembling target machine code.  These APIs are useful for a variety of
 566     low level clients, and are surfaced in the new "enhanced disassembly" API.
 567     For more information see the <a
 568     href="http://blog.llvm.org/2010/01/x86-disassembler.html">The X86
 569     Disassembler Blog Post</a> for more information.</li>
 570
 571 <li>2.7 includes major parts of the work required by the new MC Project,
 572     see the <a href="#mc">MC update above</a> for more information.</li>
 573
 574 </ul>
 575
 576 </div>
 577
 578 <!--=========================================================================-->
 579 <div class="doc_subsection">
 580 <a name="coreimprovements">LLVM IR and Core Improvements</a>
 581 </div>
 582
 583 <div class="doc_text">
 584 <p>LLVM IR has several new features for better support of new targets and that
 585 expose new optimization opportunities:</p>
 586
 587 <ul>
 588 <li>LLVM IR now supports a 16-bit "half float" data type through <a
 589    href="LangRef.html#int_fp16">two new intrinsics</a> and APFloat support.</li>
 590 <li>LLVM IR supports two new <a href="LangRef.html#fnattrs">function
 591     attributes</a>: inlinehint and alignstack(n).  The former is a hint to the
 592     optimizer that a function was declared 'inline' and thus the inliner should
 593     weight it higher when considering inlining it.  The later
 594     indicates to the code generator that the function diverges from the platform
 595     ABI on stack alignment.</li>
 596 <li>The new <a href="LangRef.html#int_objectsize">llvm.objectsize</a> intrinsic
 597     allows the optimizer to infer the sizes of memory objects in some cases.
 598     This intrinsic is used to implement the GCC <tt>__builtin_object_size</tt>
 599     extension.</li>
 600 <li>LLVM IR now supports marking load and store instructions with <a
 601     href="LangRef.html#i_load">"non-temporal" hints</a> (building on the new
 602     metadata feature).  This hint encourages the code
 603     generator to generate non-temporal accesses when possible, which are useful
 604     for code that is carefully managing cache behavior.  Currently, only the
 605     X86 backend provides target support for this feature.</li>
 606
 607 <li>LLVM 2.7 has pre-alpha support for <a
 608   href="LangRef.html#t_union">unions in LLVM IR</a>.
 609   Unfortunately, this support is not really usable in 2.7, so if you're
 610  interested in pushing it forward, please help contribute to LLVM mainline.</li>
 611
 612 </ul>
 613
 614 </div>
 615
 616 <!--=========================================================================-->
 617 <div class="doc_subsection">
 618 <a name="optimizer">Optimizer Improvements</a>
 619 </div>
 620
 621 <div class="doc_text">
 622
 623 <p>In addition to a large array of minor performance tweaks and bug fixes, this
 624 release includes a few major enhancements and additions to the optimizers:</p>
 625
 626 <ul>
 627
 628 <li>The inliner reuses now merges arrays stack objects in different callees when
 629     inlining multiple call sites into one function.  This reduces the stack size
 630     of the resultant function.</li>
 631 <li>The -basicaa alias analysis pass (which is the default) has been improved to
 632     be less dependent on "type safe" pointers.  It can now look through bitcasts
 633     and other constructs more aggressively, allowing better load/store
 634     optimization.</li>
 635 <li>The load elimination optimization in the GVN Pass [<a
 636 href="http://blog.llvm.org/2009/12/introduction-to-load-elimination-in-gvn.html">intro
 637  blog post</a>] has been substantially improved to be more aggressive about
 638  partial redundancy elimination and do more aggressive phi translation.  Please
 639  see the <a
 640  href="http://blog.llvm.org/2009/12/advanced-topics-in-redundant-load.html">
 641  Advanced Topics in Redundant Load Elimination with a Focus on PHI Translation
 642  Blog Post</a> for more details.</li>
 643 <li>The module <a href="LangRef.html#datalayout">target data string</a> now
 644     includes a notion of 'native' integer data types for the target. This
 645     helps mid-level optimizations avoid promoting complex sequences of
 646     operations to data types that are not natively supported (e.g. converting
 647     i32 operations to i64 on 32-bit chips).</li>
 648 <li>The mid-level optimizer is now conservative when operating on a module with
 649     no target data.  Previously, it would default to SparcV9 settings, which is
 650     not what most people expected.</li>
 651 <li>Jump threading is now much more aggressive at simplifying correlated
 652    conditionals and threading blocks with otherwise complex logic. It has
 653    subsumed the old "Conditional Propagation" pass, and -condprop has been
 654    removed from LLVM 2.7.</li>
 655 <li>The -instcombine pass has been refactored from being one huge file to being
 656     a library of its own.  Internally, it uses a customized IRBuilder to clean
 657     it up and simplify it.</li>
 658
 659 <li>The optimal edge profiling pass is reliable and much more complete than in
 660     2.6.  It can be used with the llvm-prof tool but isn't wired up to the
 661     llvm-gcc and clang command line options yet.</li>
 662
 663 <li>A new experimental alias analysis implementation, -scev-aa, has been added.
 664     It uses LLVM's Scalar Evolution implementation to do symbolic analysis of
 665     pointer offset expressions to disambiguate pointers.  It can catch a few
 666     cases that basicaa cannot, particularly in complex loop nests.</li>
 667
 668 <li>The default pass ordering has been tweaked for improved optimization
 669     effectiveness.</li>
 670
 671 </ul>
 672
 673 </div>
 674
 675
 676 <!--=========================================================================-->
 677 <div class="doc_subsection">
 678 <a name="executionengine">Interpreter and JIT Improvements</a>
 679 </div>
 680
 681 <div class="doc_text">
 682
 683 <ul>
 684 <li>The JIT now supports generating debug information and is compatible with
 685 the new GDB 7.0 (and later) interfaces for registering dynamically generated
 686 debug info.</li>
 687
 688 <li>The JIT now <a href="http://llvm.org/PR5184">defaults
 689 to compiling eagerly</a> to avoid a race condition in the lazy JIT.
 690 Clients that still want the lazy JIT can switch it on by calling
 691 <tt>ExecutionEngine::DisableLazyCompilation(false)</tt>.</li>
 692
 693 <li>It is now possible to create more than one JIT instance in the same process.
 694 These JITs can generate machine code in parallel,
 695 although <a href="http://llvm.org/docs/ProgrammersManual.html#jitthreading">you
 696 still have to obey the other threading restrictions</a>.</li>
 697
 698 </ul>
 699
 700 </div>
 701
 702 <!--=========================================================================-->
 703 <div class="doc_subsection">
 704 <a name="codegen">Target Independent Code Generator Improvements</a>
 705 </div>
 706
 707 <div class="doc_text">
 708
 709 <p>We have put a significant amount of work into the code generator
 710 infrastructure, which allows us to implement more aggressive algorithms and make
 711 it run faster:</p>
 712
 713 <ul>
 714 <li>The 'llc -asm-verbose' option (which is now the default) has been enhanced
 715     to emit many useful comments to .s files indicating information about spill
 716     slots and loop nest structure.  This should make it much easier to read and
 717     understand assembly files.  This is wired up in llvm-gcc and clang to
 718     the <tt>-fverbose-asm</tt> option.</li>
 719
 720 <li>New LSR with "full strength reduction" mode, which can reduce address
 721     register pressure in loops where address generation is important.</li>
 722
 723 <li>A new codegen level Common Subexpression Elimination pass (MachineCSE)
 724     is available and enabled by default.  It catches redundancies exposed by
 725     lowering.</li>
 726 <li>A new pre-register-allocation tail duplication pass is available and enabled
 727     by default, it can substantially improve branch prediction quality in some
 728     cases.</li>
 729 <li>A new sign and zero extension optimization pass (OptimizeExtsPass)
 730     is available and enabled by default.  This pass can takes advantage
 731     architecture features like x86-64 implicit zero extension behavior and
 732     sub-registers.</li>
 733 <li>The code generator now supports a mode where it attempts to preserve the
 734     order of instructions in the input code.  This is important for source that
 735     is hand scheduled and extremely sensitive to scheduling.  It is compatible
 736     with the GCC <tt>-fno-schedule-insns</tt> option.</li>
 737 <li>The target-independent code generator now supports generating code with
 738     arbitrary numbers of result values.  Returning more values than was
 739     previously supported is handled by returning through a hidden pointer.  In
 740     2.7, only the X86 and XCore targets have adopted support for this
 741     though.</li>
 742 <li>The code generator now supports generating code that follows the
 743     <a href="LangRef.html#callingconv">Glasgow Haskell Compiler Calling
 744     Convention</a> and ABI.</li>
 745 <li>The "<a href="CodeGenerator.html#selectiondag_select">DAG instruction
 746     selection</a>" phase of the code generator has been largely rewritten for
 747     2.7.  Previously, tblgen spit out tons of C++ code which was compiled and
 748     linked into the target to do the pattern matching, now it emits a much
 749     smaller table which is read by the target-independent code.  The primary
 750     advantages of this approach is that the size and compile time of various
 751     targets is much improved.  The X86 code generator shrunk by 1.5MB of code,
 752     for example.</li>
 753 <li>Almost the entire code generator has switched to emitting code through the
 754     MC interfaces instead of printing textually to the .s file.  This led to a
 755     number of cleanups and speedups.  In 2.7, debug an exception handling
 756     information does not go through MC yet.</li>
 757 </ul>
 758 </div>
 759
 760 <!--=========================================================================-->
 761 <div class="doc_subsection">
 762 <a name="x86">X86-32 and X86-64 Target Improvements</a>
 763 </div>
 764
 765 <div class="doc_text">
 766 <p>New features of the X86 target include:
 767 </p>
 768
 769 <ul>
 770 <li>The X86 backend now optimizes tails calls much more aggressively for
 771     functions that use the standard C calling convention.</li>
 772 <li>The X86 backend now models scalar SSE registers as subregs of the SSE vector
 773     registers, making the code generator more aggressive in cases where scalars
 774     and vector types are mixed.</li>
 775
 776 </ul>
 777
 778 </div>
 779
 780 <!--=========================================================================-->
 781 <div class="doc_subsection">
 782 <a name="ARM">ARM Target Improvements</a>
 783 </div>
 784
 785 <div class="doc_text">
 786 <p>New features of the ARM target include:
 787 </p>
 788
 789 <ul>
 790
 791 <li>The ARM backend now generates instructions in unified assembly syntax.</li>
 792
 793 <li>llvm-gcc now has complete support for the ARM v7 NEON instruction set.  This
 794    support differs slightly from the GCC implementation.  Please see the
 795    <a
 796 href="http://blog.llvm.org/2010/04/arm-advanced-simd-neon-intrinsics-and.html">
 797   ARM Advanced SIMD (NEON) Intrinsics and Types in LLVM Blog Post</a> for
 798   helpful information if migrating code from GCC to LLVM-GCC.</li>
 799
 800 <li>The ARM and Thumb code generators now use register scavenging for stack
 801     object address materialization. This allows the use of R3 as a general
 802     purpose register in Thumb1 code, as it was previous reserved for use in
 803     stack address materialization. Secondly, sequential uses of the same
 804     value will now re-use the materialized constant.</li>
 805
 806 <li>The ARM backend now has good support for ARMv4 targets and has been tested
 807     on StrongARM hardware.  Previously, LLVM only supported ARMv4T and
 808     newer chips.</li>
 809
 810 <li>Atomic builtins are now supported for ARMv6 and ARMv7 (__sync_synchronize,
 811     __sync_fetch_and_add, etc.).</li>
 812
 813 </ul>
 814
 815
 816 </div>
 817
 818 <!--=========================================================================-->
 819 <div class="doc_subsection">
 820 <a name="newapis">New Useful APIs</a>
 821 </div>
 822
 823 <div class="doc_text">
 824
 825 <p>This release includes a number of new APIs that are used internally, which
 826    may also be useful for external clients.
 827 </p>
 828
 829 <ul>
 830 <li>The optimizer uses the new CodeMetrics class to measure the size of code.
 831     Various passes (like the inliner, loop unswitcher, etc) all use this to make
 832     more accurate estimates of the code size impact of various
 833     optimizations.</li>
 834 <li>A new <a href="http://llvm.org/doxygen/InstructionSimplify_8h-source.html">
 835     llvm/Analysis/InstructionSimplify.h</a> interface is available for doing
 836     symbolic simplification of instructions (e.g. <tt>a+0</tt> -&gt; <tt>a</tt>)
 837     without requiring the instruction to exist.  This centralizes a lot of
 838     ad-hoc symbolic manipulation code scattered in various passes.</li>
 839 <li>The optimizer now uses a new <a
 840     href="http://llvm.org/doxygen/SSAUpdater_8h-source.html">SSAUpdater</a>
 841     class which efficiently supports
 842     doing unstructured SSA update operations.  This centralized a bunch of code
 843     scattered throughout various passes (e.g. jump threading, lcssa,
 844     loop rotate, etc) for doing this sort of thing.  The code generator has a
 845     similar <a href="http://llvm.org/doxygen/MachineSSAUpdater_8h-source.html">
 846     MachineSSAUpdater</a> class.</li>
 847 <li>The <a href="http://llvm.org/doxygen/Regex_8h-source.html">
 848     llvm/Support/Regex.h</a> header exposes a platform independent regular
 849     expression API.  Building on this, the <a
 850     href="TestingGuide.html#FileCheck">FileCheck</a> utility now supports
 851     regular exressions.</li>
 852 <li>raw_ostream now supports a circular "debug stream" accessed with "dbgs()".
 853     By default, this stream works the same way as "errs()", but if you pass
 854     <tt>-debug-buffer-size=1000</tt> to opt, the debug stream is capped to a
 855     fixed sized circular buffer and the output is printed at the end of the
 856     program's execution.  This is helpful if you have a long lived compiler
 857     process and you're interested in seeing snapshots in time.</li>
 858 </ul>
 859
 860
 861 </div>
 862
 863 <!--=========================================================================-->
 864 <div class="doc_subsection">
 865 <a name="otherimprovements">Other Improvements and New Features</a>
 866 </div>
 867
 868 <div class="doc_text">
 869 <p>Other miscellaneous features include:</p>
 870
 871 <ul>
 872 <li>You can now build LLVM as a big dynamic library (e.g. "libllvm2.7.so"). To
 873     get this, configure LLVM with the --enable-shared option.</li>
 874
 875 <li>LLVM command line tools now overwrite their output by default. Previously,
 876     they would only do this with -f. This makes them more convenient to use, and
 877     behave more like standard unix tools.</li>
 878
 879 <li>The opt and llc tools now autodetect whether their input is a .ll or .bc
 880     file, and automatically do the right thing.  This means you don't need to
 881     explicitly use the llvm-as tool for most things.</li>
 882 </ul>
 883
 884 </div>
 885
 886
 887 <!--=========================================================================-->
 888 <div class="doc_subsection">
 889 <a name="changes">Major Changes and Removed Features</a>
 890 </div>
 891
 892 <div class="doc_text">
 893
 894 <p>If you're already an LLVM user or developer with out-of-tree changes based
 895 on LLVM 2.6, this section lists some "gotchas" that you may run into upgrading
 896 from the previous release.</p>
 897
 898 <ul>
 899
 900 <li>
 901 The Andersen's alias analysis ("anders-aa") pass, the Predicate Simplifier
 902 ("predsimplify") pass, the LoopVR pass, the GVNPRE pass, and the random sampling
 903 profiling ("rsprofiling") passes have all been removed.  They were not being
 904 actively maintained and had substantial problems.  If you are interested in
 905 these components, you are welcome to ressurect them from SVN, fix the
 906 correctness problems, and resubmit them to mainline.</li>
 907
 908 <li>LLVM now defaults to building most libraries with RTTI turned off, providing
 909 a code size reduction.  Packagers who are interested in building LLVM to support
 910 plugins that require RTTI information should build with "make REQUIRE_RTTI=1"
 911 and should read the new <a href="Packaging.html">Advice on Packaging LLVM</a>
 912 document.</li>
 913
 914 <li>The LLVM interpreter now defaults to <em>not</em> using <tt>libffi</tt> even
 915 if you have it installed.  This makes it more likely that an LLVM built on one
 916 system will work when copied to a similar system.  To use <tt>libffi</tt>,
 917 configure with <tt>--enable-libffi</tt>.</li>
 918
 919 <li>Debug information uses a completely different representation, an LLVM 2.6
 920 .bc file should work with LLVM 2.7, but debug info won't come forward.</li>
 921
 922 <li>The LLVM 2.6 (and earlier) "malloc" and "free" instructions got removed,
 923     along with LowerAllocations pass.  Now you should just use a call to the
 924     malloc and free functions in libc.  These calls are optimized as well as
 925     the old instructions were.</li>
 926 </ul>
 927
 928 <p>In addition, many APIs have changed in this release.  Some of the major LLVM
 929 API changes are:</p>
 930
 931 <ul>
 932 <li>Just about everything has been converted to use <tt>raw_ostream</tt> instead of
 933     <tt>std::ostream</tt>.</li>
 934 <li><tt>llvm/ADT/iterator.h</tt> has been removed, just use <tt>&lt;iterator&gt;</tt>
 935  instead.</li>
 936 <li>The <tt>Streams.h</tt> file and <tt>DOUT</tt> got removed, use <tt>DEBUG(errs() &lt;&lt; ...);</tt>
 937    instead.</li>
 938 <li>The <tt>TargetAsmInfo</tt> interface was renamed to <tt>MCAsmInfo</tt>.</li>
 939 <li><tt>ModuleProvider</tt> has been <a
 940 href="http://llvm.org/viewvc/llvm-project?view=rev&amp;revision=94686">removed</a>
 941 and its methods moved to <tt>Module</tt> and <tt>GlobalValue</tt>.
 942 Most clients can remove uses of <tt>ExistingModuleProvider</tt>,
 943 replace <tt>getBitcodeModuleProvider</tt> with
 944 <tt>getLazyBitcodeModule</tt>, and pass their <tt>Module</tt> to
 945 functions that used to accept <tt>ModuleProvider</tt>.  Clients who
 946 wrote their own <tt>ModuleProvider</tt>s will need to derive from
 947 <tt>GVMaterializer</tt> instead and use
 948 <tt>Module::setMaterializer</tt> to attach it to a
 949 <tt>Module</tt>.</li>
 950
 951 <li><tt>GhostLinkage</tt> has given up the ghost.
 952 <tt>GlobalValue</tt>s that have not yet been read from their backing
 953 storage have the same linkage they will have after being read in.
 954 Clients must replace calls to
 955 <tt>GlobalValue::hasNotBeenReadFromBitcode</tt> with
 956 <tt>GlobalValue::isMaterializable</tt>.</li>
 957
 958 <li>The <tt>isInteger</tt>, <tt>isIntOrIntVector</tt>, <tt>isFloatingPoint</tt>,
 959 <tt>isFPOrFPVector</tt> and <tt>isFPOrFPVector</tt> methods have been renamed
 960 <tt>isIntegerTy</tt>, <tt>isIntOrIntVectorTy</tt>, <tt>isFloatingPointTy</tt>,
 961 <tt>isFPOrFPVectorTy</tt> and <tt>isFPOrFPVectorTy</tt> respectively.</li>
 962
 963 <li><tt>llvm::Instruction::clone()</tt> no longer takes argument.</li>
 964 <li><tt>raw_fd_ostream</tt>'s constructor now takes a flag argument, not individual
 965   booleans (see <tt>include/llvm/Support/raw_ostream.h</tt> for details).</li>
 966 <li>Some header files have been renamed:
 967 <ul>
 968   <li><tt>llvm/Support/AIXDataTypesFix.h</tt> to
 969       <tt>llvm/System/AIXDataTypesFix.h</tt></li>
 970   <li><tt>llvm/Support/DataTypes.h</tt> to <tt>llvm/System/DataTypes.h</tt></li>
 971   <li><tt>llvm/Transforms/Utils/InlineCost.h</tt> to
 972       <tt>llvm/Analysis/InlineCost.h</tt></li>
 973   <li><tt>llvm/Support/Mangler.h</tt> to <tt>llvm/Target/Mangler.h</tt></li>
 974   <li><tt>llvm/Analysis/Passes.h</tt> to <tt>llvm/CodeGen/Passes.h</tt></li>
 975 </ul></li>
 976 </ul>
 977
 978 </div>
 979
 980
 981
 982 <!-- *********************************************************************** -->
 983 <div class="doc_section">
 984   <a name="portability">Portability and Supported Platforms</a>
 985 </div>
 986 <!-- *********************************************************************** -->
 987
 988 <div class="doc_text">
 989
 990 <p>LLVM is known to work on the following platforms:</p>
 991
 992 <ul>
 993 <li>Intel and AMD machines (IA32, X86-64, AMD64, EMT-64) running Red Hat
 994     Linux, Fedora Core, FreeBSD and AuroraUX (and probably other unix-like
 995     systems).</li>
 996 <li>PowerPC and X86-based Mac OS X systems, running 10.4 and above in 32-bit
 997     and 64-bit modes.</li>
 998 <li>Intel and AMD machines running on Win32 using MinGW libraries (native).</li>
 999 <li>Intel and AMD machines running on Win32 with the Cygwin libraries (limited
1000     support is available for native builds with Visual C++).</li>
1001 <li>Sun x86 and AMD64 machines running Solaris 10, OpenSolaris 0906.</li>
1002 <li>Alpha-based machines running Debian GNU/Linux.</li>
1003 </ul>
1004
1005 <p>The core LLVM infrastructure uses GNU autoconf to adapt itself
1006 to the machine and operating system on which it is built.  However, minor
1007 porting may be required to get LLVM to work on new platforms.  We welcome your
1008 portability patches and reports of successful builds or error messages.</p>
1009
1010 </div>
1011
1012 <!-- *********************************************************************** -->
1013 <div class="doc_section">
1014   <a name="knownproblems">Known Problems</a>
1015 </div>
1016 <!-- *********************************************************************** -->
1017
1018 <div class="doc_text">
1019
1020 <p>This section contains significant known problems with the LLVM system,
1021 listed by component.  If you run into a problem, please check the <a
1022 href="http://llvm.org/bugs/">LLVM bug database</a> and submit a bug if
1023 there isn't already one.</p>
1024
1025 <ul>
1026 <li>LLVM will not correctly compile on Solaris and/or OpenSolaris
1027 using the stock GCC 3.x.x series 'out the box',
1028 See: <a href="GettingStarted.html#brokengcc">Broken versions of GCC and other tools</a>.
1029 However, A <a href="http://pkg.auroraux.org/GCC">Modern GCC Build</a>
1030 for x86/x86-64 has been made available from the third party AuroraUX Project
1031 that has been meticulously tested for bootstrapping LLVM &amp; Clang.</li>
1032 </ul>
1033
1034 </div>
1035
1036 <!-- ======================================================================= -->
1037 <div class="doc_subsection">
1038   <a name="experimental">Experimental features included with this release</a>
1039 </div>
1040
1041 <div class="doc_text">
1042
1043 <p>The following components of this LLVM release are either untested, known to
1044 be broken or unreliable, or are in early development.  These components should
1045 not be relied on, and bugs should not be filed against them, but they may be
1046 useful to some people.  In particular, if you would like to work on one of these
1047 components, please contact us on the <a
1048 href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev list</a>.</p>
1049
1050 <ul>
1051 <li>The MSIL, Alpha, SPU, MIPS, PIC16, Blackfin, MSP430, SystemZ and MicroBlaze
1052     backends are experimental.</li>
1053 <li><tt>llc</tt> "<tt>-filetype=asm</tt>" (the default) is the only
1054     supported value for this option.  The MachO writer is experimental, and
1055     works much better in mainline SVN.</li>
1056 </ul>
1057
1058 </div>
1059
1060 <!-- ======================================================================= -->
1061 <div class="doc_subsection">
1062   <a name="x86-be">Known problems with the X86 back-end</a>
1063 </div>
1064
1065 <div class="doc_text">
1066
1067 <ul>
1068   <li>The X86 backend does not yet support
1069     all <a href="http://llvm.org/PR879">inline assembly that uses the X86
1070     floating point stack</a>.  It supports the 'f' and 't' constraints, but not
1071     'u'.</li>
1072   <li>The X86 backend generates inefficient floating point code when configured
1073     to generate code for systems that don't have SSE2.</li>
1074   <li>Win64 code generation wasn't widely tested. Everything should work, but we
1075     expect small issues to happen. Also, llvm-gcc cannot build the mingw64
1076     runtime currently due to lack of support for the 'u' inline assembly
1077     constraint and for X87 floating point inline assembly.</li>
1078   <li>The X86-64 backend does not yet support the LLVM IR instruction
1079       <tt>va_arg</tt>. Currently, front-ends support variadic
1080       argument constructs on X86-64 by lowering them manually.</li>
1081 </ul>
1082
1083 </div>
1084
1085 <!-- ======================================================================= -->
1086 <div class="doc_subsection">
1087   <a name="ppc-be">Known problems with the PowerPC back-end</a>
1088 </div>
1089
1090 <div class="doc_text">
1091
1092 <ul>
1093 <li>The Linux PPC32/ABI support needs testing for the interpreter and static
1094 compilation, and lacks support for debug information.</li>
1095 </ul>
1096
1097 </div>
1098
1099 <!-- ======================================================================= -->
1100 <div class="doc_subsection">
1101   <a name="arm-be">Known problems with the ARM back-end</a>
1102 </div>
1103
1104 <div class="doc_text">
1105
1106 <ul>
1107 <li>Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6
1108 processors, thumb programs can crash or produce wrong
1109 results (<a href="http://llvm.org/PR1388">PR1388</a>).</li>
1110 <li>Compilation for ARM Linux OABI (old ABI) is supported but not fully tested.
1111 </li>
1112 </ul>
1113
1114 </div>
1115
1116 <!-- ======================================================================= -->
1117 <div class="doc_subsection">
1118   <a name="sparc-be">Known problems with the SPARC back-end</a>
1119 </div>
1120
1121 <div class="doc_text">
1122
1123 <ul>
1124 <li>The SPARC backend only supports the 32-bit SPARC ABI (-m32); it does not
1125     support the 64-bit SPARC ABI (-m64).</li>
1126 </ul>
1127
1128 </div>
1129
1130 <!-- ======================================================================= -->
1131 <div class="doc_subsection">
1132   <a name="mips-be">Known problems with the MIPS back-end</a>
1133 </div>
1134
1135 <div class="doc_text">
1136
1137 <ul>
1138 <li>64-bit MIPS targets are not supported yet.</li>
1139 </ul>
1140
1141 </div>
1142
1143 <!-- ======================================================================= -->
1144 <div class="doc_subsection">
1145   <a name="alpha-be">Known problems with the Alpha back-end</a>
1146 </div>
1147
1148 <div class="doc_text">
1149
1150 <ul>
1151
1152 <li>On 21164s, some rare FP arithmetic sequences which may trap do not have the
1153 appropriate nops inserted to ensure restartability.</li>
1154
1155 </ul>
1156 </div>
1157
1158 <!-- ======================================================================= -->
1159 <div class="doc_subsection">
1160   <a name="c-be">Known problems with the C back-end</a>
1161 </div>
1162
1163 <div class="doc_text">
1164
1165 <ul>
1166 <li><a href="http://llvm.org/PR802">The C backend has only basic support for
1167     inline assembly code</a>.</li>
1168 <li><a href="http://llvm.org/PR1658">The C backend violates the ABI of common
1169     C++ programs</a>, preventing intermixing between C++ compiled by the CBE and
1170     C++ code compiled with <tt>llc</tt> or native compilers.</li>
1171 <li>The C backend does not support all exception handling constructs.</li>
1172 <li>The C backend does not support arbitrary precision integers.</li>
1173 </ul>
1174
1175 </div>
1176
1177
1178 <!-- ======================================================================= -->
1179 <div class="doc_subsection">
1180   <a name="c-fe">Known problems with the llvm-gcc C and C++ front-end</a>
1181 </div>
1182
1183 <div class="doc_text">
1184
1185 <p>The only major language feature of GCC not supported by llvm-gcc is
1186     the <tt>__builtin_apply</tt> family of builtins.   However, some extensions
1187     are only supported on some targets.  For example, trampolines are only
1188     supported on some targets (these are used when you take the address of a
1189     nested function).</p>
1190
1191 </div>
1192
1193 <!-- ======================================================================= -->
1194 <div class="doc_subsection">
1195   <a name="fortran-fe">Known problems with the llvm-gcc Fortran front-end</a>
1196 </div>
1197
1198 <div class="doc_text">
1199 <ul>
1200 <li>Fortran support generally works, but there are still several unresolved bugs
1201     in <a href="http://llvm.org/bugs/">Bugzilla</a>.  Please see the
1202     tools/gfortran component for details.</li>
1203 </ul>
1204 </div>
1205
1206 <!-- ======================================================================= -->
1207 <div class="doc_subsection">
1208   <a name="ada-fe">Known problems with the llvm-gcc Ada front-end</a>
1209 </div>
1210
1211 <div class="doc_text">
1212 The llvm-gcc 4.2 Ada compiler works fairly well; however, this is not a mature
1213 technology, and problems should be expected.
1214 <ul>
1215 <li>The Ada front-end currently only builds on X86-32.  This is mainly due
1216 to lack of trampoline support (pointers to nested functions) on other platforms.
1217 However, it <a href="http://llvm.org/PR2006">also fails to build on X86-64</a>
1218 which does support trampolines.</li>
1219 <li>The Ada front-end <a href="http://llvm.org/PR2007">fails to bootstrap</a>.
1220 This is due to lack of LLVM support for <tt>setjmp</tt>/<tt>longjmp</tt> style
1221 exception handling, which is used internally by the compiler.
1222 Workaround: configure with <tt>--disable-bootstrap</tt>.</li>
1223 <li>The c380004, <a href="http://llvm.org/PR2010">c393010</a>
1224 and <a href="http://llvm.org/PR2421">cxg2021</a> ACATS tests fail
1225 (c380004 also fails with gcc-4.2 mainline).
1226 If the compiler is built with checks disabled then <a href="http://llvm.org/PR2010">c393010</a>
1227 causes the compiler to go into an infinite loop, using up all system memory.</li>
1228 <li>Some GCC specific Ada tests continue to crash the compiler.</li>
1229 <li>The <tt>-E</tt> binder option (exception backtraces)
1230 <a href="http://llvm.org/PR1982">does not work</a> and will result in programs
1231 crashing if an exception is raised.  Workaround: do not use <tt>-E</tt>.</li>
1232 <li>Only discrete types <a href="http://llvm.org/PR1981">are allowed to start
1233 or finish at a non-byte offset</a> in a record.  Workaround: do not pack records
1234 or use representation clauses that result in a field of a non-discrete type
1235 starting or finishing in the middle of a byte.</li>
1236 <li>The <tt>lli</tt> interpreter <a href="http://llvm.org/PR2009">considers
1237 'main' as generated by the Ada binder to be invalid</a>.
1238 Workaround: hand edit the file to use pointers for <tt>argv</tt> and
1239 <tt>envp</tt> rather than integers.</li>
1240 <li>The <tt>-fstack-check</tt> option <a href="http://llvm.org/PR2008">is
1241 ignored</a>.</li>
1242 </ul>
1243 </div>
1244
1245 <!-- *********************************************************************** -->
1246 <div class="doc_section">
1247   <a name="additionalinfo">Additional Information</a>
1248 </div>
1249 <!-- *********************************************************************** -->
1250
1251 <div class="doc_text">
1252
1253 <p>A wide variety of additional information is available on the <a
1254 href="http://llvm.org">LLVM web page</a>, in particular in the <a
1255 href="http://llvm.org/docs/">documentation</a> section.  The web page also
1256 contains versions of the API documentation which is up-to-date with the
1257 Subversion version of the source code.
1258 You can access versions of these documents specific to this release by going
1259 into the "<tt>llvm/doc/</tt>" directory in the LLVM tree.</p>
1260
1261 <p>If you have any questions or comments about LLVM, please feel free to contact
1262 us via the <a href="http://llvm.org/docs/#maillist"> mailing
1263 lists</a>.</p>
1264
1265 </div>
1266
1267 <!-- *********************************************************************** -->
1268
1269 <hr>
1270 <address>
1271   <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
1272   src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
1273   <a href="http://validator.w3.org/check/referer"><img
1274   src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
1275
1276   <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br>
1277   Last modified: $Date$
1278 </address>
1279
1280 </body>
1281 </html>