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.

@@ -58,10 +64,12 @@ Almost dead code. include/llvm/Analysis/LiveValues.h => Dan lib/Transforms/IPO/MergeFunctions.cpp => consider for 2.8. llvm/Analysis/PointerTracking.h => Edwin wants this, consider for 2.8. + ABCD, SCCVN, GEPSplitterPass + MSIL backend? --> -

- External Open Source Projects Using LLVM 2.6 + External Open Source Projects Using LLVM 2.7

@@ -313,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.

@@ -374,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).

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.
...

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.
The JIT now defaults +to compiling eagerly to avoid a race condition in the lazy JIT. +Clients that still want the lazy JIT can switch it on by calling +ExecutionEngine::DisableLazyCompilation(false).

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.

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. -
...

@@ -924,82 +612,24 @@ 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.
-
ModuleProvider has been removed +and its methods moved to Module and GlobalValue. +Most clients can remove uses of ExistingModuleProvider, +replace getBitcodeModuleProvider with +getLazyBitcodeModule, and pass their Module to +functions that used to accept ModuleProvider. Clients who +wrote their own ModuleProviders will need to derive from +GVMaterializer instead and use +Module::setMaterializer to attach it to a +Module.
GhostLinkage has given up the ghost. +GlobalValues that have not yet been read from their backing +storage have the same linkage they will have after being read in. +Clients must replace calls to +GlobalValue::hasNotBeenReadFromBitcode with +GlobalValue::isMaterializable.

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

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