This document contains the release notes for the LLVM compiler
-infrastructure, release 2.0. Here we describe the status of LLVM, including any
-known problems and major improvements from the previous release. All LLVM
+infrastructure, release 2.1. 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.
+releases web site.
For more information about LLVM, including information about the latest
release, please check out the main LLVM
@@ -43,10 +43,10 @@ web site. If you have questions or comments, the LLVM developer's mailing
list is a good place to send them.
-
Note that if you are reading this file from CVS or the main LLVM web page,
-this document applies to the next release, not the current one. To see
-the release notes for the current or previous releases, see the releases page.
+
Note that if you are reading this file from a Subversion checkout or the
+main LLVM web page, this document applies to the next release, not the
+current one. To see the release notes for a specific releases, please see the
+releases page.
@@ -58,137 +58,235 @@ href="http://llvm.org/releases/">releases page.
-
This is the eleventh public release of the LLVM Compiler Infrastructure.
-Being the first major release since 1.0, this release is different in several
-ways from our previous releases:
+
This is the twelfth public release of the LLVM Compiler Infrastructure.
+It includes many features and refinements from LLVM 2.0.
-
-- We took this as an opportunity to
-break backwards compatibility with the LLVM 1.x bytecode and .ll file format.
-If you have LLVM 1.9 .ll files that you would like to upgrade to LLVM 2.x, we
-recommend the use of the stand alone llvm-upgrade
-tool. We intend to keep compatibility with .ll and .bc formats within the 2.x
-release series, like we did within the 1.x series.
-- There are several significant change to the LLVM IR and internal APIs, such
- as a major overhaul of the type system, the completely new bitcode file
- format, etc.
-- We designed the release around a 6 month release cycle instead of the usual
- 3-month cycle. This gave us extra time to develop and test some of the
- more invasive features in this release.
-- LLVM 2.0 no longer supports the llvm-gcc3 front-end.
-
+
Note that while this is a major version bump, this release has been
- extensively tested on a wide range of software. It is easy to say that this
- is our best release yet, in terms of both features and correctness.
+
+
+
+
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!
+
+
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.
-
blah
-
+
+
Some of the most noticable feature improvements this release have been in the
+optimizer, speeding it up and making it more aggressive. For example:
-- ding dong llvm-gcc3 is dead
-- bytecode -> bitcode
+
+- 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.
+
-
+
-
New features include:
-
+
+
One of the main focuses of this release was performance tuning and bug
+ fixing. In addition to these, several new major changes occurred:
-- many new supported things
-- easier to configure on linux
+
+- 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.
+
-
+
+
-
-New features include:
+
New features include:
+
Duncan and Anton made significant progress chasing down a number of problems
+ with C++ Zero-Cost exception handling in llvm-gcc 4.0 and 4.2. It is now at
+ the point where it "just works" on linux/X86-32 and has partial support on
+ other targets.
-
In addition, the LLVM target description format has itself been extended in
- several ways:
-
-
+
Devang and Duncan fixed a huge number of bugs relating to bitfields, pragma
+ pack, and variable sized fields in structures.
-
Further, several significant target-specific enhancements are included in
-LLVM 2.0:
+
Tanya implemented support for __attribute__((noinline)) in
+ llvm-gcc, and added support for generic variable annotations which are
+ propagated into the LLVM IR, e.g.
+ "int X __attribute__((annotate("myproperty")));".
-
+
Sheng Zhou and Christopher Lamb implemented alias analysis support for
+"restrict" pointer arguments to functions.
+
+
Duncan contributed support for trampolines (taking the address of a nested
+ function). Currently this is only supported on the X86-32 target.
+
Lauro Ramos Venancio contributed support to encode alignment info in
+ load and store instructions, the foundation for other alignment-related
+ work.
+
+
+
+
+
New features include:
-
+- Neil Booth contributed a new "APFloat" class, which ensures that floating
+ point representation and constant folding is not dependent on the host
+ architecture that builds the application. This support is the foundation
+ for "long double" support that will be wrapped up in LLVM 2.2.
+
+- Based on the APFloat class, Dale redesigned the internals of the ConstantFP
+ class and has been working on extending the core and optimizer components to
+ support various target-specific 'long double's. We expect this work to be
+ completed in LLVM 2.2.
+
+- LLVM now provides an LLVMBuilder class, which makes it significantly easier
+ to create LLVM IR instructions.
+
+- Reid contributed support for intrinsics that take arbitrary integer typed
+ arguments. Dan Gohman and Chandler extended it to support arbitrary
+ floating point arguments and vectors.
+
+
-
-
-
-
-
More specific changes include:
+
New features include:
+
-
+- Sterling Stein contributed a new BrainF frontend, located in llvm/examples.
+ This shows a some of the more modern APIs for building a front-end, and
+ demonstrates JIT compiler support.
+
+- David Green contributed a new --enable-expensive-checks configure
+ option which enables STL checking, and fixed several bugs exposed by
+ it.
+
-
-
LLVM is known to work on the following platforms:
- - Intel and AMD machines running Red Hat Linux, Fedora Core and FreeBSD
+
- Intel and AMD machines running Red Hat Linux, Fedora Core and FreeBSD
(and probably other unix-like systems).
+- PowerPC and X86-based Mac OS X systems, running 10.2 and above in 32-bit and
+ 64-bit modes.
- Intel and AMD machines running on Win32 using MinGW libraries (native)
-- Sun UltraSPARC workstations running Solaris 8.
- Intel and AMD machines running on Win32 with the Cygwin libraries (limited
support is available for native builds with Visual C++).
-- PowerPC and X86-based Mac OS X systems, running 10.2 and above in 32-bit and
- 64-bit modes.
+- Sun UltraSPARC workstations running Solaris 8.
- Alpha-based machines running Debian GNU/Linux.
- Itanium-based machines running Linux and HP-UX.
@@ -250,11 +348,11 @@ useful to some people. In particular, if you would like to work on one of these
components, please contact us on the
LLVMdev list.
-- The -cee pass is known to be buggy, and may be removed in in a
+
- The -cee pass is known to be buggy, and may be removed in a
future release.
-- C++ EH support
+- The MSIL backend is experimental.
- The IA64 code generator is experimental.
-- The Alpha JIT is experimental.
+- The Alpha backend is experimental.
- "-filetype=asm" (the default) is the only supported value for the
-filetype llc option.
@@ -271,6 +369,9 @@ components, please contact us on the
inline
assembly that uses the X86 floating point stack.
+
The X86 backend occasionally has alignment
+ problems on operating systems that don't require 16-byte stack alignment
+ (including most non-darwin OS's like linux).
FIXME: the list of supported stuff below needs to be updated. We do support
-tls now, what else??
@@ -410,85 +513,56 @@ tls now, what else??
-
-- "long double" is transformed by the front-end into "double". There is no
-support for floating point data types of any size other than 32 and 64
-bits.
+"long double" is silently transformed by the front-end into "double". There
+is no support for floating point data types of any size other than 32 and 64
+bits.
- Although many GCC extensions are supported, some are not. In particular,
- the following extensions are known to not be supported:
-
- - Local Labels: Labels local to a block.
- - Nested Functions: As in Algol and Pascal, lexical scoping of functions.
- - Constructing Calls: Dispatching a call to another function.
- - Thread-Local: Per-thread variables.
- - Pragmas: Pragmas accepted by GCC.
-
-
- The following GCC extensions are partially supported. An ignored
- attribute means that the LLVM compiler ignores the presence of the attribute,
- but the code should still work. An unsupported attribute is one which is
- ignored by the LLVM compiler and will cause a different interpretation of
- the program.
+ llvm-gcc does not support __builtin_apply yet.
+ See Constructing Calls: Dispatching a call to another function.
+llvm-gcc partially supports these GCC extensions:
- - Variable Length:
- Arrays whose length is computed at run time.
- Supported, but allocated stack space is not freed until the function returns (noted above).
+ - Nested Functions:
+
+ As in Algol and Pascal, lexical scoping of functions.
+ Nested functions are supported, but llvm-gcc does not support
+ taking the address of a nested function (except on the X86-32 target)
+ or non-local gotos.
- Function Attributes:
Declaring that functions have no side effects or that they can never
return.
- Supported: alias, constructor, destructor,
+ Supported: alias, always_inline, cdecl,
+ const, constructor, destructor,
deprecated, fastcall, format,
- format_arg, non_null, noreturn, regparm
+ format_arg, non_null, noinline,
+ noreturn, pure, regparm
section, stdcall, unused, used,
visibility, warn_unused_result, weak
- Ignored: noinline,
- always_inline, pure, const, nothrow,
- malloc, no_instrument_function, cdecl
-
- Unsupported: All other target specific attributes
-
- - Variable Attributes:
- Specifying attributes of variables.
- Supported: alias, cleanup, common,
- nocommon, deprecated, dllimport,
- dllexport, section, transparent_union,
- unused, used, weak
-
- Unsupported: aligned, mode, packed,
- shared, tls_model,
- vector_size, all target specific attributes.
-
-
- - Type Attributes: Specifying attributes of types.
- Supported: transparent_union, unused,
- deprecated, may_alias
-
- Unsupported: aligned, packed,
- all target specific attributes.
-
- - Other Builtins:
- Other built-in functions.
- We support all builtins which have a C language equivalent (e.g.,
- __builtin_cos), __builtin_alloca,
- __builtin_types_compatible_p, __builtin_choose_expr,
- __builtin_constant_p, and __builtin_expect
- (currently ignored). We also support builtins for ISO C99 floating
- point comparison macros (e.g., __builtin_islessequal),
- __builtin_prefetch, __builtin_popcount[ll],
- __builtin_clz[ll], and __builtin_ctz[ll].
+ Ignored: nothrow, malloc,
+ no_instrument_function
The following extensions are known to be supported:
+llvm-gcc supports the vast majority of GCC extensions, including:
+ - Pragmas: Pragmas accepted by GCC.
+ - Local Labels: Labels local to a block.
+ - Other Builtins:
+ Other built-in functions.
+ - Variable Attributes:
+ Specifying attributes of variables.
+ - Type Attributes: Specifying attributes of types.
+ - Thread-Local: Per-thread variables.
+ - Variable Length:
+ Arrays whose length is computed at run time.
- Labels as Values: Getting pointers to labels and computed gotos.
- Statement Exprs: Putting statements and declarations inside expressions.
- Typeof:
typeof: referring to the type of an expression.
@@ -549,8 +623,9 @@ tested and works for a number of non-trivial programs, including LLVM
itself, Qt, Mozilla, etc.
-- llvm-gcc4 only has partial support for C++
-Exception Handling, and it is not enabled by default.
+- Exception handling only works well on the linux/X86-32 target.
+In some cases, illegally throwing an exception does not result
+in a call to terminate.