LLVM 2.5 Release Notes

1. Introduction
2. Sub-project Status Update
3. What's New in LLVM?
4. Installation Instructions
5. Portability and Supported Platforms
6. Known Problems
7. Additional Information

Written by the LLVM Team

Introduction

This document contains the release notes for the LLVM Compiler Infrastructure, release 2.5. 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 release, please check out the main LLVM web site. If you have questions or comments, the LLVM Developer's Mailing List is a good place to send them.

Note that if you are reading this file from 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 release, please see the releases page.

Sub-project Status Update

The LLVM 2.5 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.

Clang: C/C++/Objective-C Frontend Toolkit

The Clang project is an effort to build a set of new 'LLVM native' front-end technologies for the LLVM optimizer and code generator. While Clang is not included in the LLVM 2.5 release, it is continuing to make major strides forward in all areas. Its C and Objective-C parsing and code generation support is now very solid. For example, it is capable of successfully building many real applications for X86-32 and X86-64, including the FreeBSD kernel. C++ is also making incredible progress, and work on templates has recently started.

While Clang is not yet production quality, it is progressing very nicely and is quite usable for building many C and Objective-C applications. If you are interested in fast compiles and good diagnostics, we encourage you to try it out by building from mainline and reporting any issues you hit to the Clang front-end mailing list.

In the LLVM 2.5 time-frame, the Clang team has made many improvements:

- Clang now has a new driver, which is focused on providing a GCC-compatible interface.
- The X86-64 ABI is now supported.
- Precompiled header support is now implemented.
- Objective-C support is significantly improved beyond LLVM 2.4, supporting many features, such as Objective-C Garbage Collection.
- Many many bugs are fixed.

Clang Static Analyzer

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.

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!

VMKit: JVM/CLI Virtual Machine Implementation

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.

Following LLVM 2.5, VMKit has its first release ? that you can find on its webpage. The release includes bug fixes, cleanup and new features. The major changes are:

- Ahead of Time compiler: compiles .class files to llvm .bc. VMKit uses this functionality to native compile the standard classes (eg java.lang.String). Users can compile AOT .class files into dynamic libraries and run them with the help of VMKit.
- New exception model: the dwarf exception model is very slow for exception-intensive applications, so the JVM has had a new implementation of exceptions which check at each function call if an exception happened. There is a low performance penalty on applications without exceptions, but it is a big gain for exception-intensive applications. For example the jack benchmark in Spec JVM98 is 6x faster (performance gain of 83%).
- New support for OSX/X64, Linux/X64 (with the Boehm GC), Linux/ppc32.

What's New in LLVM?

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.

Major New Features

LLVM 2.5 includes several major new capabilities:

- The code generator now supports arbitrary precision integers. Types like `i33` have long been valid in the LLVM IR, but previously could only be used with the interpreter. Now IR using such types can be compiled to native code on all targets. All operations are supported if the integer is not bigger than twice the target machine word size. Simple operations like loads, stores and shifts by a constant amount are supported for integers of any size.

llvm-gcc 4.2 Improvements

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 Core Improvements

New features include:

- ?

Optimizer Improvements

In addition to a huge array of bug fixes and minor performance tweaks, this release includes a few major enhancements and additions to the optimizers:

- ?

Code Generator Improvements

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 type legalization logic has been completely rewritten, and is now more powerful (it supports arbitrary precision integer types for example) and hopefully more correct. The type legalizer converts operations on types that are not natively supported by the target machine into equivalent code sequences that only use natively supported types. The old type legalizer is still available and will be used if `-disable-legalize-types` is passed to `llc`.
- ?

Target Specific Improvements

New target-specific features include:

- ?

Other Improvements

New features include:

- ?

Major Changes and Removed Features

If you're already an LLVM user or developer with out-of-tree changes based on LLVM 2.4, this section lists some "gotchas" that you may run into upgrading from the previous release.

- ?

In addition, many APIs have changed in this release. Some of the major LLVM API changes are:

- ?

- ?
Portability and Supported Platforms

LLVM is known to work on the following platforms:

- Intel and AMD machines (IA32, X86-64, AMD64, EMT-64) 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 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.
- 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 to the machine and operating system on which it is built. However, minor porting may be required to get LLVM to work on new platforms. We welcome your portability patches and reports of successful builds or error messages.

Known Problems

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.

Experimental features included with this release

The following components of this LLVM release are either untested, known to 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.

- The MSIL, IA64, Alpha, SPU, MIPS, and PIC16 backends are experimental.
- The llc "`-filetype=asm`" (the default) is the only supported value for this option.

Known problems with the X86 back-end

- The X86 backend does not yet support all inline assembly that uses the X86 floating point stack. It supports the 'f' and 't' constraints, but not 'u'.
- The X86 backend generates inefficient floating point code when configured to generate code for systems that don't have SSE2.
- Win64 code generation wasn't widely tested. Everything should work, but we expect small issues to happen. Also, llvm-gcc cannot build mingw64 runtime currently due to several bugs due to lack of support for the 'u' inline assembly constraint and X87 floating point inline assembly.
- The X86-64 backend does not yet support the LLVM IR instruction `va_arg`. Currently, the llvm-gcc front-end supports variadic argument constructs on X86-64 by lowering them manually.

Known problems with the PowerPC back-end

- The Linux PPC32/ABI support needs testing for the interpreter and static compilation, and lacks support for debug information.

Known problems with the ARM back-end

- 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 MIPS back-end

- The O32 ABI is not fully supported.
- 64-bit MIPS targets are not supported yet.

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

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

Known problems with the C back-end

- The C backend has only basic support for inline assembly code.
- 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.
- The C backend does not support all exception handling constructs.
- The C backend does not support arbitrary precision integers.

Known problems with the llvm-gcc C front-end

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 supported on some targets (these are used when you take the address of a nested function).

If you run into GCC extensions which are not supported, please let us know.

Known problems with the llvm-gcc C++ front-end

The C++ front-end is considered to be fully tested and works for a number of non-trivial programs, including LLVM 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).

Known problems with the llvm-gcc Fortran front-end

- Fortran support generally works, but there are still several unresolved bugs in Bugzilla. Please see the tools/gfortran component for details.
- The Fortran front-end currently does not build on Darwin (without tweaks) due to unresolved dependencies on the C front-end.

Known problems with the llvm-gcc Ada front-end
The llvm-gcc 4.2 Ada compiler works fairly well, however this is not a mature technology and problems should be expected.

- 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 which does support trampolines.
- The Ada front-end fails to 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). 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.
- 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 starting or finishing in the middle of a byte.
- The `lli` interpreter considers 'main' as generated by the Ada binder to be invalid. Workaround: hand edit the file to use pointers for `argv` and `envp` rather than integers.
- The `-fstack-check` option is ignored.

Additional Information

A wide variety of additional information is available on the 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.

If you have any questions or comments about LLVM, please feel free to contact us via the mailing lists.