LLVM 2.8 Release Notes

+NOTE: This should be written to be self-contained without referencing llvm-gcc. +

DragonEgg is a port of llvm-gcc to gcc-4.5. Unlike llvm-gcc, dragonegg in theory does not require any gcc-4.5 @@ -186,32 +162,24 @@ linux and darwin (darwin may need additional gcc patches).

-The 2.8 release has the following notable changes: +The 2.9 release has the following notable changes:

The plugin loads faster due to exporting fewer symbols.
Additional vector operations such as addps256 are now supported.
Ada global variables with no initial value are no longer zero initialized, -resulting in better optimization.
The '-fplugin-arg-dragonegg-enable-gcc-optzns' flag now runs all gcc -optimizers, rather than just a handful.
Fortran programs using common variables now link correctly.
GNU OMP constructs no longer crash the compiler.

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.8, VMKit now supports copying garbage -collectors, and can be configured to use MMTk's copy mark-sweep garbage -collector. In LLVM 2.8, the VMKit .NET VM is no longer being maintained. +just-in-time compilation. + +UPDATE.

-

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

- -

TCE uses llvm-gcc/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.

- -

-

-Horizon is a bytecode -language and compiler written on top of LLVM, intended for producing -single-address-space managed code operating systems that -run faster than the equivalent multiple-address-space C systems. -More in-depth blurb is available on the wiki.

- -

-

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

- -

The -ClamAV bytecode compiler uses Clang and LLVM to compile a C-like -language, insert runtime checks, and generate ClamAV bytecode.

- -

-

-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 0.44 and later have been tested and are known to work with -LLVM 2.8 (and continue to work with older LLVM releases >= 2.5).

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

-

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

- -

-

-Clay is a new systems programming -language that is specifically designed for generic programming. It makes -generic programming very concise thanks to whole program type propagation. It -uses LLVM as its backend.

- -

-

-llvm-py has been updated to work -with LLVM 2.8. llvm-py provides Python bindings for LLVM, allowing you to write a -compiler backend or a VM in Python.

- -

-

-FAUST is a compiled language for real-time -audio signal processing. The name FAUST stands for Functional AUdio STream. Its -programming model combines two approaches: functional programming and block -diagram composition. In addition with the C, C++, JAVA output formats, the -Faust compiler can now generate LLVM bitcode, and works with LLVM 2.7 and -2.8.

- -

-

Jade -(Just-in-time Adaptive Decoder Engine) is a generic video decoder engine using -LLVM for just-in-time compilation of video decoder configurations. Those -configurations are designed by MPEG Reconfigurable Video Coding (RVC) committee. -MPEG RVC standard is built on a stream-based dataflow representation of -decoders. It is composed of a standard library of coding tools written in -RVC-CAL language and a dataflow configuration — block diagram — -of a decoder.

- -

Jade project is hosted as part of the Open -RVC-CAL Compiler and requires it to translate the RVC-CAL standard library -of video coding tools into an LLVM assembly code.

- -

-

Neko LLVM JIT -replaces the standard Neko JIT with an LLVM-based implementation. While not -fully complete, it is already providing a 1.5x speedup on 64-bit systems. -Neko LLVM JIT requires LLVM 2.8 or later.

- -

-

-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 0.2 works with LLVM 2.7, and the forthcoming Crack 0.2.1 release -builds on LLVM 2.8.

- -

-

-DTMC provides support for -Transactional Memory, which is an easy-to-use and efficient way to synchronize -accesses to shared memory. Transactions can contain normal C/C++ code (e.g., -__transaction { list.remove(x); x.refCount--; }) and will be executed -virtually atomically and isolated from other transactions.

- -

-

-Kai (Japanese 会 for -meeting/gathering) is an experimental interpreter that provides a highly -extensible runtime environment and explicit control over the compilation -process. Programs are defined using nested symbolic expressions, which are all -parsed into first-class values with minimal intrinsic semantics. Kai can -generate optimised code at run-time (using LLVM) in order to exploit the nature -of the underlying hardware and to integrate with external software libraries. -It is a unique exploration into world of dynamic code compilation, and the -interaction between high level and low level semantics.

- -

-

