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.
This is the eleventh public release of the LLVM Compiler Infrastructure. -Being the first major release since 1.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.
- -Note that while - This -release -incorporates a large number of enhancements, new features, and bug -fixes. We recommend that all users of previous LLVM versions upgrade. -
+This is the twelfth public release of the LLVM Compiler Infrastructure. +It includes many features and refinements from LLVM 2.0.
The mid-level optimizer is now faster and produces better code in many cases. - Significant changes include:
+ +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.
+ +Some of the most noticable feature improvements this release have been in the +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. +
-The LLVM Target-Independent code generator now supports more target features and -optimizes many cases more aggressively. 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:
-
-
+
+
- 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. +
In addition, the LLVM target description format has itself been extended in - several ways:
- +New features include: +
+-
-
+
- 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.
Further, several significant target-specific enhancements are included in -LLVM 2.0:
+ + + + +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. + +
- Devang and Duncan fixed a huge number of bugs relating to bitfields, pragma + pack, and variable sized fields in structures. + +
- 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.
More specific changes include:
+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.
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.
-
-
- 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. +
- The MSIL backend is experimental.
- The IA64 code generator is experimental. -
- The ARM 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.
-
-
- The SPARC backend only supports the 32-bit SPARC ABI (-m32), it does not - support the 64-bit SPARC ABI (-m64). +
- Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6 +processors, thumb programs can crash or produce wrong +results (PR1388). +
- Compilation for ARM Linux OABI (old ABI) is supported, but not fully tested. + +
- There is a bug in QEMU-ARM (<= 0.9.0) which causes it to incorrectly execute +programs compiled with LLVM. Please use more recent versions of QEMU.
-
-
-
- The C back-end produces code that violates the ANSI C Type-Based Alias -Analysis rules. As such, special options may be necessary to compile the code -(for example, GCC requires the -fno-strict-aliasing option). This -problem probably cannot be fixed. - -
- Zero arg vararg functions are not -supported. This should not affect LLVM produced by the C or C++ -frontends. - -
- The C backend does not correctly implement the llvm.stacksave or -llvm.stackrestore -intrinsics. This means that some code compiled by it can run out of stack -space if they depend on these (e.g. C99 varargs). - -
- The C backend does not support inline - assembly code. +
- The SPARC backend only supports the 32-bit SPARC ABI (-m32), it does not + support the 64-bit SPARC ABI (-m64).
-
-
- The ARM backend is currently in early development stages, it is not -ready for production use. +
- The C backend does not support inline + assembly code. +
- The C backend does not support vectors + yet. +
- The C backend violates the ABI of common + C++ programs, preventing intermixing between C++ compiled by the CBE and + C++ code compiled with LLC or native compilers.
-
-
- In the JIT, dlsym() on a symbol compiled by the JIT will not - work. -
- -
llvm-gcc4 is far more stable and produces better code than llvm-gcc3, but -does not currently support Link-Time -Optimization or C++ Exception Handling, -which llvm-gcc3 does.
- -llvm-gcc4 does not support the GCC indirect -goto extension, but llvm-gcc3 does.
+llvm-gcc4 does not currently support Link-Time +Optimization on most platforms "out-of-the-box". Please inquire on the +llvmdev mailing list if you are interested.
-
-
- "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: constructor, destructor, + Supported: alias, always_inline, cdecl, + const, constructor, destructor, deprecated, fastcall, format, - format_arg, non_null, noreturn, + 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: alias, regparm, all other target specific - attributes
-
- - Variable Attributes:
- Specifying attributes of variables.
- Supported: 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
+
- - Variable Length:
- Arrays whose length is computed at run time.
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.
@@ -517,20 +618,16 @@ lists, please let us know (also including whether or not they work).
- llvm-gcc4 does not support C++ exception handling at all yet. +
- 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. + +
-+itself, Qt, Mozilla, etc. - -For this release, the C++ front-end is considered to be fully +
The C++ front-end is considered to be fully tested and works for a number of non-trivial programs, including LLVM -itself.
- -- Notes -- -@@ -564,11 +661,10 @@ itself.-
-
A wide variety of additional information is available on the LLVM web page, including documentation and publications describing algorithms and -components implemented in LLVM. The web page also contains versions of the -API documentation which is up-to-date with the CVS version of the source code. +href="http://llvm.org">LLVM web page, in particular in the documentation section. The web page also +contains versions of the API documentation which is up-to-date with the +Subversion version of the source code. You can access versions of these documents specific to this release by going into the "llvm/doc/" directory in the LLVM tree.
@@ -587,7 +683,7 @@ lists.- The LLVM Compiler Infrastructure
+ LLVM Compiler Infrastructure
Last modified: $Date$
The following extensions are known to be supported:
+