This document contains the release notes for the LLVM compiler -infrastructure, release 1.6. Here we describe the status of LLVM, including any -known problems and major improvements from the previous release. The most -up-to-date version of this document can be found on the LLVM 1.6 web site. If you are -not reading this on the LLVM web pages, you should probably go there because -this document may be updated after the release.

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

For more information about LLVM, including information about the latest -release, please check out the main LLVM +release, please check out the main LLVM 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 seventh public release of the LLVM Compiler Infrastructure.

+

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

-

LLVM 1.6 is known to correctly compile a wide range of C and C++ programs, -includes bug fixes for those problems found since the 1.5 release, and includes -a large number of new features and enhancements, described below.

+

+ +

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.

-

- See LLVM 1.5 Release Notes -

-

The JIT now uses mutexes to protect its internal data structures. This - allows multi-threaded programs to be run from the JIT or interpreter without - corruption of the internal data structures. See - PR418 and - PR540 for the details. -

+ +

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.

+

+ +

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.

+

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.

+ +

-

[simplify-libcalls] The simplify-libcalls pass generates ill-formed LLVM code.

+

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.

+ +

+

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.

+

In the JIT, dlsym() on a symbol compiled by the JIT will not - work.
The lower-invoke pass does not - mark values live across a setjmp as volatile. This missing feature - only affects targets whose setjmp/longjmp libraries do not save and restore - the entire register file.
The X86 backend does not yet support 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).

+

+ +

PowerPC backend does not correctly +implement ordered FP comparisons.
The Linux PPC32/ABI support needs testing for the interpreter and static +compilation, and lacks support for debug information.

+ +

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 SPARC backend only supports the 32-bit SPARC ABI (-m32), it does not + support the 64-bit SPARC ABI (-m64).

+ +

On 21164s, some rare FP arithmetic sequences which may trap do not have the +appropriate nops inserted to ensure restartability.

+

+ +

C++ programs are likely to fail on IA64, as calls to setjmp are +made where the argument is not 16-byte aligned, as required on IA64. (Strictly +speaking this is not a bug in the IA64 back-end; it will also be encountered +when building C++ programs using the C back-end.)
The C++ front-end does not use IA64 +ABI compliant layout of v-tables. In particular, it just stores function +pointers instead of function descriptors in the vtable. This bug prevents +mixing C++ code compiled with LLVM with C++ objects compiled by other C++ +compilers.
There are a few ABI violations which will lead to problems when mixing LLVM +output with code built with other compilers, particularly for floating-point +programs.
Defining vararg functions is not supported (but calling them is ok).
The Itanium backend has bitrotted somewhat.

+ +

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.

+ +

-

Inline assembly is not yet supported.
"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.
The following Unix system functionality has not been tested and may not -work: -
1. sigsetjmp, siglongjmp - These are not turned into the - appropriate invoke/unwind instructions. Note that - setjmp and longjmp are compiled correctly. -
2. getcontext, setcontext, makecontext - - These functions have not been tested. -
llvm-gcc does not support __builtin_apply yet. + See Constructing Calls: Dispatching a call to another function.
+
Although many GCC extensions are supported, some are not. In particular, - the following extensions are known to not be supported: +
llvm-gcc partially supports these GCC extensions:
1. Local Labels: Labels local to a block.
2. Nested Functions: As in Algol and Pascal, lexical scoping of functions.
3. Constructing Calls: Dispatching a call to another function.
4. Extended Asm: Assembler instructions with C expressions as operands.
5. Constraints: Constraints for asm operands.
6. Asm Labels: Specifying the assembler name to use for a C symbol.
7. Explicit Reg Vars: Defining variables residing in specified registers.
8. Vector Extensions: Using vector instructions through built-in functions.
9. Target Builtins: Built-in functions specific to particular targets.
10. Thread-Local: Per-thread variables.
11. Pragmas: Pragmas accepted by GCC.
+
Nested Functions: -
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.
- -
1. Variable Length: - Arrays whose length is computed at run time.
  - Supported, but allocated stack space is not freed until the function returns (noted above).
2. Function Attributes: Declaring that functions have no side effects or that they can never return.
  - Supported: format, format_arg, non_null, - noreturn, constructor, destructor, - unused, - deprecated, warn_unused_result, weak
  - - Ignored: noinline, - always_inline, pure, const, nothrow, - malloc, no_instrument_function, cdecl
  - - Unsupported: used, section, alias, - visibility, regparm, stdcall, - fastcall, all other target specific attributes
3. Variable Attributes: - Specifying attributes of variables.
  - Supported: cleanup, common, nocommon, - deprecated, transparent_union, - unused, weak
  - - Unsupported: aligned, mode, packed, - section, shared, tls_model, - vector_size, dllimport, - dllexport, all target specific attributes.
4. Type Attributes: Specifying attributes of types.
  - Supported: transparent_union, unused, - deprecated, may_alias
  - - Unsupported: aligned, packed, - all target specific attributes.
5. 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].
+

The following extensions are known to be supported:

llvm-gcc supports the vast majority of GCC extensions, including:
1. Pragmas: Pragmas accepted by GCC.
2. Local Labels: Labels local to a block.
3. Other Builtins: + Other built-in functions.
4. Variable Attributes: + Specifying attributes of variables.
5. Type Attributes: Specifying attributes of types.
6. Thread-Local: Per-thread variables.
7. Variable Length: + Arrays whose length is computed at run time.
8. Labels as Values: Getting pointers to labels and computed gotos.
9. Statement Exprs: Putting statements and declarations inside expressions.
10. Typeof: typeof: referring to the type of an expression.
11. Empty Structures: Structures with no members.
12. Variadic Macros: Macros with a variable number of arguments.
13. Escaped Newlines: Slightly looser rules for escaped newlines.
14. Extended Asm: Assembler instructions with C expressions as operands.
15. Constraints: Constraints for asm operands.
16. Asm Labels: Specifying the assembler name to use for a C symbol.
17. Explicit Reg Vars: Defining variables residing in specified registers.
18. Vector Extensions: Using vector instructions through built-in functions.
19. Target Builtins: Built-in functions specific to particular targets.
20. Subscripting: Any array can be subscripted, even if not an lvalue.
21. Pointer Arith: Arithmetic on void-pointers and function pointers.
22. Initializers: Non-constant initializers.