-OSL is a shading -language designed for use in physically based renderers and in particular -production rendering. By using LLVM instead of the interpreter, it was able to -meet its performance goals (>= C-code) while retaining the benefits of -runtime specialization and a portable high-level language. -

- -

-

LLVM 2.8 includes several major new capabilities:

+

LLVM 2.9 includes several major new capabilities:

As mentioned above, libc++ and LLDB are major new additions to the LLVM collective.
LLVM 2.8 now has pretty decent support for debugging optimized code. You - should be able to reliably get debug info for function arguments, assuming - that the value is actually available where you have stopped.
A new 'llvm-diff' tool is available that does a semantic diff of .ll - files.
The MC subproject has made major progress in this release. - Direct .o file writing support for darwin/x86[-64] is now reliable and - support for other targets and object file formats are in progress.

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

The build configuration machinery changed the output directory names. It - wasn't clear to many people that a "Release-Asserts" build was a release build - without asserts. To make this more clear, "Release" does not include - assertions and "Release+Asserts" does (likewise, "Debug" and - "Debug+Asserts").
The MSIL Backend was removed, it was unsupported and broken.
The ABCD, SSI, and SCCVN passes were removed. These were not fully - functional and their behavior has been or will be subsumed by the - LazyValueInfo pass.
The LLVM IR 'Union' feature was removed. While this is a desirable feature - for LLVM IR to support, the existing implementation was half baked and - barely useful. We'd really like anyone interested to resurrect the work and - finish it for a future release.
If you're used to reading .ll files, you'll probably notice that .ll file - dumps don't produce #uses comments anymore. To get them, run a .bc file - through "llvm-dis --show-annotations".
Target triples are now stored in a normalized form, and all inputs from - humans are expected to be normalized by Triple::normalize before being - stored in a module triple or passed to another library.

@@ -974,72 +447,6 @@ from the previous release.

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

LLVM 2.8 changes the internal order of operands in InvokeInst - and CallInst. - To be portable across releases, please use the CallSite class and the - high-level accessors, such as getCalledValue and - setUnwindDest. -
- You can no longer pass use_iterators directly to cast<> (and similar), - because these routines tend to perform costly dereference operations more - than once. You have to dereference the iterators yourself and pass them in. -
- llvm.memcpy.*, llvm.memset.*, llvm.memmove.* intrinsics take an extra - parameter now ("i1 isVolatile"), totaling 5 parameters, and the pointer - operands are now address-space qualified. - If you were creating these intrinsic calls and prototypes yourself (as opposed - to using Intrinsic::getDeclaration), you can use - UpgradeIntrinsicFunction/UpgradeIntrinsicCall to be portable across releases. -
- SetCurrentDebugLocation takes a DebugLoc now instead of a MDNode. - Change your code to use - SetCurrentDebugLocation(DebugLoc::getFromDILocation(...)). -
- The RegisterPass and RegisterAnalysisGroup templates are - considered deprecated, but continue to function in LLVM 2.8. Clients are - strongly advised to use the upcoming INITIALIZE_PASS() and - INITIALIZE_AG_PASS() macros instead. -
- The constructor for the Triple class no longer tries to understand odd triple - specifications. Frontends should ensure that they only pass valid triples to - LLVM. The Triple::normalize utility method has been added to help front-ends - deal with funky triples. -
- The signature of the GCMetadataPrinter::finishAssembly virtual - function changed: the raw_ostream and MCAsmInfo arguments - were dropped. GC plugins which compute stack maps must be updated to avoid - having the old definition overload the new signature. -
- The signature of MemoryBuffer::getMemBuffer changed. Unfortunately - calls intended for the old version still compile, but will not work correctly, - leading to a confusing error about an invalid header in the bitcode. -
- Some APIs were renamed: -
- llvm_report_error -> report_fatal_error
- llvm_install_error_handler -> install_fatal_error_handler
- llvm::DwarfExceptionHandling -> llvm::JITExceptionHandling
- VISIBILITY_HIDDEN -> LLVM_LIBRARY_VISIBILITY
-
- Some public headers were renamed: -
- llvm/Assembly/AsmAnnotationWriter.h was renamed - to llvm/Assembly/AssemblyAnnotationWriter.h -