LLVM 1.5 Release Notes

-This release implements the following new features: +

LLVM now includes an - Interprocedural Sparse Conditional Constant Propagation pass, named - -ipsccp, which is run by default at link-time.
LLVM 1.5 is now about 15% faster than LLVM 1.4 and its core data structures - use about 30% less memory.
LLVM includes new experimental native code generators for SparcV8, - Alpha, and IA64.
Support for Microsoft Visual Studio is improved, and now documented.
Configuring LLVM to build targets selectively is now implemented, via the - --enable-targets= option. This feature is documented - here.

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.

+ +

+ + +

+Optimizer Improvements

+ +

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.

+ +

-In this release, the following missing features were implemented: +

+Code Generator Improvements

LLVM can now create native shared libraries with 'llvm-gcc ... - -shared -Wl,-native' (or with -Wl,-native-cbe).
LLVM now supports a new "llvm.prefetch - " intrinsic, and llvm-gcc now supports __builtin_prefetch. -

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 this release, the following Quality of Implementation -issues were fixed: +

+Target Specific Improvements

New features include: +

Building LLVM in optimized mode - should no longer cause GCC to hit swap in the PowerPC backend.

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.

+ -

-This release includes the following Code Quality -improvements: +

+llvm-gcc Improvements

Transition code for 1.0 style varargs was removed.

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.

+ -

-In this release, the following bugs in the previous release -were fixed: +

+LLVM Core Improvements

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.

Bugs fixed in the LLVM Core:

LLVM now provides an LLVMBuilder class, which makes it significantly easier + to create LLVM IR instructions.

Code Generator Bugs:

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.

+ +

Bugs in the C/C++ front-end:

+ +

+Other Improvements +

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.

@@ -195,13 +298,16 @@ were fixed:

LLVM is known to work on the following platforms:

Intel and AMD machines running Red Hat Linux and FreeBSD (and probably - other unix-like systems).
Sun UltraSPARC workstations running Solaris 8.
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)
Intel and AMD machines running on Win32 with the Cygwin libraries (limited support is available for native builds with Visual C++).
PowerPC-based Mac OS X systems, running 10.2 and above.
Alpha-based machines running Debian GNU/Linux
Sun UltraSPARC workstations running Solaris 8.
Alpha-based machines running Debian GNU/Linux.
Itanium-based machines running Linux and HP-UX.

The core LLVM infrastructure uses @@ -223,7 +329,7 @@ portability patches and reports of successful builds or error messages.

This section contains all known problems with the LLVM system, listed by component. As new problems are discovered, they will be added to these sections. If you run into a problem, please check the LLVM bug database and submit a bug if +href="http://llvm.org/bugs/">LLVM bug database and submit a bug if there isn't already one.

@@ -239,41 +345,152 @@ 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 a + future release.
The MSIL backend is experimental.
The IA64 code generator is experimental.
The Alpha backend is experimental.
"-filetype=asm" (the default) is the only supported value for the + -filetype llc option.

+ +

+ + +

+ Known problems with the X86 back-end +

+ +

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 +

+ +

The following passes are incomplete or buggy, and may be removed in future - releases: -cee, -branch-combine, -instloops, -paths, -pre
The llvm-db tool is in a very early stage of development, but can - be used to step through programs and inspect the stack.
The "iterative scan" register allocator (enabled with - -regalloc=iterativescan) is not stable.
The SparcV8, Alpha, and IA64 ports are experimental.
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.
The JIT does not use mutexes to protect its internal data structures. As - such, execution of a threaded program could cause these data structures to be - corrupted. -
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.
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 SPARC back-end +

+ +

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 +

+ +

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 +

+ +

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 @@ -283,20 +500,11 @@ components, please contact us on the llvmdev list.

Bugs

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);
-    }
-
```
Initialization of global union variables can only be done with the largest union member.

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.

@@ -305,102 +513,56 @@ href="http://llvm.cs.uiuc.edu/PR162">with the largest union member.

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
  + 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, 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), and - __builtin_prefetch.
+

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.