LLVM 2.1 Release Notes

This document contains the release notes for the LLVM compiler -infrastructure, release 2.1. Here we describe the status of LLVM, including +infrastructure, release 2.2. Here we describe the status of LLVM, including major improvements from the previous release and any known problems. All LLVM releases may be downloaded from the LLVM releases web site.

@@ -58,31 +58,35 @@ current one. To see the release notes for a specific releases, please see the

This is the twelfth public release of the LLVM Compiler Infrastructure. -It includes many features and refinements from LLVM 2.0.

This is the thirteenth public release of the LLVM Compiler Infrastructure. +It includes many features and refinements from LLVM 2.1.

-New Frontends +llvm-gcc 4.0, llvm-gcc 4.2, and clang

LLVM 2.1 brings two new beta C front-ends. First, a new version of llvm-gcc -based on GCC 4.2, innovatively called "llvm-gcc-4.2". This promises to bring -FORTRAN and Ada support to LLVM as well as features like atomic builtins and -OpenMP. None of these actually work yet, but don't let that stop you checking -it out!

LLVM 2.2 fully supports both the llvm-gcc 4.0 and llvm-gcc 4.2 front-ends (in +LLVM 2.1, llvm-gcc 4.2 was beta). Since LLVM 2.1, the llvm-gcc 4.2 front-end +has made leaps and bounds and is now at least as good as 4.0 in virtually every +area, and is better in several areas (for example, exception handling +correctness). We strongly recommend that you migrate from llvm-gcc 4.0 to +llvm-gcc 4.2 in this release cycle because LLVM 2.2 is the last release +that will support llvm-gcc 4.0: LLVM 2.3 will only support the llvm-gcc +4.2 front-end.

Second, LLVM now includes its own native C and Objective-C front-end (C++ is -in progress, but is not very far along) code named "clang". This front-end has a number of great -features, primarily aimed at source-level analysis and speeding up compile-time. -At this point though, the LLVM Code Generator component is still very early in -development, so it's mostly useful for people looking to build source-level -analysis tools or source-to-source translators.

The clang project is an effort +to build a set of new front-end technology for the LLVM optimizer and code +generator. Currently, its C and Objective-C support is maturing nicely, and it +has advanced source-to-source analysis and transformation capabilities. If you +are interested in building source-level tools for C and Objective-C (and +eventually C++), you should take a look. However, note that clang is not an +official part of the LLVM 2.2 release. If you are interested in this project, +please see the web site and check it out from SVN head.

@@ -98,24 +102,7 @@ optimizer, speeding it up and making it more aggressive. For example:

Owen Anderson wrote the new MemoryDependenceAnalysis pass, which provides - a lazy, caching layer on top of AliasAnalysis. He then used it to rewrite - DeadStoreElimination which resulted in significantly better compile time in - common cases,
Owen implemented the new GVN pass, which is also based on - MemoryDependenceAnalysis. This pass replaces GCSE/LoadVN in the standard - set of passes, providing more aggressive optimization at a some-what - improved compile-time cost.
Owen implemented GVN-PRE, a partial redundancy elimination algorithm that - shares some details with the new GVN pass. It is still in need of compile - time tuning, and is not turned on by default.
Devang merged ETForest and DomTree into a single easier to use data - structure. This makes it more obvious which datastructure to choose - (because there is only one) and makes the compiler more memory and time - efficient (less stuff to keep up-to-date).
Nick Lewycky improved loop trip count analysis to handle many more common - cases.
.

@@ -133,38 +120,7 @@ optimizer, speeding it up and making it more aggressive. For example:

Dale finished up the Tail Merging optimization in the code generator, and - enabled it by default. This produces smaller code that is also faster in - some cases.
Christopher Lamb implemented support for virtual register sub-registers, - which can be used to better model many forms of subregisters. As an example - use, he modified the X86 backend to use this to model truncates and - extends more accurately (leading to better code).
Dan Gohman changed the way we represent vectors before legalization, - significantly simplifying the SelectionDAG representation for these and - making the code generator faster for vector code.
Evan contributed a new target independent if-converter. While it is - target independent, so far only the ARM backend uses it.
Evan rewrote the way the register allocator handles rematerialization, - allowing it to be much more effective on two-address targets like X86, - and taught it to fold loads away when possible (also a big win on X86).
Dan Gohman contributed support for better alignment and volatility handling - in the code generator, and significantly enhanced alignment analysis for SSE - load/store instructions. With his changes, an insufficiently-aligned SSE - load instruction turns into movups, for example.
Duraid Madina contributed a new "bigblock" register allocator, and Roman - Levenstein contributed several big improvements. BigBlock is optimized for - code that uses very large basic blocks. It is slightly slower than the - "local" allocator, but produces much better code.
David Greene refactored the register allocator to split coalescing out from - allocation, making coalescers pluggable.
.

@@ -181,19 +137,7 @@ optimizer, speeding it up and making it more aggressive. For example:

Bruno Cardoso Lopes contributed initial MIPS support. It is sufficient to - run many small programs, but is still incomplete and is not yet - fully performant.
Bill Wendling added SSSE3 support to the X86 backend.
Nicholas Geoffray contributed improved linux/ppc ABI and JIT support.
Dale Johannesen rewrote handling of 32-bit float values in the X86 backend - when using the floating point stack, fixing several nasty bugs.
Dan contributed rematerialization support for the X86 backend, in addition - to several X86-specific micro optimizations.
.