LLVM 1.7 Release Notes

@@ -32,12 +32,10 @@

This document contains the release notes for the LLVM compiler -infrastructure, release 1.7. 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 releases 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 @@ -45,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.

@@ -60,221 +58,235 @@ href="http://llvm.org/releases/">releases page.

This is the eighth public release of the LLVM Compiler Infrastructure. This -release incorporates a large number of enhancements and new features, -including vector support (Intel SSE and Altivec), a new GCC4.0-based -C/C++ front-end, Objective C/C++ support, inline assembly support, and many -other big features. -

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

-New Features in LLVM 1.7 +New Frontends

- -

GCC4.0-based llvm-gcc -front-end

LLVM 1.8 includes a brand new llvm-gcc, based on GCC 4.0.1. This version -of llvm-gcc solves many serious long-standing problems with llvm-gcc, including -all of those blocked by the llvm-gcc 4 meta -bug. In addition, llvm-gcc4 implements support for many new features, -including GCC inline assembly, generic vector support, SSE and Altivec -intrinsics, and several new GCC attributes. In addition, llvm-gcc4 is -significantly faster than llvm-gcc3, respects -O options, its -c/-S options -correspond to GCC's (they emit native code), and it has debugging support well -underway.

- -

If you can use it, llvm-gcc4 is offers significant new functionality, and we -hope that it will replace llvm-gcc3 completely in a future release. -Unfortunately, it does not currently support C++ exception handling at all, and -it only works on Apple Mac OS/X machines with X86 or PowerPC processors. -

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.

- -

Inline Assembly -Support

+ +

+Optimizer Improvements +

The LLVM IR and llvm-gcc4 front-end now fully support arbitrary GCC inline assembly. The LLVM X86 and PowerPC -code generators have initial support for it, -being able to compile basic statements, but are missing some features. Please -report any inline asm statements that crash the compiler or that are miscompiled -as bugs.

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.

- -

New SPARC backend

+ +

+Code Generator Improvements +

LLVM 1.7 includes a new, fully functional, SPARC backend built in the -target-independent code generator. This SPARC backend includes support for -SPARC V8 and SPARC V9 subtargets (controlling whether V9 features can be used), -and targets the 32-bit SPARC ABI.

One of the main focuses of this release was performance tuning and bug + fixing. In addition to these, several new major changes occurred:

The LLVM 1.7 release is the last release that will include the LLVM "SparcV9" -backend, which was the very first LLVM native code generator. In 1.8, it will -be removed, replaced with the new SPARC backend.

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.

- -

Generic Vector Support -

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.

LLVM now includes significantly extended support for SIMD vectors in its -core instruction set. It now includes three new instructions for manipulating -vectors: extractelement, -insertelement, and -shufflevector. Further, -many bugs in vector handling have been fixed, and vectors are now supported by -the target-independent code generator. For example, if a vector operation is -not supported by a particular target, it will be correctly broken down and -executed as scalar operations.

- -

Because llvm-gcc3 does not support GCC generic vectors or vector intrinsics, -so llvm-gcc4 must be used.

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

- -

Intel SSE and PowerPC -Altivec support -

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.

The LLVM X86 backend now supports Intel SSE 1, 2, and 3, and now uses scalar -SSE operations to implement scalar floating point math when the target supports -SSE1 (for floats) or SSE2 (for doubles). Vector SSE instructions are generated -by llvm-gcc4 when the generic vector mechanism or specific SSE intrinsics are -used. -

David Greene refactored the register allocator to split coalescing out from + allocation, making coalescers pluggable.

The LLVM PowerPC backend now supports the Altivec instruction set, including -both GCC -maltivec and -faltivec modes. Altivec instructions are generated -by llvm-gcc4 when the generic vector mechanism or specific Altivec intrinsics -are used. -

- -

Optimizer -Improvements

+ + +

+Target Specific Improvements +

New features include: +

The Loop Unswitching pass (-loop-unswitch) has had several bugs - fixed, has several new features, and is enabled by default in llvmgcc3 - now.
The Loop Strength Reduction pass (-loop-reduce) is now enabled for - the X86 backend.
The Instruction Combining pass (-instcombine) now includes a - framework and implementation for simplifying code based on whether computed - bits are demanded or not.
The Scalar Replacement of Aggregates pass (-scalarrepl) can now - promote simple unions to registers.
The Reassociation pass (-reassociate) can now - factor expressions, e.g. turning "A*A+A*B" into "A*(A+B)".
Several LLVM passes are significantly -faster.
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.

- -

Code Generator -Improvements

+ + +

+llvm-gcc Improvements +

New features include: +

