X-Git-Url: http://plrg.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FReleaseNotes.html;h=cddf5882f1a6684db266e0e8810ac54633404ba1;hb=c352caf168094c83f05a8010ca14c2e643dbf618;hp=cef80a48bcb0739b040559bc26802d2881dd8d21;hpb=06c6d9aeb047004bedc2bc2f8bf83214577ef17b;p=oota-llvm.git diff --git a/docs/ReleaseNotes.html b/docs/ReleaseNotes.html index cef80a48bcb..cddf5882f1a 100644 --- a/docs/ReleaseNotes.html +++ b/docs/ReleaseNotes.html @@ -4,11 +4,11 @@ - LLVM 2.9 Release Notes + LLVM 3.0 Release Notes -

LLVM 2.9 Release Notes

+

LLVM 3.0 Release Notes

LLVM Dragon Logo @@ -16,8 +16,8 @@
  1. Introduction
  2. Sub-project Status Update
  3. -
  4. External Projects Using LLVM 2.9
  5. -
  6. What's New in LLVM 2.9?
  7. +
  8. External Projects Using LLVM 3.0
  9. +
  10. What's New in LLVM 3.0?
  11. Installation Instructions
  12. Known Problems
  13. Additional Information
  14. @@ -28,10 +28,10 @@ @@ -41,24 +41,24 @@ Release Notes. -
    +

    This document contains the release notes for the LLVM Compiler -Infrastructure, release 2.9. 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.

    + Infrastructure, release 3.0. 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.

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

    +

    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.

    @@ -77,46 +77,63 @@ current one. To see the release notes for a specific release, please see the -
    -

    -The LLVM 2.9 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 LLVM 3.0 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.

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

    -
    +

    Clang is an LLVM front end for the C, -C++, and Objective-C languages. Clang aims to provide a better user experience -through expressive diagnostics, a high level of conformance to language -standards, fast compilation, and low memory use. Like LLVM, Clang provides a -modular, library-based architecture that makes it suitable for creating or -integrating with other development tools. Clang is considered a -production-quality compiler for C, Objective-C, C++ and Objective-C++ on x86 -(32- and 64-bit), and for darwin/arm targets.

    - -

    In the LLVM 2.9 time-frame, the Clang team has made many improvements in C, -C++ and Objective-C support. C++ support is now generally rock solid, has -been exercised on a broad variety of code, and has several new C++'0x features -implemented (such as rvalue references and variadic templates). LLVM 2.9 has -also brought in a large range of bug fixes and minor features (e.g. __label__ -support), and is much more compatible with the Linux Kernel.

    + C++, and Objective-C languages. Clang aims to provide a better user + experience through expressive diagnostics, a high level of conformance to + language standards, fast compilation, and low memory use. Like LLVM, Clang + provides a modular, library-based architecture that makes it suitable for + creating or integrating with other development tools. Clang is considered a + production-quality compiler for C, Objective-C, C++ and Objective-C++ on x86 + (32- and 64-bit), and for darwin/arm targets.

    + +

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

    + +
      +
    • Greatly improved support for building C++ applications, with greater + stability and better diagnostics.
    • + +
    • Improved support for + the C++ + 2011 standard, including implementations of non-static data member + initializers, alias templates, delegating constructors, the range-based + for loop, and implicitly-generated move constructors and move assignment + operators, among others.
    • + +
    • Implemented support for some features of the upcoming C1x standard, + including static assertions and generic selections.
    • + +
    • Better detection of include and linking paths for system headers and + libraries, especially for Linux distributions.
    • + +
    • Implemented support + for Automatic + Reference Counting for Objective-C.
    • + +
    • Implemented a number of optimizations in libclang, the Clang C + interface, to improve the performance of code completion and the mapping + from source locations to abstract syntax tree nodes.
    • +
    +

    If Clang rejects your code but another compiler accepts it, please take a -look at the language -compatibility guide to make sure this is not intentional or a known issue. -

    + look at the language + compatibility guide to make sure this is not intentional or a known + issue.

    @@ -125,29 +142,22 @@ compatibility guide to make sure this is not intentional or a known issue. DragonEgg: GCC front-ends, LLVM back-end -
    -

    -DragonEgg is a -gcc plugin that replaces GCC's -optimizers and code generators with LLVM's. -Currently it requires a patched version of gcc-4.5. -The plugin can target the x86-32 and x86-64 processor families and has been -used successfully on the Darwin, FreeBSD and Linux platforms. -The Ada, C, C++ and Fortran languages work well. -The plugin is capable of compiling plenty of Obj-C, Obj-C++ and Java but it is -not known whether the compiled code actually works or not! -

    +
    +

    DragonEgg is a + gcc plugin that replaces GCC's + optimizers and code generators with LLVM's. Currently it requires a patched + version of gcc-4.5. The plugin can target the x86-32 and x86-64 processor + families and has been used successfully on the Darwin, FreeBSD and Linux + platforms. The Ada, C, C++ and Fortran languages work well. The plugin is + capable of compiling plenty of Obj-C, Obj-C++ and Java but it is not known + whether the compiled code actually works or not!

    + +

    The 3.0 release has the following notable changes:

    -

    -The 2.9 release has the following notable changes:

      -
    • The plugin is much more stable when compiling Fortran.
    • -
    • Inline assembly where an asm output is tied to an input of a different size -is now supported in many more cases.
    • -
    • Basic support for the __float128 type was added. It is now possible to -generate LLVM IR from programs using __float128 but code generation does not -work yet.
    • -
    • Compiling Java programs no longer systematically crashes the plugin.
    • +
    @@ -157,24 +167,18 @@ work yet. compiler-rt: Compiler Runtime Library -
    -

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

    +
    + +

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

    -

    In the LLVM 2.9 timeframe, compiler_rt has had several minor changes for - better ARM support, and a fairly major license change. All of the code in the - compiler-rt project is now dual - licensed under MIT and UIUC license, which allows you to use compiler-rt - in applications without the binary copyright reproduction clause. If you - prefer the LLVM/UIUC license, you are free to continue using it under that - license as well.

    +

    In the LLVM 3.0 timeframe,

    @@ -183,20 +187,13 @@ libgcc routines).

    LLDB: Low Level Debugger -
    -

    -LLDB is a brand new member of the LLVM -umbrella of projects. LLDB is a next generation, high-performance debugger. It -is built as a set of reusable components which highly leverage existing -libraries in the larger LLVM Project, such as the Clang expression parser, the -LLVM disassembler and the LLVM JIT.

    +
    -

    -LLDB is has advanced by leaps and bounds in the 2.9 timeframe. It is -dramatically more stable and useful, and includes both a new tutorial and a side-by-side comparison with -GDB.

    +

    LLDB has advanced by leaps and bounds in the 3.0 timeframe. It is + dramatically more stable and useful, and includes both a + new tutorial and + a side-by-side comparison with + GDB.

    @@ -205,22 +202,11 @@ GDB.

    libc++: C++ Standard Library -
    -

    -libc++ is another new member of the LLVM -family. It is an implementation of the C++ standard library, written from the -ground up to specifically target the forthcoming C++'0X standard and focus on -delivering great performance.

    +
    -

    -In the LLVM 2.9 timeframe, libc++ has had numerous bugs fixed, and is now being -co-developed with Clang's C++'0x mode.

    - -

    -Like compiler_rt, libc++ is now dual - licensed under the MIT and UIUC license, allowing it to be used more - permissively. -

    +

    Like compiler_rt, libc++ is now dual + licensed under the MIT and UIUC license, allowing it to be used more + permissively.

    @@ -230,14 +216,15 @@ Like compiler_rt, libc++ is now dual LLBrowse: IR Browser -
    -

    - - LLBrowse is an interactive viewer for LLVM modules. It can load any LLVM - module and displays its contents as an expandable tree view, facilitating an - easy way to inspect types, functions, global variables, or metadata nodes. It - is fully cross-platform, being based on the popular wxWidgets GUI toolkit. -

    +
    + +

    + LLBrowse is an interactive viewer for LLVM modules. It can load any LLVM + module and displays its contents as an expandable tree view, facilitating an + easy way to inspect types, functions, global variables, or metadata nodes. It + is fully cross-platform, being based on the popular wxWidgets GUI + toolkit.

    +
    @@ -245,14 +232,15 @@ Like compiler_rt, libc++ is now dual VMKit -
    +
    +

    The VMKit project is an implementation - of a Java Virtual Machine (Java VM or JVM) that uses LLVM for static and - just-in-time compilation. As of LLVM 2.9, VMKit now supports generational - garbage collectors. The garbage collectors are provided by the MMTk framework, - and VMKit can be configured to use one of the numerous implemented collectors - of MMTk. -

    + of a Java Virtual Machine (Java VM or JVM) that uses LLVM for static and + just-in-time compilation. As of LLVM 3.0, VMKit now supports generational + garbage collectors. The garbage collectors are provided by the MMTk + framework, and VMKit can be configured to use one of the numerous implemented + collectors of MMTk.

    +
    @@ -262,7 +250,7 @@ Like compiler_rt, libc++ is now dual KLEE: A Symbolic Execution Virtual Machine -
    +

    KLEE is a symbolic execution framework for programs in LLVM bitcode form. KLEE tries to symbolically evaluate "all" paths @@ -274,88 +262,390 @@ be used to verify some algorithms.

    UPDATE!

    --> +

    - External Open Source Projects Using LLVM 2.9 + External Open Source Projects Using LLVM 3.0

    -
    +

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

    + projects that have already been updated to work with LLVM 3.0.

    + + +

    AddressSanitizer

    + +
    + +

    AddressSanitizer + uses compiler instrumentation and a specialized malloc library to find C/C++ + bugs such as use-after-free and out-of-bound accesses to heap, stack, and + globals. The key feature of the tool is speed: the average slowdown + introduced by AddressSanitizer is less than 2x.

    +
    + +

    ClamAV

    + +
    + +

    Clam AntiVirus is an open source (GPL) + anti-virus toolkit for UNIX, designed especially for e-mail scanning on mail + gateways.

    + +

    Since version 0.96 it + has bytecode + signatures that allow writing detections for complex malware.

    + +

    It uses LLVM's JIT to speed up the execution of bytecode on X86, X86-64, + PPC32/64, falling back to its own interpreter otherwise. The git version was + updated to work with LLVM 3.0.

    + +
    + + +

    clReflect

    + +
    + +

    clReflect is a C++ + parser that uses clang/LLVM to derive a light-weight reflection database + suitable for use in game development. It comes with a very simple runtime + library for loading and querying the database, requiring no external + dependencies (including CRT), and an additional utility library for object + management and serialisation.

    + +
    + + +

    Cling C++ Interpreter

    + +
    + +

    Cling is an interactive compiler interface + (aka C++ interpreter). It uses LLVM's JIT and clang; it currently supports + C++ and C. It has a prompt interface, runs source files, calls into shared + libraries, prints the value of expressions, even does runtime lookup of + identifiers (dynamic scopes). And it just behaves like one would expect from + an interpreter.

    + +

    Crack Programming Language

    -
    -

    -Crack aims to provide the -ease of development of a scripting language with the performance of a compiled -language. The language derives concepts from C++, Java and Python, incorporating -object-oriented programming, operator overloading and strong typing.

    +
    + +

    Crack aims to provide + the ease of development of a scripting language with the performance of a + compiled language. The language derives concepts from C++, Java and Python, + incorporating object-oriented programming, operator overloading and strong + typing.

    +
    + +

    Eero

    + +
    + +

    Eero is a fully + header-and-binary-compatible dialect of Objective-C 2.0, implemented with a + patched version of the Clang/LLVM compiler. It features a streamlined syntax, + Python-like indentation, and new operators, for improved readability and + reduced code clutter. It also has new features such as limited forms of + operator overloading and namespaces, and strict (type-and-operator-safe) + enumerations. It is inspired by languages such as Smalltalk, Python, and + Ruby.

    + +
    + + +

    Glasgow Haskell Compiler (GHC)

    +
    + +

    GHC is an open source, state-of-the-art programming suite for Haskell, a + standard lazy functional programming language. It includes an optimizing + static compiler generating good code for a variety of platforms, together + with an interactive system for convenient, quick development.

    + +

    GHC 7.0 and onwards include an LLVM code generator, supporting LLVM 2.8 and + later. Since LLVM 2.9, GHC now includes experimental support for the ARM + platform with LLVM 3.0.

    + +
    + + +

    gwXscript

    + +
    + +

    gwXscript is an object oriented, + aspect oriented programming language which can create both executables (ELF, + EXE) and shared libraries (DLL, SO, DYNLIB). The compiler is implemented in + its own language and translates scripts into LLVM-IR which can be optimized + and translated into native code by the LLVM framework. Source code in + gwScript contains definitions that expand the namespaces. So you can build + your project and simply 'plug out' features by removing a file. The remaining + project does not leave scars since you directly separate concerns by the + 'template' feature of gwX. It is also possible to add new features to a + project by just adding files and without editing the original project. This + language is used for example to create games or content management systems + that should be extendable.

    + +

    gwXscript is strongly typed and offers comfort with its native types string, + hash and array. You can easily write new libraries in gwXscript or native + code. gwXscript is type safe and users should not be able to crash your + program or execute malicious code except code that is eating CPU time.

    + +
    + + +

    include-what-you-use

    + +
    + +

    include-what-you-use + is a tool to ensure that a file directly #includes + all .h files that provide a symbol that the file uses. It also + removes superfluous #includes from source files.

    + +
    + + +

    ispc: The Intel SPMD Program Compiler

    + +
    + +

    ispc is a compiler for "single program, + multiple data" (SPMD) programs. It compiles a C-based SPMD programming + language to run on the SIMD units of CPUs; it often delivers 5-6x speedups on + a single core of a CPU with an 8-wide SIMD unit compared to serial code, + while still providing a clean and easy-to-understand programming model. For + an introduction to the language and its performance, + see the walkthrough of a short + example program. ispc is licensed under the BSD license.

    + +
    + + +

    LanguageKit and Pragmatic Smalltalk

    + +
    + +

    LanguageKit is + a framework for implementing dynamic languages sharing an object model with + Objective-C. It provides static and JIT compilation using LLVM along with + its own interpreter. Pragmatic Smalltalk is a dialect of Smalltalk, built on + top of LanguageKit, that interfaces directly with Objective-C, sharing the + same object representation and message sending behaviour. These projects are + developed as part of the Étoié desktop environment.

    + +
    + + +

    LuaAV

    + +
    + +

    LuaAV is a real-time + audiovisual scripting environment based around the Lua language and a + collection of libraries for sound, graphics, and other media protocols. LuaAV + uses LLVM and Clang to JIT compile efficient user-defined audio synthesis + routines specified in a declarative syntax.

    + +
    + -

    TTA-based Codesign Environment (TCE)

    +

    Mono

    + +
    + +

    An open source, cross-platform implementation of C# and the CLR that is + binary compatible with Microsoft.NET. Has an optional, dynamically-loaded + LLVM code generation backend in Mini, the JIT compiler.

    + +

    Note that we use a Git mirror of LLVM with some patches. See: + https://github.com/mono/llvm

    + +
    + + +

    Portable OpenCL (pocl)

    + +
    + +

    Portable OpenCL is an open source implementation of the OpenCL standard which + can be easily adapted for new targets. One of the goals of the project is + improving performance portability of OpenCL programs, avoiding the need for + target-dependent manual optimizations. A "native" target is included, which + allows running OpenCL kernels on the host (CPU).

    + +
    + + +

    Pure

    -
    +
    +

    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. The interpreter uses LLVM as a backend to JIT-compile Pure + programs to fast native code. 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 interface to C and other programming + languages (including the ability to load LLVM bitcode modules, and inline C, + C++, Fortran and Faust code in Pure programs if the corresponding LLVM-enabled + compilers are installed).

    + +

    Pure version 0.48 has been tested and is known to work with LLVM 3.0 + (and continues to work with older LLVM releases >= 2.5).

    + +
    + + +

    Renderscript

    + +
    + +

    Renderscript + is Android's advanced 3D graphics rendering and compute API. It provides a + portable C99-based language with extensions to facilitate common use cases + for enhancing graphics and thread level parallelism. The Renderscript + compiler frontend is based on Clang/LLVM. It emits a portable bitcode format + for the actual compiled script code, as well as reflects a Java interface for + developers to control the execution of the compiled bitcode. Executable + machine code is then generated from this bitcode by an LLVM backend on the + device. Renderscript is thus able to provide a mechanism by which Android + developers can improve performance of their applications while retaining + portability.

    + +
    + + +

    SAFECode

    + +
    + +

    SAFECode is a memory safe C/C++ + compiler built using LLVM. It takes standard, unannotated C/C++ code, + analyzes the code to ensure that memory accesses and array indexing + operations are safe, and instruments the code with run-time checks when + safety cannot be proven statically. SAFECode can be used as a debugging aid + (like Valgrind) to find and repair memory safety bugs. It can also be used + to protect code from security attacks at run-time.

    + +
    + + +

    The Stupid D Compiler (SDC)

    + +
    + +

    The Stupid D Compiler is a + project seeking to write a self-hosting compiler for the D programming + language without using the frontend of the reference compiler (DMD).

    + +
    + + +

    TTA-based Co-design Environment (TCE)

    + +
    +

    TCE is a toolset for designing application-specific processors (ASP) based on -the Transport triggered architecture (TTA). The toolset provides a complete -co-design flow from C/C++ programs down to synthesizable VHDL and parallel -program binaries. Processor customization points include the register files, -function units, supported operations, and the interconnection network.

    + the Transport triggered architecture (TTA). The toolset provides a complete + co-design flow from C/C++ programs down to synthesizable VHDL and parallel + program binaries. Processor customization points include the register files, + function units, supported operations, and the interconnection network.

    TCE uses Clang and LLVM for C/C++ language support, target independent -optimizations and also for parts of code generation. It generates new LLVM-based -code generators "on the fly" for the designed TTA processors and loads them in -to the compiler backend as runtime libraries to avoid per-target recompilation -of larger parts of the compiler chain.

    + optimizations and also for parts of code generation. It generates new + LLVM-based code generators "on the fly" for the designed TTA processors and + loads them in to the compiler backend as runtime libraries to avoid + per-target recompilation of larger parts of the compiler chain.

    +
    + + +

    Tart Programming Language

    + +
    + +

    Tart is a general-purpose, + strongly typed programming language designed for application + developers. Strongly inspired by Python and C#, Tart focuses on practical + solutions for the professional software developer, while avoiding the clutter + and boilerplate of legacy languages like Java and C++. Although Tart is still + in development, the current implementation supports many features expected of + a modern programming language, such as garbage collection, powerful + bidirectional type inference, a greatly simplified syntax for template + metaprogramming, closures and function literals, reflection, operator + overloading, explicit mutability and immutability, and much more. Tart is + flexible enough to accommodate a broad range of programming styles and + philosophies, while maintaining a strong commitment to simplicity, minimalism + and elegance in design.

    +
    + + +

    ThreadSanitizer

    + +
    + +

    ThreadSanitizer is a + data race detector for (mostly) C and C++ code, available for Linux, Mac OS + and Windows. On different systems, we use binary instrumentation frameworks + (Valgrind and Pin) as frontends that generate the program events for the race + detection algorithm. On Linux, there's an option of using LLVM-based + compile-time instrumentation.

    + +
    - +

    The ZooLib C++ Cross-Platform Application Framework

    + +
    + +

    ZooLib is Open Source under the MIT + License. It provides GUI, filesystem access, TCP networking, thread-safe + memory management, threading and locking for Mac OS X, Classic Mac OS, + Microsoft Windows, POSIX operating systems with X11, BeOS, Haiku, Apple's iOS + and Research in Motion's BlackBerry.

    + +

    My current work is to use CLang's static analyzer to improve ZooLib's code + quality. I also plan to set up LLVM compiles of the demo programs and test + programs using CLang and LLVM on all the platforms that CLang, LLVM and + ZooLib all support.

    + +
    + + + - -

    Pure

    - -
    -

    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. The interpreter uses LLVM as a backend to JIT-compile Pure - programs to fast native code. 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 interface to C and other - programming languages (including the ability to load LLVM bitcode - modules, and inline C, C++, Fortran and Faust code in Pure programs if - the corresponding LLVM-enabled compilers are installed).

    - -

    Pure version 0.47 has been tested and is known to work with LLVM 2.9 - (and continues to work with older LLVM releases >= 2.5).

    -
    + -

    Glasgow Haskell Compiler (GHC)

    - -
    -

    GHC is an open source, state-of-the-art programming suite for Haskell, -a standard lazy functional programming language. It includes an -optimizing static compiler generating good code for a variety of -platforms, together with an interactive system for convenient, quick -development.

    - -

    In addition to the existing C and native code generators, GHC 7.0 now -supports an LLVM code generator. GHC supports LLVM 2.7 and later.

    -
    - - + + + +
    +

    - What's New in LLVM 2.9? + What's New in LLVM 3.0?

    -
    +

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

    - -
    + minor improvements. Some of the major improvements and new features are + listed in this section.

    Major New Features

    -
    +
    -

    LLVM 2.9 includes several major new capabilities:

    +

    LLVM 3.0 includes several major new capabilities:

      - -
    • Type Based Alias Analysis (TBAA) is now implemented and turned on by default - in Clang. This allows substantially better load/store optimization in some - cases. TBAA can be disabled by passing -fno-strict-aliasing. -
    • - -
    • This release has seen a continued focus on quality of debug information. - LLVM now generates much higher fidelity debug information, particularly when - debugging optimized code.
    • - -
    • Inline assembly now supports multiple alternative constraints.
    • -
    • A new backend for the NVIDIA PTX virtual ISA (used to target its GPUs) is - under rapid development. It is not generally useful in 2.9, but is making - rapid progress.
    • +
    @@ -478,26 +748,145 @@ in this section. LLVM IR and Core Improvements -
    +
    +

    LLVM IR has several new features for better support of new targets and that -expose new optimization opportunities:

    + expose new optimization opportunities:

    + +

    One of the biggest changes is that 3.0 has a new exception handling + system. The old system used LLVM intrinsics to convey the exception handling + information to the code generator. It worked in most cases, but not + all. Inlining was especially difficult to get right. Also, the intrinsics + could be moved away from the invoke instruction, making it hard + to recover that information.

    + +

    The new EH system makes exception handling a first-class member of the IR. It + adds two new instructions:

      -
    • The udiv, ashr, lshr, and shl - instructions now have support exact and nuw/nsw bits to indicate that they - don't overflow or shift out bits. This is useful for optimization of pointer differences and other cases.
    • - -
    • LLVM IR now supports the unnamed_addr - attribute to indicate that constant global variables with identical - initializers can be merged. This fixed an - issue where LLVM would incorrectly merge two globals which were supposed - to have distinct addresses.
    • - -
    • The new hotpatch attribute has been added - to allow runtime patching of functions.
    • +
    • landingpad — + this instruction defines a landing pad basic block. It contains all of the + information that's needed by the code generator. It's also required to be + the first non-PHI instruction in the landing pad. In addition, a landing + pad may be jumped to only by the unwind edge of an invoke + instruction.
    • + +
    • resume — this + instruction causes the current exception to resume traveling up the + stack. It replaces the @llvm.eh.resume intrinsic.
    +

    Converting from the old EH API to the new EH API is rather simple, because a + lot of complexity has been removed. The two intrinsics, + @llvm.eh.exception and @llvm.eh.selector have been + superceded by the landingpad instruction. Instead of generating + a call to @llvm.eh.exception and @llvm.eh.selector: + +

    +
    +Function *ExcIntr = Intrinsic::getDeclaration(TheModule,
    +                                              Intrinsic::eh_exception);
    +Function *SlctrIntr = Intrinsic::getDeclaration(TheModule,
    +                                                Intrinsic::eh_selector);
    +
    +// The exception pointer.
    +Value *ExnPtr = Builder.CreateCall(ExcIntr, "exc_ptr");
    +
    +std::vector<Value*> Args;
    +Args.push_back(ExnPtr);
    +Args.push_back(Builder.CreateBitCast(Personality,
    +                                     Type::getInt8PtrTy(Context)));
    +
    +// Add selector clauses to Args.
    +
    +// The selector call.
    +Builder.CreateCall(SlctrIntr, Args, "exc_sel");
    +
    +
    + +

    You should instead generate a landingpad instruction, that + returns an exception object and selector value:

    + +
    +
    +LandingPadInst *LPadInst =
    +  Builder.CreateLandingPad(StructType::get(Int8PtrTy, Int32Ty, NULL),
    +                           Personality, 0);
    +
    +Value *LPadExn = Builder.CreateExtractValue(LPadInst, 0);
    +Builder.CreateStore(LPadExn, getExceptionSlot());
    +
    +Value *LPadSel = Builder.CreateExtractValue(LPadInst, 1);
    +Builder.CreateStore(LPadSel, getEHSelectorSlot());
    +
    +
    + +

    It's now trivial to add the individual clauses to the landingpad + instruction.

    + +
    +
    +// Adding a catch clause
    +Constant *TypeInfo = getTypeInfo();
    +LPadInst->addClause(TypeInfo);
    +
    +// Adding a C++ catch-all
    +LPadInst->addClause(Constant::getNullValue(Builder.getInt8PtrTy()));
    +
    +// Adding a cleanup
    +LPadInst->setCleanup(true);
    +
    +// Adding a filter clause
    +std::vector<Constant*> TypeInfos;
    +Constant *TypeInfo = getFilterTypeInfo();
    +TypeInfos.push_back(Builder.CreateBitCast(TypeInfo, Builder.getInt8PtrTy()));
    +
    +ArrayType *FilterTy = ArrayType::get(Int8PtrTy, TypeInfos.size());
    +LPadInst->addClause(ConstantArray::get(FilterTy, TypeInfos));
    +
    +
    + +

    Converting from using the @llvm.eh.resume intrinsic to + the resume instruction is trivial. It takes the exception + pointer and exception selector values returned by + the landingpad instruction:

    + +
    +
    +Type *UnwindDataTy = StructType::get(Builder.getInt8PtrTy(),
    +                                     Builder.getInt32Ty(), NULL);
    +Value *UnwindData = UndefValue::get(UnwindDataTy);
    +Value *ExcPtr = Builder.CreateLoad(getExceptionObjSlot());
    +Value *ExcSel = Builder.CreateLoad(getExceptionSelSlot());
    +UnwindData = Builder.CreateInsertValue(UnwindData, ExcPtr, 0, "exc_ptr");
    +UnwindData = Builder.CreateInsertValue(UnwindData, ExcSel, 1, "exc_sel");
    +Builder.CreateResume(UnwindData);
    +
    +
    + +
    + + +

    +Loop Optimization Improvements +

    + +
    +

    The induction variable simplification pass in 3.0 only modifies + induction variables when profitable. Sign and zero extension + elimination, linear function test replacement, loop unrolling, and + other simplifications that require induction variable analysis have + been generalized so they no longer require loops to be rewritten in a + typically suboptimal form prior to optimization. This new design + preserves more IR level information, avoids undoing earlier loop + optimizations (particularly hand-optimized loops), and no longer + strongly depends on the code generator rewriting loops a second time + in a now optimal form--an intractable problem.

    + +

    The original behavior can be restored with -mllvm -enable-iv-rewrite; + however, support for this mode will be short lived. As such, bug + reports should be filed for any significant performance regressions + when moving from -mllvm -enable-iv-rewrite to the 3.0 default mode.

    @@ -505,63 +894,16 @@ expose new optimization opportunities:

    Optimizer Improvements -
    +

    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:

    + release includes a few major enhancements and additions to the + optimizers:

      -
    • Link Time Optimization (LTO) has been improved to use MC for parsing inline - assembly and now can build large programs like Firefox 4 on both Mac OS X and - Linux.
    • - -
    • The new -loop-idiom pass recognizes memset/memcpy loops (and memset_pattern - on darwin), turning them into library calls, which are typically better - optimized than inline code. If you are building a libc and notice that your - memcpy and memset functions are compiled into infinite recursion, please build - with -ffreestanding or -fno-builtin to disable this pass.
    • - -
    • A new -early-cse pass does a fast pass over functions to fold constants, - simplify expressions, perform simple dead store elimination, and perform - common subexpression elimination. It does a good job at catching some of the - trivial redundancies that exist in unoptimized code, making later passes more - effective.
    • - -
    • A new -loop-instsimplify pass is used to clean up loop bodies in the loop - optimizer.
    • - -
    • The new TargetLibraryInfo interface allows mid-level optimizations to know - whether the current target's runtime library has certain functions. For - example, the optimizer can now transform integer-only printf calls to call - iprintf, allowing reduced code size for embedded C libraries (e.g. newlib). -
    • - -
    • LLVM has a new RegionPass - infrastructure for region-based optimizations.
    • - -
    • Several optimizer passes have been substantially sped up: - GVN is much faster on functions with deep dominator trees and lots of basic - blocks. The dominator tree and dominance frontier passes are much faster to - compute, and preserved by more passes (so they are computed less often). The - -scalar-repl pass is also much faster and doesn't use DominanceFrontier. -
    • - -
    • The Dead Store Elimination pass is more aggressive optimizing stores of - different types: e.g. a large store following a small one to the same address. - The MemCpyOptimizer pass handles several new forms of memcpy elimination.
    • - -
    • LLVM now optimizes various idioms for overflow detection into check of the - flag register on various CPUs. For example, we now compile: - -
      -   unsigned long t = a+b;
      -   if (t < a) ...
      -  
      - into: -
      -   addq %rdi, %rbx
      -   jno  LBB0_2
      -  
      +
    @@ -573,52 +915,22 @@ release includes a few major enhancements and additions to the optimizers:

    MC Level Improvements -
    -

    -The LLVM Machine Code (aka MC) subsystem was created to solve a number -of problems in the realm of assembly, disassembly, object file format handling, -and a number of other related areas that CPU instruction-set level tools work -in.

    +
    -
      -
    • ELF MC support has matured enough for the integrated assembler to be turned - on by default in Clang on X86-32 and X86-64 ELF systems.
    • - -
    • MC supports and CodeGen uses the .file and .loc directives - for producing line number debug info. This produces more compact line - tables and easier to read .s files.
    • - -
    • MC supports the .cfi_* directives for producing DWARF - frame information, but it is still not used by CodeGen by default.
    • - - -
    • The MC assembler now generates much better diagnostics for common errors, - is much faster at matching instructions, is much more bug-compatible with - the GAS assembler, and is now generally useful for a broad range of X86 - assembly.
    • - -
    • We now have some basic internals - documentation for MC.
    • - -
    • .td files can now specify assembler aliases directly with the MnemonicAlias and InstAlias - tblgen classes.
    • - -
    • LLVM now has an experimental format-independent object file manipulation - library (lib/Object). It supports both PE/COFF and ELF. The llvm-nm tool has - been extended to work with native object files, and the new llvm-objdump tool - supports disassembly of object files (but no relocations are displayed yet). -
    • - -
    • Win32 PE-COFF support in the MC assembler has made a lot of progress in the - 2.9 timeframe, but is still not generally useful.
    • +

      The LLVM Machine Code (aka MC) subsystem was created to solve a number of + problems in the realm of assembly, disassembly, object file format handling, + and a number of other related areas that CPU instruction-set level tools work + in.

      +
        +
      -

      For more information, please see the Intro to the -LLVM MC Project Blog Post. -

      +

      For more information, please see + the Intro + to the LLVM MC Project Blog Post.

    @@ -627,41 +939,16 @@ LLVM MC Project Blog Post. Target Independent 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:

    + infrastructure, which allows us to implement more aggressive algorithms and + make it run faster:

      -
    • The pre-register-allocation (preRA) instruction scheduler models register - pressure much more accurately in some cases. This allows the adoption of more - aggressive scheduling heuristics without causing spills to be generated. -
    • - -
    • LiveDebugVariables is a new pass that keeps track of debugging information - for user variables that are promoted to registers in optimized builds.
    • - -
    • The scheduler now models operand latency and pipeline forwarding.
    • - -
    • A major register allocator infrastructure rewrite is underway. It is not on - by default for 2.9 and you are not advised to use it, but it has made - substantial progress in the 2.9 timeframe: -
        -
      • A new -regalloc=basic "basic" register allocator can be used as a simple - fallback when debugging. It uses the new infrastructure.
      • -
      • New infrastructure is in place for live range splitting. "SplitKit" can - break a live interval into smaller pieces while preserving SSA form, and - SpillPlacement can help find the best split points. This is a work in - progress so the API is changing quickly.
      • -
      • The inline spiller has learned to clean up after live range splitting. It - can hoist spills out of loops, and it can eliminate redundant spills.
      • -
      • Rematerialization works with live range splitting.
      • -
      • The new "greedy" register allocator using live range splitting. This will - be the default register allocator in the next LLVM release, but it is not - turned on by default in 2.9.
      • -
      -
    • +
    @@ -670,36 +957,18 @@ it run faster:

    X86-32 and X86-64 Target Improvements -
    -

    New features and major changes in the X86 target include: -

    +
    + +

    New features and major changes in the X86 target include:

      -
    • LLVM 2.9 includes a complete reimplementation of the MMX instruction set. - The reimplementation uses a new LLVM IR x86_mmx type to ensure that MMX operations - are only generated from source that uses MMX builtin operations. With - this, random types like <2 x i32> are not turned into MMX operations - (which can be catastrophic without proper "emms" insertion). Because the X86 - code generator always generates reliable code, the -disable-mmx flag is now - removed. -
    • - -
    • X86 support for FS/GS relative loads and stores using address space 256/257 works reliably - now.
    • - -
    • LLVM 2.9 generates much better code in several cases by using adc/sbb to - avoid generation of conditional move instructions for conditional increment - and other idioms.
    • -
    • The X86 backend has adopted a new preRA scheduling mode, "list-ilp", to - shorten the height of instruction schedules without inducing register spills. -
    • +
    • The CRC32 intrinsics have been renamed. The intrinsics were previously + @llvm.x86.sse42.crc32.[8|16|32] + and @llvm.x86.sse42.crc64.[8|64]. They have been renamed to + @llvm.x86.sse42.crc32.32.[8|16|32] and + @llvm.x86.sse42.crc32.64.[8|64].
    • -
    • The MC assembler supports 3dNow! and 3DNowA instructions.
    • - -
    • Several bugs have been fixed for Windows x64 code generator.
    @@ -709,22 +978,14 @@ it run faster:

    ARM Target Improvements -
    -

    New features of the ARM target include: -

    +
    -
      -
    • The ARM backend now has a fast instruction selector, which dramatically - improves -O0 compile times.
    • -
    • The ARM backend has new tuning for Cortex-A8 and Cortex-A9 CPUs.
    • -
    • The __builtin_prefetch builtin (and llvm.prefetch intrinsic) is compiled - into prefetch instructions instead of being discarded.
    • - -
    • The ARM backend preRA scheduler now models machine resources at cycle - granularity. This allows the scheduler to both accurately model - instruction latency and avoid overcommitting functional units.
    • +

      New features of the ARM target include:

      -
    • Countless ARM microoptimizations have landed in LLVM 2.9.
    • +
        +
    @@ -733,24 +994,17 @@ it run faster:

    Other Target Specific Improvements -
    -
      -
    • MicroBlaze: major updates for aggressive delay slot filler, MC-based - assembly printing, assembly instruction parsing, ELF .o file emission, and MC - instruction disassembler have landed.
    • - -
    • SPARC: Many improvements, including using the Y registers for - multiplications and addition of a simple delay slot filler.
    • - -
    • PowerPC: The backend has been largely MC'ized and is ready to support - directly writing out mach-o object files. No one seems interested in finishing - this final step though.
    • +

      PPC32/ELF va_arg was implemented.

      +

      PPC32 initial support for .o file writing was implemented.

      -
    • Mips: Improved o32 ABI support, including better varags handling. -More instructions supported in codegen: madd, msub, rotr, rotrv and clo. -It also now supports lowering block addresses.
    • +
      +
        +
      +
      @@ -758,61 +1012,153 @@ It also now supports lowering block addresses. Major Changes and Removed Features -
      +
      -

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

      +

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

        -
      • This is the last release to support the llvm-gcc frontend.
      • - -
      • LLVM has a new naming - convention standard, though the codebase hasn't fully adopted it yet.
      • - -
      • The new DIBuilder class provides a simpler interface for front ends to - encode debug info in LLVM IR, and has replaced DIFactory.
      • - -
      • LLVM IR and other tools always work on normalized target triples (which have - been run through Triple::normalize).
      • +
      • The LLVMC front end code was removed while separating + out language independence.
      • +
      • The LowerSetJmp pass wasn't used effectively by any + target and has been removed.
      • +
      • The old TailDup pass was not used in the standard pipeline + and was unable to update ssa form, so it has been removed. +
      • The syntax of volatile loads and stores in IR has been changed to + "load volatile"/"store volatile". The old + syntax ("volatile load"/"volatile store") + is still accepted, but is now considered deprecated.
      • +
      • The old atomic intrinscs (llvm.memory.barrier and + llvm.atomic.*) are now gone. Please use the new atomic + instructions, described in the atomics guide. +
      -
    • The target triple x86_64--mingw64 is obsoleted. Use x86_64--mingw32 - instead.
    • +

      Windows (32-bit)

      +
      -
    • The PointerTracking pass has been removed from mainline, and moved to The - ClamAV project (its only client).
    • - -
    • The LoopIndexSplit, LiveValues, SimplifyHalfPowrLibCalls, GEPSplitter, and - PartialSpecialization passes were removed. They were unmaintained, - buggy, or deemed to be a bad idea.
    • +
        +
      • On Win32(MinGW32 and MSVC), Windows 2000 will not be supported. + Windows XP or higher is required.
      +
      +

      Internal API Changes

      -
      +

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

      + LLVM API changes are:

        -
      • include/llvm/System merged into include/llvm/Support.
      • -
      • The llvm::APInt API was significantly - cleaned up.
      • - -
      • In the code generator, MVT::Flag was renamed to MVT::Glue to more accurately - describe its behavior.
      • - -
      • The system_error header from C++0x was added, and is now pervasively used to - capture and handle i/o and other errors in LLVM.
      • +
      • The biggest and most pervasive change is that llvm::Type's are no longer + returned or accepted as 'const' values. Instead, just pass around + non-const Type's.
      • -
      • The old sys::Path API has been deprecated in favor of the new PathV2 API, - which is more efficient and flexible.
      • +
      • PHINode::reserveOperandSpace has been removed. Instead, you + must specify how many operands to reserve space for when you create the + PHINode, by passing an extra argument + into PHINode::Create.
      • + +
      • PHINodes no longer store their incoming BasicBlocks as operands. Instead, + the list of incoming BasicBlocks is stored separately, and can be accessed + with new functions PHINode::block_begin + and PHINode::block_end.
      • + +
      • Various functions now take an ArrayRef instead of either a + pair of pointers (or iterators) to the beginning and end of a range, or a + pointer and a length. Others now return an ArrayRef instead + of a reference to a SmallVector + or std::vector. These include: +
          + +
        • CallInst::Create
        • +
        • ComputeLinearIndex (in llvm/CodeGen/Analysis.h)
        • +
        • ConstantArray::get
        • +
        • ConstantExpr::getExtractElement
        • +
        • ConstantExpr::getGetElementPtr
        • +
        • ConstantExpr::getInBoundsGetElementPtr
        • +
        • ConstantExpr::getIndices
        • +
        • ConstantExpr::getInsertElement
        • +
        • ConstantExpr::getWithOperands
        • +
        • ConstantFoldCall (in llvm/Analysis/ConstantFolding.h)
        • +
        • ConstantFoldInstOperands (in llvm/Analysis/ConstantFolding.h)
        • +
        • ConstantVector::get
        • +
        • DIBuilder::createComplexVariable
        • +
        • DIBuilder::getOrCreateArray
        • +
        • ExtractValueInst::Create
        • +
        • ExtractValueInst::getIndexedType
        • +
        • ExtractValueInst::getIndices
        • +
        • FindInsertedValue (in llvm/Analysis/ValueTracking.h)
        • +
        • gep_type_begin (in llvm/Support/GetElementPtrTypeIterator.h)
        • +
        • gep_type_end (in llvm/Support/GetElementPtrTypeIterator.h)
        • +
        • GetElementPtrInst::Create
        • +
        • GetElementPtrInst::CreateInBounds
        • +
        • GetElementPtrInst::getIndexedType
        • +
        • InsertValueInst::Create
        • +
        • InsertValueInst::getIndices
        • +
        • InvokeInst::Create
        • +
        • IRBuilder::CreateCall
        • +
        • IRBuilder::CreateExtractValue
        • +
        • IRBuilder::CreateGEP
        • +
        • IRBuilder::CreateInBoundsGEP
        • +
        • IRBuilder::CreateInsertValue
        • +
        • IRBuilder::CreateInvoke
        • +
        • MDNode::get
        • +
        • MDNode::getIfExists
        • +
        • MDNode::getTemporary
        • +
        • MDNode::getWhenValsUnresolved
        • +
        • SimplifyGEPInst (in llvm/Analysis/InstructionSimplify.h)
        • +
        • TargetData::getIndexedOffset
        • +
      • + +
      • All forms of StringMap::getOrCreateValue have been remove + except for the one which takes a StringRef.
      • + +
      • The LLVMBuildUnwind function from the C API was removed. The + LLVM unwind instruction has been deprecated for a long time + and isn't used by the current front-ends. So this was removed during the + exception handling rewrite.
      • + +
      • The LLVMAddLowerSetJmpPass function from the C API was + removed because the LowerSetJmp pass was removed.
      • + +
      • The DIBuilder interface used by front ends to encode + debugging information in the LLVM IR now expects clients to + use DIBuilder::finalize() at the end of translation unit to + complete debugging information encoding.
      • + +
      • The way the type system works has been + rewritten: PATypeHolder and OpaqueType are gone, + and all APIs deal with Type* instead of const + Type*. If you need to create recursive structures, then create a + named structure, and use setBody() when all its elements are + built. Type merging and refining is gone too: named structures are not + merged with other structures, even if their layout is identical. (of + course anonymous structures are still uniqued by layout).
      • + +
      • TargetSelect.h moved to Support/ from Target/
      • + +
      • UpgradeIntrinsicCall no longer upgrades pre-2.9 intrinsic calls (for + example llvm.memset.i32).
      • + +
      • It is mandatory to initialize all out-of-tree passes too and their dependencies now with + INITIALIZE_PASS{BEGIN,END,} + and INITIALIZE_{PASS,AG}_DEPENDENCY.
      • + +
      • The interface for MemDepResult in MemoryDependenceAnalysis has been + enhanced with new return types Unknown and NonFuncLocal, in addition to + the existing types Clobber, Def, and NonLocal.
      + +
      +
      @@ -821,35 +1167,34 @@ from the previous release.

      -
      +
      -

      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.

      - -
      +

      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.

      + 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 Alpha, Blackfin, CellSPU, MicroBlaze, MSP430, MIPS, PTX, SystemZ - and XCore backends are experimental.
      • -
      • llc "-filetype=obj" is experimental on all targets - other than darwin and ELF X86 systems.
      • - +
      • The Alpha, Blackfin, CellSPU, MicroBlaze, MSP430, MIPS, PTX, SystemZ and + XCore backends are experimental.
      • + +
      • llc "-filetype=obj" is experimental on all targets other + than darwin and ELF X86 systems.
      @@ -859,27 +1204,32 @@ href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev list.

      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'.
      • + all inline assembly that uses the X86 + floating point stack. It supports the 'f' and 't' constraints, but + not 'u'. +
      • The X86-64 backend does not yet support the LLVM IR instruction - va_arg. Currently, front-ends support variadic - argument constructs on X86-64 by lowering them manually.
      • + va_arg. Currently, front-ends support variadic argument + constructs on X86-64 by lowering them manually. +
      • Windows x64 (aka Win64) code generator has a few issues.
          -
        • llvm-gcc cannot build the mingw-w64 runtime currently - due to lack of support for the 'u' inline assembly - constraint and for X87 floating point inline assembly.
        • -
        • On mingw-w64, you will see unresolved symbol __chkstk - due to Bug 8919. - It is fixed in r128206.
        • +
        • llvm-gcc cannot build the mingw-w64 runtime currently due to lack of + support for the 'u' inline assembly constraint and for X87 floating + point inline assembly.
        • + +
        • On mingw-w64, you will see unresolved symbol __chkstk due + to Bug 8919. + It is fixed + in r128206.
        • +
        • Miss-aligned MOVDQA might crash your program. It is due to - Bug 9483, - lack of handling aligned internal globals.
        • + Bug 9483, lack + of handling aligned internal globals.
      • @@ -892,11 +1242,10 @@ href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev list.

        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.
        • +
        • The PPC32/ELF support lacks PIC support.
        @@ -906,14 +1255,15 @@ 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. -
        • +
        • 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.
        @@ -923,11 +1273,11 @@ results (PR1388). 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).
        • +
        • The SPARC backend only supports the 32-bit SPARC ABI (-m32); it does not + support the 64-bit SPARC ABI (-m64).
        @@ -937,10 +1287,10 @@ results (PR1388). Known problems with the MIPS back-end -
        +
          -
        • 64-bit MIPS targets are not supported yet.
        • +
        • 64-bit MIPS targets are not supported yet.
        @@ -950,14 +1300,13 @@ results (PR1388). 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.
        • - +
        • On 21164s, some rare FP arithmetic sequences which may trap do not have + the appropriate nops inserted to ensure restartability.
        +
        @@ -965,19 +1314,22 @@ appropriate nops inserted to ensure restartability. Known problems with the C back-end -
        +

        The C backend has numerous problems and is not being actively maintained. -Depending on it for anything serious is not advised.

        + Depending on it for anything serious is not advised.

        @@ -988,9 +1340,9 @@ Depending on it for anything serious is not advised.

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

        LLVM 2.9 will be the last release of llvm-gcc.

        +

        LLVM 2.9 was the last release of llvm-gcc.

        llvm-gcc is generally very stable for the C family of languages. The only major language feature of GCC not supported by llvm-gcc is the @@ -1007,8 +1359,11 @@ Depending on it for anything serious is not advised.

        dragonegg instead.

        The llvm-gcc 4.2 Ada compiler has basic functionality, but is no longer being -actively maintained. If you are interested in Ada, we recommend that you -consider using dragonegg instead.

        + actively maintained. If you are interested in Ada, we recommend that you + consider using dragonegg instead.

        + +
        +
        @@ -1017,19 +1372,18 @@ consider using dragonegg instead.

        -
        +
        -

        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.

        +

        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.

        + us via the mailing lists.