From bec487767c3e0a376eed7c37773c88d6fcc8e4d9 Mon Sep 17 00:00:00 2001 From: Jeffrey Yasskin Date: Thu, 28 Jan 2010 01:14:43 +0000 Subject: [PATCH] Truncate the release notes so they're ready to accumulate notes for the 2.7 release. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94720 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/ReleaseNotes.html | 481 ++++------------------------------------- 1 file changed, 44 insertions(+), 437 deletions(-) diff --git a/docs/ReleaseNotes.html b/docs/ReleaseNotes.html index f3d87c6330c..8df6cfc95f6 100644 --- a/docs/ReleaseNotes.html +++ b/docs/ReleaseNotes.html @@ -4,17 +4,17 @@ - LLVM 2.6 Release Notes + LLVM 2.7 Release Notes -
LLVM 2.6 Release Notes
+
LLVM 2.7 Release Notes
  1. Introduction
  2. Sub-project Status Update
    3. -
  3. External Projects Using LLVM 2.6
    4. -
  4. What's New in LLVM 2.6?
    5. +
  5. External Projects Using LLVM 2.7
    6. +
  6. What's New in LLVM 2.7?
  7. Installation Instructions
  8. Portability and Supported Platforms
  9. Known Problems
    10. @@ -25,6 +25,12 @@

    Written by the LLVM Team

    +

    These are in-progress notes for the upcoming LLVM 2.7 +release.
    +You may prefer the +LLVM 2.6 +Release Notes.

    +
    Introduction @@ -34,7 +40,7 @@

    This document contains the release notes for the LLVM Compiler -Infrastructure, release 2.6. Here we describe the status of LLVM, including +Infrastructure, release 2.7. Here we describe the status of LLVM, including major improvements from the previous release and significant known problems. All LLVM releases may be downloaded from the LLVM releases web site.

    @@ -63,7 +69,7 @@ Almost dead code. --> -
    - External Open Source Projects Using LLVM 2.6 + External Open Source Projects Using LLVM 2.7
    @@ -315,7 +247,7 @@ other situations.

    An exciting aspect of LLVM is that it is used as an enabling technology for a lot of other language and tools projects. This section lists some of the - projects that have already been updated to work with LLVM 2.6.

    + projects that have already been updated to work with LLVM 2.7.

    @@ -376,8 +308,8 @@ built-in list and matrix support (including list and matrix comprehensions) and an easy-to-use C interface. The interpreter uses LLVM as a backend to JIT-compile Pure programs to fast native code.

    -

    Pure versions 0.31 and later have been tested and are known to work with -LLVM 2.6 (and continue to work with older LLVM releases >= 2.3 as well). +

    Pure versions ??? and later have been tested and are known to work with +LLVM 2.7 (and continue to work with older LLVM releases >= 2.3 as well).

    @@ -460,7 +392,7 @@ code.
    - What's New in LLVM 2.6? + What's New in LLVM 2.7?
    @@ -480,28 +412,10 @@ in this section.
    -

    LLVM 2.6 includes several major new capabilities:

    +

    LLVM 2.7 includes several major new capabilities:

      -
    • New compiler-rt, KLEE - and machine code toolkit sub-projects.
      • -
    • Debug information now includes line numbers when optimizations are enabled. - This allows statistical sampling tools like OProfile and Shark to map - samples back to source lines.
      • -
    • LLVM now includes new experimental backends to support the MSP430, SystemZ - and BlackFin architectures.
      • -
    • LLVM supports a new Gold Linker Plugin which - enables support for transparent - link-time optimization on ELF targets when used with the Gold binutils - linker.
      • -
    • LLVM now supports doing optimization and code generation on multiple - threads. Please see the LLVM - Programmer's Manual for more information.
      • -
    • LLVM now has experimental support for embedded - metadata in LLVM IR, though the implementation is not guaranteed to be - final and the .bc file format may change in future releases. Debug info - does not yet use this format in LLVM 2.6.
      • +
    • ...
    @@ -516,50 +430,7 @@ in this section. expose new optimization opportunities:

    @@ -576,23 +447,7 @@ release includes a few major enhancements and additions to the optimizers:

    @@ -607,17 +462,7 @@ release includes a few major enhancements and additions to the optimizers:

      -
    • LLVM has a new "EngineBuilder" class which makes it more obvious how to - set up and configure an ExecutionEngine (a JIT or interpreter).
      • -
    • The JIT now supports generating more than 16M of code.
      • -
    • When configured with --with-oprofile, the JIT can now inform - OProfile about JIT'd code, allowing OProfile to get line number and function - name information for JIT'd functions.
      • -
    • When "libffi" is available, the LLVM interpreter now uses it, which supports - calling almost arbitrary external (natively compiled) functions.
      • -
    • Clients of the JIT can now register a 'JITEventListener' object to receive - callbacks when the JIT emits or frees machine code. The OProfile support - uses this mechanism.
      • +
    • ...
    @@ -635,54 +480,7 @@ it run faster:

    @@ -697,31 +495,7 @@ it run faster:

    @@ -737,11 +511,7 @@ it run faster:

    Things not yet supported:

    @@ -764,22 +534,9 @@ it run faster:

    -

    These features are still somewhat experimental -and subject to change. The Neon intrinsics, in particular, may change in future -releases of LLVM. ARMv7 support has progressed a lot on top of tree since 2.6 -branched.

    - @@ -793,11 +550,7 @@ branched.

    @@ -814,40 +567,7 @@ branched.

    @@ -862,32 +582,7 @@ branched.

    Other miscellaneous features include:

    @@ -901,24 +596,11 @@ CPU2000).

    If you're already an LLVM user or developer with out-of-tree changes based -on LLVM 2.5, this section lists some "gotchas" that you may run into upgrading +on LLVM 2.6, this section lists some "gotchas" that you may run into upgrading from the previous release.

      -
    • The Itanium (IA64) backend has been removed. It was not actively supported - and had bitrotted.
      • -
    • The BigBlock register allocator has been removed, it had also bitrotted.
      • -
    • The C Backend (-march=c) is no longer considered part of the LLVM release -criteria. We still want it to work, but no one is maintaining it and it lacks -support for arbitrary precision integers and other important IR features.
      • - -
    • All LLVM tools now default to overwriting their output file, behaving more - like standard unix tools. Previously, this only happened with the '-f' - option.
      • -
    • LLVM build now builds all libraries as .a files instead of some - libraries as relinked .o files. This requires some APIs like - InitializeAllTargets.h. -
      • +
    • ...
    @@ -926,82 +608,7 @@ support for arbitrary precision integers and other important IR features. API changes are:

      -
    • All uses of hash_set and hash_map have been removed from - the LLVM tree and the wrapper headers have been removed.
      • -
    • The llvm/Streams.h and DOUT member of Debug.h have been removed. The - llvm::Ostream class has been completely removed and replaced with - uses of raw_ostream.
      • -
    • LLVM's global uniquing tables for Types and Constants have - been privatized into members of an LLVMContext. A number of APIs - now take an LLVMContext as a parameter. To smooth the transition - for clients that will only ever use a single context, the new - getGlobalContext() API can be used to access a default global - context which can be passed in any and all cases where a context is - required. -
    • The getABITypeSize methods are now called getAllocSize.
      • -
    • The Add, Sub and Mul operators are no longer - overloaded for floating-point types. Floating-point addition, subtraction - and multiplication are now represented with new operators FAdd, - FSub and FMul. In the IRBuilder API, - CreateAdd, CreateSub, CreateMul and - CreateNeg should only be used for integer arithmetic now; - CreateFAdd, CreateFSub, CreateFMul and - CreateFNeg should now be used for floating-point arithmetic.
      • -
    • The DynamicLibrary class can no longer be constructed, its functionality has - moved to static member functions.
      • -
    • raw_fd_ostream's constructor for opening a given filename now - takes an extra Force argument. If Force is set to - false, an error will be reported if a file with the given name - already exists. If Force is set to true, the file will - be silently truncated (which is the behavior before this flag was - added).
      • -
    • SCEVHandle no longer exists, because reference counting is no - longer done for SCEV* objects, instead const SCEV* - should be used.
      • - -
    • Many APIs, notably llvm::Value, now use the StringRef -and Twine classes instead of passing const char* -or std::string, as described in -the Programmer's Manual. Most -clients should be unaffected by this transition, unless they are used to -Value::getName() returning a string. Here are some tips on updating to -2.6: -
        -
      • getNameStr() is still available, and matches the old - behavior. Replacing getName() calls with this is an safe option, - although more efficient alternatives are now possible.
        • - -
      • If you were just relying on getName() being able to be sent to - a std::ostream, consider migrating - to llvm::raw_ostream.
        • - -
      • If you were using getName().c_str() to get a const - char* pointer to the name, you can use getName().data(). - Note that this string (as before), may not be the entire name if the - name contains embedded null characters.
        • - -
      • If you were using operator + on the result of getName() and - treating the result as an std::string, you can either - use Twine::str to get the result as an std::string, or - could move to a Twine based design.
        • - -
      • isName() should be replaced with comparison - against getName() (this is now efficient). -
      -
      • - -
    • The registration interfaces for backend Targets has changed (what was -previously TargetMachineRegistry). For backend authors, see the Writing An LLVM Backend -guide. For clients, the notable API changes are: -
        -
      • TargetMachineRegistry has been renamed - to TargetRegistry.
        • - -
      • Clients should move to using the TargetRegistry::lookupTarget() - function to find targets.
        • -
      -
      • +
    • ...
    @@ -1055,8 +662,8 @@ there isn't already one.

  10. The llvm-gcc bootstrap will fail with some versions of binutils (e.g. 2.15) with a message of "Error: can not do 8 byte pc-relative relocation" when building C++ code. We intend to - fix this on mainline, but a workaround for 2.6 is to upgrade to binutils - 2.17 or later.
    11. + fix this on mainline, but a workaround is to upgrade to binutils 2.17 or + later.
  11. LLVM will not correctly compile on Solaris and/or OpenSolaris using the stock GCC 3.x.x series 'out the box',