This document contains the release notes for the LLVM Compiler -Infrastructure, release 2.4. Here we describe the status of LLVM, including +Infrastructure, release 2.7. Here we describe the status of LLVM, including major improvements from the previous release and significant known problems. -All LLVM releases may be downloaded from the LLVM releases web site.
For more information about LLVM, including information about the latest @@ -46,23 +53,45 @@ List is a good place to send them.
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 +current one. To see the release notes for a specific release, please see the releases page.
-The LLVM 2.4 distribution currently consists of code from the core LLVM -repository (which roughly includes the LLVM optimizers, code generators and -supporting tools) and the llvm-gcc repository. In addition to this code, the -LLVM Project includes other sub-projects that are in development. The two which -are the most actively developed are the Clang Project and -the vmkit Project. +The LLVM 2.7 distribution currently consists of code from the core LLVM +repository (which roughly includes the LLVM optimizers, code generators +and supporting tools), the Clang repository and the llvm-gcc repository. In +addition to this code, the LLVM Project includes other sub-projects that are in +development. Here we include updates on these subprojects.
The Clang project is an effort to build -a set of new 'LLVM native' front-end technologies for the LLVM optimizer -and code generator. Clang is continuing to make major strides forward in all -areas. Its C and Objective-C parsing support is very solid, and the code -generation support is far enough along to build many C applications. While not -yet production quality, it is progressing very nicely. In addition, C++ -front-end work has started to make significant progress.
+The Clang project is ...
-Codegen progress/state [DANIEL]
+In the LLVM 2.7 time-frame, the Clang team has made many improvements:
+-
+
- ... +
The Clang project also includes an early stage static source code analysis -tool for automatically -finding bugs in C and Objective-C programs. The tool performs a growing set -of checks to find bugs that occur on a specific path within a program. Examples -of bugs the tool finds include logic errors such as null dereferences, -violations of various API rules, dead code, and potential memory leaks in -Objective-C programs. Since its inception, public feedback on the tool has been -extremely positive, and conservative estimates put the number of real bugs it -has found in industrial-quality software on the order of thousands.
+Previously announced in the 2.4, 2.5, and 2.6 LLVM releases, the Clang project also +includes an early stage static source code analysis tool for automatically finding bugs +in C and Objective-C programs. The tool performs checks to find +bugs that occur on a specific path within a program.
+ +In the LLVM 2.7 time-frame, the analyzer core has ...
+ ++The VMKit project is an implementation of +a JVM and a CLI Virtual Machine (Microsoft .NET is an +implementation of the CLI) using LLVM for static and just-in-time +compilation.
+ ++VMKit version ?? builds with LLVM 2.7 and you can find it on its +web page. The release includes +bug fixes, cleanup and new features. The major changes are:
+ +-
+
+
- ... + +
+The new LLVM compiler-rt project +is a simple library that provides an implementation of the low-level +target-specific hooks required by code generation and other runtime components. +For example, when compiling for a 32-bit target, converting a double to a 64-bit +unsigned integer is compiled into a runtime call to the "__fixunsdfdi" +function. The compiler-rt library provides highly optimized implementations of +this and other low-level routines (some are 3x faster than the equivalent +libgcc routines).
+ ++All of the code in the compiler-rt project is available under the standard LLVM +License, a "BSD-style" license.
-The tool also provides a simple web GUI to inspect potential bugs found by -the tool. While still early in development, the GUI illustrates some of the key -features of Clang: accurate source location information, which is used by the -GUI to highlight specific code expressions that relate to a bug (including those -that span multiple lines) and built-in knowledge of macros, which is used to -perform inline expansion of macros within the GUI itself.
+The set of checks performed by the static analyzer is gradually expanding, -and -future plans for the tool include full source-level inter-procedural analysis -and deeper checks such as buffer overrun detection. There are many opportunities -to extend and enhance the static analyzer, and anyone interested in working on -this project is encouraged to get involved!
+ + + ++The new LLVM KLEE project is a symbolic +execution framework for programs in LLVM bitcode form. KLEE tries to +symbolically evaluate "all" paths through the application and records state +transitions that lead to fault states. This allows it to construct testcases +that lead to faults and can even be used to verify algorithms. For more +details, please see the OSDI 2008 paper about +KLEE.
-The vmkit project is an implementation of -a JVM and a CLI Virtual Machines (Microsoft .NET is an -implementation of the CLI) using the Just-In-Time compiler of LLVM.
+The goal of DragonEgg is to make +gcc-4.5 act like llvm-gcc without requiring any gcc modifications whatsoever. +DragonEgg is a shared library (dragonegg.so) +that is loaded by gcc at runtime. It ... + -[NICOLAS]
++The LLVM Machine Code (MC) Toolkit project is ... +
+ +This release includes a huge number of bug fixes, performance tweaks and -minor improvements. Some of the major improvements and new features are listed -in this section. +
An exciting aspect of LLVM is that it is used as an enabling technology for + a lot of other language and tools projects. This section lists some of the + projects that have already been updated to work with LLVM 2.7.
+Rubinius is an environment +for running Ruby code which strives to write as much of the core class +implementation in Ruby as possible. Combined with a bytecode interpreting VM, it +uses LLVM to optimize and compile ruby code down to machine code. Techniques +such as type feedback, method inlining, and uncommon traps are all used to +remove dynamism from ruby execution and increase performance.
+ +Since LLVM 2.5, Rubinius has made several major leaps forward, implementing +a counter based JIT, type feedback and speculative method inlining.
+LLVM 2.4 includes several major new capabilities:
++MacRuby is an implementation of Ruby on top of +core Mac OS X technologies, such as the Objective-C common runtime and garbage +collector and the CoreFoundation framework. It is principally developed by +Apple and aims at enabling the creation of full-fledged Mac OS X applications. +
--
-
The most visible end-user change in LLVM 2.4 is that it includes many -optimizations and changes to make -O0 compile times much faster. You should see -improvements on the order of 30% or more faster than LLVM 2.3. There are many -pieces to this change, described in more detail below. The speedups and new -components can also be used for JIT compilers that want fast compilation as -well.
-
-The biggest change to the LLVM IR is that Multiple Return Values (which -were introduced in LLVM 2.3) have been generalized to full support for "First -Class Aggregate" values in LLVM 2.4. This means that LLVM IR supports using -structs and arrays as values in a function. This capability is mostly useful -for front-end authors, who prefer to treat things like complex numbers, simple -tuples, dope vectors, etc as Value*'s instead of as a tuple of Value*'s or as -memory values.
-
-LLVM 2.4 also includes an initial port for the PIC16 microprocessor. This -is the LLVM targer that only has support for 8 bit registers, and a number of -other crazy constraints. While the port is still in early development stages, -it shows some interesting things you can do with LLVM.
+
+MacRuby uses LLVM for optimization passes, JIT and AOT compilation of Ruby +expressions. It also uses zero-cost DWARF exceptions to implement Ruby exception +handling.
+ ++Pure +is an algebraic/functional programming language based on term rewriting. +Programs are collections of equations which are used to evaluate expressions in +a symbolic fashion. Pure offers dynamic typing, eager and lazy evaluation, +lexical closures, a hygienic macro system (also based on term rewriting), +built-in list and matrix support (including list and matrix comprehensions) and +an easy-to-use C interface. The interpreter uses LLVM as a backend to + JIT-compile Pure programs to fast native code.
+ +Pure versions ??? and later have been tested and are known to work with +LLVM 2.7 (and continue to work with older LLVM releases >= 2.3 as well). +
+LDC is an implementation of +the D Programming Language using the LLVM optimizer and code generator. +The LDC project works great with the LLVM 2.6 release. General improvements in +this +cycle have included new inline asm constraint handling, better debug info +support, general bug fixes and better x86-64 support. This has allowed +some major improvements in LDC, getting it much closer to being as +fully featured as the original DMD compiler from DigitalMars. +
+LLVM fully supports the llvm-gcc 4.2 front-end, which marries the GCC -front-ends and driver with the LLVM optimizer and code generator. It currently -includes support for the C, C++, Objective-C, Ada, and Fortran front-ends.
+ +-
-
- LLVM 2.4 supports the full set of atomic __sync_* builtins. LLVM -2.3 only supported those used by OpenMP, but 2.4 supports them all. While -llvm-gcc supports all of these builtins, note that not all targets do. X86 -support them all in both 32-bit and 64-bit mode and PowerPC supports them all -except for the 64-bit operations when in 32-bit mode. - -
- llvm-gcc now supports an -flimited-precision option, which tells -the compiler that it is ok to use low-precision approximations of certain libm -functions (like tan, log, etc). This allows you to get high performance if you -only need (say) 14-bits of precision. - -
- llvm-gcc now supports a C language extension known as "Blocks -. This feature is similar to nested functions and closures, but does not -require stack trampolines (with most ABIs) and supports returning closures -from functions that define them. Note that actually using Blocks -requires a small runtime that is not included with llvm-gcc. - -
- llvm-gcc now supports a new -flto option. On systems that support -transparent Link Time Optimization (currently Darwin systems with Xcode 3.1 and -later) this allows the use of LTO with other optimization levels like -Os. -Previously, LTO could only be used with -O4, which implied optimizations in --O3 that can increase code size. -
+Roadsend PHP (rphp) is an open +source implementation of the PHP programming +language that uses LLVM for its optimizer, JIT and static compiler. This is a +reimplementation of an earlier project that is now based on LLVM.
++Unladen Swallow is a +branch of Python intended to be fully +compatible and significantly faster. It uses LLVM's optimization passes and JIT +compiler.
+LLVM-Lua uses LLVM to add JIT +and static compiling support to the Lua VM. Lua bytecode is analyzed to +remove type checks, then LLVM is used to compile the bytecode down to machine +code.
++IcedTea provides a +harness to build OpenJDK using only free software build tools and to provide +replacements for the not-yet free parts of OpenJDK. One of the extensions that +IcedTea provides is a new JIT compiler named Shark which uses LLVM +to provide native code generation without introducing processor-dependent +code. +
+New features include: + +
This release includes a huge number of bug fixes, performance tweaks and +minor improvements. Some of the major improvements and new features are listed +in this section.
+LLVM 2.7 includes several major new capabilities:
+-
-
- A major change to the "Use" class landed, which shrank it by 25%. Since -this is a pervasive part of the LLVM, it ended up reducing the memory use of -LLVM IR in general by 15% for most programs. +
- ... +
LLVM IR has several new features for better support of new targets and that +expose new optimization opportunities:
+ +-
+
- ...
In addition to a huge array of bug fixes and minor performance tweaks, this +
In addition to a large array of minor performance tweaks and bug fixes, this release includes a few major enhancements and additions to the optimizers:
-
-
- The Global Value Numbering (GVN) pass now does local Partial Redundancy -Elimination (PRE) to eliminate some partially redundant expressions in cases -where doing so won't grow code size. - -
- LLVM 2.4 includes a new loop deletion pass (which removes output-free -provably-finite loops) and a rewritten Aggressive Dead Code Elimination (ADCE) -pass that no longer uses control dependence information. These changes speed up -the optimizer and also prevents it from deleting output-free infinite -loops. +
- ... -
- The new AddReadAttrs pass works out which functions are read-only or -read-none (these correspond to 'pure' and 'const' in C) and marks them -with the appropriate attribute. +
-
+
- The JIT now defaults +to compiling eagerly to avoid a race condition in the lazy JIT. +Clients that still want the lazy JIT can switch it on by calling +ExecutionEngine::DisableLazyCompilation(false). +
- It is now possible to create more than one JIT instance in the same process. +These JITs can generate machine code in parallel, +although you +still have to obey the other threading restrictions.
We put a significant amount of work into the code generator infrastructure, -which allows us to implement more aggressive algorithms and make it run -faster:
+We have put a significant amount of work into the code generator +infrastructure, which allows us to implement more aggressive algorithms and make +it run faster:
-
-
- The target-independent code generator supports (and the X86 backend - currently implements) a new interface for "fast" instruction selection. This - interface is optimized to produce code as quickly as possible, sacrificing - code quality to do it. This is used by default at -O0 or when using - "llc -fast" on X86. It is straight-forward to add support for - other targets if faster -O0 compilation is desired. - -
- In addition to the new 'fast' instruction selection path, many existing - pieces of the code generator have been optimized in significant ways. - SelectionDAG's are now pool allocated and use better algorithms in many - places, the ".s" file printers now use raw_ostream to emit text much faster, - etc. The end result of these improvements is that the compiler also takes - substantially less time to generate code that is just as good (and often - better) than before. - -
- Each target has been split to separate the .s file printing logic from the - rest of the target. This enables JIT compilers that don't link in the - (somewhat large) code and data tables used for printing a .s file. - -
- The code generator now includes a "stack slot coloring" pass, which packs - together individual spilled values into common stack slots. This reduces - the size of stack frames with many spills, which tends to increase L1 cache - effectiveness. - -
- Various pieces of the register allocator (e.g. the coalescer and two-address - operation elimination pass) now know how to rematerialize trivial operations - to avoid copies and include several other optimizations. - -
- The graphs produced by - the llc -view-*-dags options are now significantly prettier and - easier to read. - -
- LLVM 2.4 includes a new register allocator based on Partitioned Boolean - Quadratic Programming (PBQP). This register allocator is still in - development, but is very simple and clean. +
- ...
New features of the X86 target include: +
+ +-
+
+
- ... + +
New target-specific features include: +
New features of the PIC16 target include:
-
-
- Exception handling is supported by default on Linux/x86-64. -
- Position Independent Code (PIC) is now supported on Linux/x86-64. -
- @llvm.frameaddress now supports getting the frame address of stack frames - > 0 on x86/x86-64. -
- MIPS floating point support? [BRUNO] -
- The PowerPC backend now supports trampolines. +
- ...
Things not yet supported:
+ +-
+
- Variable arguments. +
- Interrupts/programs. +
New features of the ARM target include: +
+ +-
+
+
- ... +
New features include: +
New features of other targets include:
-
-
- llvmc2 (the generic compiler driver) gained plugin - support. It is now easier to experiment with llvmc2 and - build your own tools based on it. - -
- LLVM 2.4 includes a number of new generic algorithms and data structures, - include a scoped hash table, 'immutable' data structures, and a - raw_ostream class. The raw_ostream class and - format allow for efficient file output, and various pieces of LLVM - have switched over to use it. The eventual goal is to eliminate - std::ostream in favor of it. - -
- Recycler + pool allocation stuff? [DAN] +
- ...
If you're already an LLVM user or developer with out-of-tree changes based -on LLVM 2.3, this section lists some "gotchas" that you may run into upgrading -from the previous release.
+This release includes a number of new APIs that are used internally, which + may also be useful for external clients. +
-
+
- ... +
In addition, many APIs have changed in this release. Some of the major LLVM -API changes are:
+Other miscellaneous features include:
-
+
- ... +
If you're already an LLVM user or developer with out-of-tree changes based +on LLVM 2.6, this section lists some "gotchas" that you may run into upgrading +from the previous release.
--
+
- The LLVM interpreter now defaults to not using libffi even +if you have it installed. This makes it more likely that an LLVM built on one +system will work when copied to a similar system. To use libffi, +configure with --enable-libffi. + +
In addition, many APIs have changed in this release. Some of the major LLVM +API changes are:
+ +-
+
- ModuleProvider has been removed +and its methods moved to Module and GlobalValue. +Most clients can remove uses of ExistingModuleProvider, +replace getBitcodeModuleProvider with +getLazyBitcodeModule, and pass their Module to +functions that used to accept ModuleProvider. Clients who +wrote their own ModuleProviders will need to derive from +GVMaterializer instead and use +Module::setMaterializer to attach it to a +Module. + +
- GhostLinkage has given up the ghost. +GlobalValues that have not yet been read from their backing +storage have the same linkage they will have after being read in. +Clients must replace calls to +GlobalValue::hasNotBeenReadFromBitcode with +GlobalValue::isMaterializable. + +
- FIXME: Debug info has been totally redone. Add pointers to new APIs. Substantial caveats about compatibility of .ll and .bc files. + +
- The llvm/Support/DataTypes.h header has moved +to llvm/System/DataTypes.h. + +
- The isInteger, isIntOrIntVector, isFloatingPoint, +isFPOrFPVector and isFPOrFPVector methods have been renamed +isIntegerTy, isIntOrIntVectorTy, isFloatingPointTy, +isFPOrFPVectorTy and isFPOrFPVectorTy respectively.
LLVM is known to work on the following platforms:
-
-
- Intel and AMD machines (IA32) running Red Hat Linux, Fedora Core and FreeBSD - (and probably other unix-like systems). -
- PowerPC and X86-based Mac OS X systems, running 10.3 and above in 32-bit and - 64-bit modes. +
- Intel and AMD machines (IA32, X86-64, AMD64, EMT-64) running Red Hat + Linux, Fedora Core, FreeBSD and AuroraUX (and probably other unix-like + systems). +
- PowerPC and X86-based Mac OS X systems, running 10.3 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++). -
- Sun UltraSPARC workstations running Solaris 10. +
- Sun x86 and AMD64 machines running Solaris 10, OpenSolaris 0906.
- Alpha-based machines running Debian GNU/Linux. -
- Itanium-based (IA64) machines running Linux and HP-UX.
The core LLVM infrastructure uses GNU autoconf to adapt itself @@ -524,12 +693,26 @@ 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 This section contains significant known problems with the LLVM system, +listed by component. If you run into a problem, please check the LLVM bug database and submit a bug if there isn't already one.
+-
+
- The llvm-gcc bootstrap will fail with some versions of binutils (e.g. 2.15) + with a message of "Error: can not do 8 + byte pc-relative relocation" when building C++ code. We intend to + fix this on mainline, but a workaround is to upgrade to binutils 2.17 or + later. + +
- LLVM will not correctly compile on Solaris and/or OpenSolaris +using the stock GCC 3.x.x series 'out the box', +See: Broken versions of GCC and other tools. +However, A Modern GCC Build +for x86/x86-64 has been made available from the third party AuroraUX Project +that has been meticulously tested for bootstrapping LLVM & Clang. +
-
-
- The MSIL, IA64, Alpha, SPU, and MIPS backends are experimental. -
- The llc "-filetype=asm" (the default) is the only supported - value for this option. +
- The MSIL, Alpha, SPU, MIPS, PIC16, Blackfin, MSP430 and SystemZ backends are + experimental. +
- The llc "-filetype=asm" (the default) is the only + supported value for this option. The ELF writer is experimental. +
- The implementation of Andersen's Alias Analysis has many known bugs.
-
+
- Support for the Advanced SIMD (Neon) instruction set is still incomplete +and not well tested. Some features may not work at all, and the code quality +may be poor in some cases.
- 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. +
- 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 +
- 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. - +
- 64-bit MIPS targets are not supported yet.
-
-
- The Itanium backend is highly experimental, and has a number of known - issues. We are looking for a maintainer for the Itanium backend. If you - are interested, please contact the llvmdev mailing list. -
llvm-gcc 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 only major language feature of GCC not supported by llvm-gcc is the __builtin_apply family of builtins. However, some extensions are only supported on some targets. For example, trampolines are only @@ -713,11 +894,23 @@ itself, Qt, Mozilla, etc.
- Exception handling works well on the X86 and PowerPC targets. Currently - only linux and darwin targets are supported (both 32 and 64 bit). + only Linux and Darwin targets are supported (both 32 and 64 bit).
-
+
- Fortran support generally works, but there are still several unresolved bugs + in Bugzilla. Please see the + tools/gfortran component for details. +
- The Ada front-end currently only builds on X86-32. This is mainly due -to lack of trampoline support (pointers to nested functions) on other platforms, -however it also fails to build on X86-64 +to lack of trampoline support (pointers to nested functions) on other platforms. +However, it also fails to build on X86-64 which does support trampolines.
- The Ada front-end fails to bootstrap. -Workaround: configure with --disable-bootstrap. +This is due to lack of LLVM support for setjmp/longjmp style +exception handling, which is used internally by the compiler. +Workaround: configure with --disable-bootstrap.
- The c380004, c393010 and cxg2021 ACATS tests fail -(c380004 also fails with gcc-4.2 mainline). -
- Some gcc specific Ada tests continue to crash the compiler. -
- The -E binder option (exception backtraces) +(c380004 also fails with gcc-4.2 mainline). +If the compiler is built with checks disabled then c393010 +causes the compiler to go into an infinite loop, using up all system memory. +
- Some GCC specific Ada tests continue to crash the compiler. +
- The -E binder option (exception backtraces) does not work and will result in programs -crashing if an exception is raised. Workaround: do not use -E. +crashing if an exception is raised. Workaround: do not use -E.
- Only discrete types are allowed to start or finish at a non-byte offset in a record. Workaround: do not pack records or use representation clauses that result in a field of a non-discrete type @@ -754,6 +951,20 @@ ignored.
The Llvm.Linkage module is broken, and has incorrect values. Only +Llvm.Linkage.External, Llvm.Linkage.Available_externally, and +Llvm.Linkage.Link_once will be correct. If you need any of the other linkage +modes, you'll have to write an external C library in order to expose the +functionality. This has been fixed in the trunk.
+
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS">
Last modified: $Date$