LLVM has a new prepass (before register allocation) list scheduler, which - supports bottom-up and top-down scheduling, pluggable priority functions and - pluggable hazard recognizers. The X86 backend uses this to reduce register - pressure and RISC targets schedule based on operation latency.
The tblgen-based target description framework introduced in LLVM 1.6 has - several new features, useful for targets that can fold loads and stores into - operations, and features that make the .td files more expressive.
The instruction selector is significantly faster in 1.7 than in 1.6.
The X86, Alpha and Itanium backends use new DAG-DAG instruction selectors, - making them easier to maintain and generate slightly better code.
The X86 backend now supports generation of Scalar SSE code for scalar FP - expressions. LLVM provides significantly better performance with Scalar SSE - instructions than it does with the Intel floating point stack - instructions.
The Itanium backend now has a bundling pass, which improves performance - by ~10% and reduces code size (previously it unconditionally inserted a stop - bit after every instruction).
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.

- -

Other New Features

+ + +

+LLVM Core Improvements +

New features include: +

The Mac OS/X PowerPC and X86 backends now have initial support Darwin DWARF - debugging information, however, debug info generation has been disabled for - the 1.7 release in llvmgcc4.
LLVM includes the new - llvm-config utility, which makes it easier to build and link programs - against the LLVM libraries when not using the LLVM makefiles.
LLVM now supports first class global ctor/dtor initialization lists, no - longer forcing targets to use "__main".
LLVM supports assigning globals and functions to a particular section - in the result executable using the GCC section attribute.
Adding intrinsics to LLVM is now - significantly easier.
llvmgcc4 now fully supports C99 Variable Length Arrays, including dynamic - stack deallocation.
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.

-Significant Changes in LLVM 1.7 +Other Improvements

New features include: +

The official LLVM URL is now - http://llvm.org/.
The LLVM intrinsics used to be overloaded based on type: for example, - llvm.ctpop could work with any - integer datatype. They are now separated into different intrinsics with - suffixes to denote their argument type (e.g. llvm.ctpop.i32)). Old - LLVM .ll and .bc files that use these intrinsics will continue to work with - new LLVM versions (they are transparently upgraded by the parsers), but will - cause a warning to be emitted.
The llvm.readport, llvm.writeport, llvm.readio, - and llvm.writeio intrinsics have been removed. The first two - were ever only supported by the X86 backend, the last two were never - correctly supported by any target, and none were accessible through the - C front-end. Inline assembly support can now be used to - implement these operations.
The llvm-db tool had basic support for stepping through code, which - used the JIT. This code has been removed, and DWARF emission support added - instead. llvm-db still exists in CVS if someone wanted to write a - ptrace backend for it.
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.

Portability and Supported Platforms @@ -286,12 +298,14 @@ Improvements

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).
Sun UltraSPARC workstations running Solaris 8.
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)
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.
Sun UltraSPARC workstations running Solaris 8.
Alpha-based machines running Debian GNU/Linux.
Itanium-based machines running Linux and HP-UX.

@@ -331,13 +345,14 @@ there isn't already one.

be broken or unreliable, or are in early development. These components should not be relied on, and bugs should not be filed against them, but they may be useful to some people. In particular, if you would like to work on one of these -components, please contact us on the llvmdev list.

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

@@ -346,60 +361,150 @@ components, please contact us on the llvmdev list.

- Known problems with the Build System + Known problems with the X86 back-end

The configure script sometimes fails on Solaris/Sparc. A work around is documented in PR656.
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).

+ +

+ + +

+ Known problems with the PowerPC back-end

+ +

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.

+ +

- Known problems with the LLVM Core + Known problems with the ARM back-end

In the JIT, dlsym() on a symbol compiled by the JIT will not - work.
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.

- Known problems with the C front-end + Known problems with the SPARC back-end

- -

Bugs

+ +

The SPARC backend only supports the 32-bit SPARC ABI (-m32), it does not + support the 64-bit SPARC ABI (-m64).

+ +

+ + +

+ Known problems with the Alpha back-end +

-llvm-gcc3 has many significant problems that are fixed by llvm-gcc4. See - those blocked on the llvm-gcc4 meta bug. -Two signicant ones include:

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

+ + +

+ Known problems with the IA64 back-end +

+ +

With llvm-gcc3, - C99 variable sized arrays do not release stack memory when they go out of - scope. Thus, the following program may run out of stack space: -
```
-    for (i = 0; i != 1000000; ++i) {
-      int X[n];
-      foo(X);
-    }
-
```
With llvm-gcc3, Initialization of global union variables can only be done with the largest union member.
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.

+ +

+ + +

+ Known problems with the C back-end +

+ +

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.

+ +

+ + + +

+ Known problems with the C front-end +

+ + +

Bugs

+ +

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.

@@ -408,101 +513,56 @@ href="http://llvm.org/PR162">with the largest union member.

"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, used, - deprecated, warn_unused_result, weak
  - - Ignored: noinline, - always_inline, pure, const, nothrow, - malloc, no_instrument_function, cdecl
  - - Unsupported: 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, used, 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
  + Supported: alias, always_inline, cdecl, + const, constructor, destructor, + deprecated, fastcall, format, + format_arg, non_null, noinline, + noreturn, pure, regparm + section, stdcall, unused, used, + visibility, warn_unused_result, weak
  - 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.