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 @@ -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.
This is the seventh public release of the LLVM Compiler Infrastructure. This -release incorporates a large number of enhancements and additions (primarily in -the code generator), which combine to improve the quality of the code generated -by LLVM by up to 30% in some cases. This release is also the first release to -have first-class support for Mac OS X: all of the major bugs have been shaken -out and it is now as well supported as Linux on X86.
+This is the twelfth public release of the LLVM Compiler Infrastructure. +It includes many features and refinements from LLVM 2.0.
LLVM now includes support for auto-generating large portions of the -instruction selectors from target descriptions. This allows us to -write patterns in the target .td file, instead of writing lots of -nasty C++ code. Most of the PowerPC instruction selector is now -generated from the PowerPC target description files and other targets -are adding support that will be live for LLVM 1.7.
-For example, here are some patterns used by the PowerPC backend. A -floating-point multiply then subtract instruction (FMSUBS):
+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!
--(set F4RC:$FRT, (fsub (fmul F4RC:$FRA, F4RC:$FRC), F4RC:$FRB)) -
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.
-Exclusive-or by 16-bit immediate (XORI):
+-(set GPRC:$dst, (xor GPRC:$src1, immZExt16:$src2)) -
Exclusive-or by 16-bit immediate shifted right 16-bits (XORIS):
+-(set GPRC:$dst, (xor GPRC:$src1, imm16Shifted:$src2)) -
Some of the most noticable feature improvements this release have been in the +optimizer, speeding it up and making it more aggressive. For example:
-With these definitions, we teach the code generator how to combine these two -instructions to xor an abitrary 32-bit immediate with the following -definition. The first line specifies what to match (a xor with an arbitrary -immediate) the second line specifies what to produce:
+-
+
+
- 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. -
-
def : Pat<(xor GPRC:$in, imm:$imm), - (XORIS (XORI GPRC:$in, (LO16 imm:$imm)), (HI16 imm:$imm))>; --
Instruction selectors using the refined instruction selection framework can now -use a simple pre-pass scheduler included with LLVM 1.6. This scheduler is -currently simple (cannot be configured much by the targets), but will be -extended in the future.
-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. + +
- 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. - -
- LLVM on Win32 no longer requires sed, - flex, or bison when compiling with Visual C++. -
- The llvm-test suite can now use the NAG Fortran to C compiler to compile - SPEC FP programs if available (allowing us to test all of SPEC'95 & - 2000). -
- When bugpoint is grinding away and the user hits ctrl-C, it now - gracefully stops and gives what it has reduced so far, instead of - giving up completely. In addition, the JIT - debugging mode of bugpoint is much faster. -
- LLVM now includes Xcode project files in the llvm/Xcode directory. -
- LLVM now supports Mac OS X on Intel. -
- LLVM now builds cleanly with GCC 4.1. -
- 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. +
- The -globalopt pass can now statically evaluate C++ static - constructors when they are simple enough. For example, it can - now statically initialize "struct X { int a; X() : a(4) {} } g;". - -
- The Loop Strength Reduction pass has been completely rewritten, is far - more aggressive, and is turned on by default in the RISC targets. On PPC, - we find that it often speeds up programs from 10-40% depending on the - program. -
- The code produced when exception handling is enabled is far more - efficient in some cases, particularly on Mac OS X. -
- 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. +
- The Alpha backend is substantially more stable and robust than in LLVM 1.5. - For example, it now fully supports varargs functions. The Alpha backend - also now features beta JIT support. -
- The code generator contains a new component, the DAG Combiner. This allows - us to optimize lowered code (e.g. after 64-bit operations have been lowered - to use 32-bit registers on 32-bit targets) and do fine-grained bit-twiddling - optimizations for the backend. -
- The SelectionDAG infrastructure is far more capable and mature, able to - handle many new target peculiarities in a target-independent way. -
- The default register allocator is now far - faster on some testcases, - particularly on targets with a large number of registers (e.g. IA64 - and PPC). -
- 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. +
- A vast number of bugs have been fixed in the PowerPC backend and in - llvm-gcc when configured for Mac OS X (particularly relating to ABI - issues). For example: - PR449, - PR594, - PR603, - PR609, - PR630, - PR643, - and several others without bugzilla bugs. -
- Several bugs in tail call support have been fixed. -
- configure does not correctly detect gcc - version on cygwin. -
- Many many other random bugs have been fixed. Query our bugzilla with a target of 1.6 for more - information. -
- 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. +
- 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.
- 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. +
- The following passes are incomplete or buggy, and may be removed in future - releases: -cee, -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 SparcV8 and IA64 code generators are experimental. -
- The Alpha JIT is experimental. +
- 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).
- In the JIT, dlsym() on a symbol compiled by the JIT will not - work. +
- 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. +
- 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. -
- 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:
-
-
-
- sigsetjmp, siglongjmp - These are not turned into the - appropriate invoke/unwind instructions. Note that - setjmp and longjmp are compiled correctly. -
- 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:
-
-
- 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. -
- Extended Asm: Assembler instructions with C expressions as operands. -
- Constraints: Constraints for asm operands. -
- Asm Labels: Specifying the assembler name to use for a C symbol. -
- Explicit Reg Vars: Defining variables residing in specified registers. -
- Vector Extensions: Using vector instructions through built-in functions. -
- Target Builtins: Built-in functions specific to particular targets. -
- Thread-Local: Per-thread variables. -
- 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.
- --
-
- Variable Length:
- Arrays whose length is computed at run time.
- Supported, but allocated stack space is not freed until the function returns (noted above).
+ 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.
- Variable Length:
- Arrays whose length is computed at run time.
- 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
-
- - 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.
+ 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 - 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
+
- 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.
@@ -469,6 +575,12 @@ work:
- Empty Structures: Structures with no members.
- Variadic Macros: Macros with a variable number of arguments.
- Escaped Newlines: Slightly looser rules for escaped newlines. +
- Extended Asm: Assembler instructions with C expressions as operands. +
- Constraints: Constraints for asm operands. +
- Asm Labels: Specifying the assembler name to use for a C symbol. +
- Explicit Reg Vars: Defining variables residing in specified registers. +
- Vector Extensions: Using vector instructions through built-in functions. +
- Target Builtins: Built-in functions specific to particular targets.
- Subscripting: Any array can be subscripted, even if not an lvalue.
- Pointer Arith: Arithmetic on
void-pointers and function pointers. - Initializers: Non-constant initializers. @@ -506,38 +618,16 @@ lists, please let us know (also including whether or not they work).
- The C++ front-end inherits all problems afflicting the C - front-end. - -
- 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. -
- The C++ front-end is based on a pre-release of the GCC 3.4 C++ parser. This -parser is significantly more standards compliant (and picky) than prior GCC -versions. For more information, see the C++ section of the GCC 3.4 release notes. + - - -
- 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. - -
- None yet -
- 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). - +-->
- Many features are still missing (e.g. support for 64-bit integer -arithmetic). This back-end is in pre-beta state. -
-- - -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.
- -Bugs- -- -- - --
-
- Notes -- -+itself, Qt, Mozilla, etc.-
+
- -- - - - - - - - - --
-
-
- -- - - - - - - - - --
-
- -- - - - --
-
-
- -- - - --
-
-
--
-
@@ -691,11 +661,10 @@ arithmetic). This back-end is in pre-beta state.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.
@@ -714,7 +683,7 @@ lists.- The LLVM Compiler Infrastructure
+ LLVM Compiler Infrastructure
Last modified: $Date$
It is now straight-forward to parameterize a target implementation, and -provide a mapping from CPU names to sets of target parameters. LLC now supports -a -mcpu=cpu option that lets you choose a subtarget by CPU name: use -"llvm-as < /dev/null | llc -march=XXX -mcpu=help" to get a list of -supported CPUs for target "XXX". It also provides a --mattr=+attr1,-attr2 option that can be used to control individual -features of a target (the previous command will list available features as -well).
+This functionality is nice when you want tell LLC something like "compile to -code that is specialized for the PowerPC G5, but doesn't use altivec code. In -this case, using "llc -march=ppc32 -mcpu=g5 -mattr=-altivec".
+-
-
New features include: +
+ +-
+
-
-
New features include: +
+ +-
+
-
-
New features include: +
+ +-
+
-
-
New features include: +
+ +-
+
LLVM is known to work on the following platforms:
-
-
-
+
-
-
-
-
-
+
-
+
-
+
+
-
+
+
-
+
-
-
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.
+-
-
-
The following extensions are known to be supported:
+