This document contains the release notes for the LLVM compiler -infrastructure, release 1.9. Here we describe the status of LLVM, including any -known problems and major improvements from the previous release. The most -up-to-date version of this document (corresponding to LLVM CVS) can be found -on the LLVM releases web site. If you are -not reading this on the LLVM web pages, you should probably go there because -this document may be updated after the release.
+infrastructure, release 2.0. Here we describe the status of LLVM, including +major improvements from the previous release and any known problems. All LLVM +releases may be downloaded from the LLVM +releases web site.For more information about LLVM, including information about the latest release, please check out the main LLVM @@ -46,7 +43,8 @@ web site. If you have questions or comments, the LLVM developer's mailing list is a good place to send them.
-Note that if you are reading this file from CVS or the main LLVM web page, +
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 the current or previous releases, see the releases page.
@@ -61,67 +59,175 @@ href="http://llvm.org/releases/">releases page.This is the tenth public release of the LLVM Compiler Infrastructure. This -release incorporates a large number of enhancements, new features, and bug -fixes. We recommend that all users of previous LLVM versions upgrade. -
+This is the eleventh public release of the LLVM Compiler Infrastructure. +Being the first major release since 1.0, this release is different in several +ways from our previous releases:
+ +-
+
- We took this as an opportunity to +break backwards compatibility with the LLVM 1.x bytecode and .ll file format. +If you have LLVM 1.9 .ll files that you would like to upgrade to LLVM 2.x, we +recommend the use of the stand alone llvm-upgrade +tool (which is included with 2.0). We intend to keep compatibility with .ll +and .bc formats within the 2.x release series, like we did within the 1.x +series. +
- There are several significant change to the LLVM IR and internal APIs, such + as a major overhaul of the type system, the completely new bitcode file + format, etc (described below). +
- We designed the release around a 6 month release cycle instead of the usual + 3-month cycle. This gave us extra time to develop and test some of the + more invasive features in this release. +
- LLVM 2.0 no longer supports the llvm-gcc3 front-end. Users are required to + upgrade to llvm-gcc4. llvm-gcc4 includes many features over + llvm-gcc3, is faster, and is much easier to + build from source. +
Note that while this is a major version bump, this release has been + extensively tested on a wide range of software. It is easy to say that this + is our best release yet, in terms of both features and correctness. This is + the first LLVM release to correctly compile and optimize major software like + LLVM itself, Mozilla/Seamonkey, Qt 4.3rc1, kOffice, etc out of the box on + linux/x86. +
LLVM 1.9 now fully supports the x86-64 instruction set on Mac OS/X, and -supports it on Linux (and other operating systems) when compiling in -static -mode. LLVM includes JIT support for X86-64, and supports both Intel EMT-64T -and AMD-64 architectures. The X86-64 instruction set permits addressing a -64-bit addressing space and provides the compiler with twice the -number of integer registers to use.
-LLVM now includes liblto which can -be used to integrate LLVM Link-Time Optimization support into a native linker. -This allows LLVM .bc to transparently participate with linking an application, -even when some .o files are in LLVM form and some are not.
+Changes to the LLVM IR itself:
+ +-
+
+
- Integer types are now completely signless. This means that we + have types like i8/i16/i32 instead of ubyte/sbyte/short/ushort/int + etc. LLVM operations that depend on sign have been split up into + separate instructions (PR950). This + eliminates cast instructions that just change the sign of the operands (e.g. + int -> uint), which reduces the size of the IR and makes optimizers + simpler to write. + +
- Integer types with arbitrary bitwidths (e.g. i13, i36, i42, i1057, etc) are + now supported in the LLVM IR and optimizations (PR1043). However, neither llvm-gcc + (PR1284) nor the native code generators + (PR1270) support non-standard width + integers yet. + +
- 'Type planes' have been removed (PR411). + It is no longer possible to have two values with the same name in the + same symbol table. This simplifies LLVM internals, allowing significant + speedups. + +
- Global variables and functions in .ll files are now prefixed with + @ instead of % (PR645). + +
- The LLVM 1.x "bytecode" format has been replaced with a + completely new binary representation, named 'bitcode'. The Bitcode Format brings a + number of advantages to the LLVM over the old bytecode format: it is denser + (files are smaller), more extensible, requires less memory to read, + is easier to keep backwards compatible (so LLVM 2.5 will read 2.0 .bc + files), and has many other nice features. + +
- Load and store instructions now track the alignment of their pointer + (PR400). This allows the IR to + express loads that are not sufficiently aligned (e.g. due to '#pragma + packed') or to capture extra alignment information. +
Major new features:
+ +-
+
+
- A number of ELF features are now supported by LLVM, including 'visibility', + extern weak linkage, Thread Local Storage (TLS) with the __thread + keyword, and symbol aliases. + Among other things, this means that many of the special options needed to + configure llvm-gcc on linux are no longer needed, and special hacks to build + large C++ libraries like Qt are not needed. + +
- LLVM now has a new MSIL backend. llc -march=msil will now turn LLVM + into MSIL (".net") bytecode. This is still fairly early development + with a number of limitations. + +
- A new llvm-upgrade tool + exists to migrates LLVM 1.9 .ll files to LLVM 2.0 syntax. +
llvm-gcc4 now supports generating debugging info for Linux, Cygwin and MinGW. -This extends the PPC/Darwin and X86/Darwin debugging support available in the -1.8 release. DWARF is a standard debugging format used on many platforms.
+New features include: +
+ +-
+
- Precompiled Headers (PCH) are now supported. + +
- "#pragma packed" is now supported, as are the various features + described above (visibility, extern weak linkage, __thread, aliases, + etc). + +
- Tracking function parameter/result attributes is now possible. + +
- Many internal enhancements have been added, such as improvements to + NON_LVALUE_EXPR, arrays with non-zero base, structs with variable sized + fields, VIEW_CONVERT_EXPR, CEIL_DIV_EXPR, nested functions, and many other + things. This is primarily to supports non-C GCC front-ends, like Ada. + +
- It is simpler to configure llvm-gcc for linux. + +
The mid-level optimizer is now faster and produces better code in many cases. - Significant changes include:
+New features include: +
-
-
- LLVM includes a new 'predicate simplifier' pass, which - currently performs dominator tree-based optimizations. -
- The complete loop unroll pass now supports unrolling of - multiple basic block loops. -
- The 'globalopt' pass can now perform the scalar replacement of - aggregates transformation on some heap allocations. -
- The globalsmodref-aa alias analysis can now track 'indirect pointer - globals' more accurately. -
- The instruction combiner can now perform element propagation -analysis of vector expressions, eliminating computation of vector elements -that are not used. +
- The pass manager has been entirely + rewritten, making it significantly smaller, simpler, and more extensible. + Support has been added to run FunctionPasses interlaced with + CallGraphSCCPasses, we now support loop transformations + explicitly with LoopPass, and ModulePasses may now use the + result of FunctionPasses. + +
- LLVM 2.0 includes a new loop rotation pass, which converts "for loops" into + "do/while loops", where the condition is at the bottom of the loop. + +
- The Loop Strength Reduction pass has been improved, and we now support + sinking expressions across blocks to reduce register pressure. + +
- The -scalarrepl pass can now promote unions containing FP values + into a register, it can also handle unions of vectors of the same + size. + +
- The [Post]DominatorSet classes have been removed from LLVM and clients + switched to use the more-efficient ETForest class instead. + +
- The ImmediateDominator class has also been removed, and clients have been + switched to use DominatorTree instead. + +
- The predicate simplifier pass has been improved, making it able to do + simple value range propagation and eliminate more conditionals. However, + note that predsimplify is not enabled by default in llvm-gcc. +
-The LLVM Target-Independent code generator now supports more target features and -optimizes many cases more aggressively. New features include: +New features include:
-
-
- LLVM now includes a late branch folding pass which optimizes code - layout, performs several branch optzns, and deletes unreachable code. -
- The code generator now support targets that have pre/post-increment - addressing modes. -
- LLVM now supports dynamically-loadable register allocators and - schedulers. -
- LLVM 1.9 includes several improvements to inline asm support, - including support for new constraints and modifiers. -
- The register coalescer is now more aggressive than before, - allowing it to eliminate more copies. + +
- LLVM now supports software floating point, which allows LLVM to target + chips that don't have hardware FPUs (e.g. ARM thumb mode). + +
- A new register scavenger has been implemented, which is useful for + finding free registers after register allocation. This is useful when + rewriting frame references on RISC targets, for example. + +
- Heuristics have been added to avoid coalescing vregs with very large live + ranges to physregs. This was bad because it effectively pinned the physical + register for the entire lifetime of the virtual register (PR711). + +
- Support now exists for very simple (but still very useful) + rematerialization the register allocator, enough to move + instructions like "load immediate" and constant pool loads. + +
- Switch statement lowering is significantly better, improving codegen for + sparse switches that have dense subregions, and implemented support + for the shift/and trick. + +
- LLVM now supports tracking physreg sub-registers and super-registers + in the code generator, and includes extensive register + allocator changes to track them. + +
- There is initial support for virtreg sub-registers + (PR1350). + +
+Other improvements include: +
+ +-
+
+
- Inline assembly support is much more solid that before. + The two primary features still missing are support for 80-bit floating point + stack registers on X86 (PR879), and + support for inline asm in the C backend (PR802). + +
- DWARF debug information generation has been improved. LLVM now passes + most of the GDB testsuite on MacOS and debug info is more dense. + +
- Codegen support for Zero-cost DWARF exception handling has been added (PR592). It is mostly + complete and just in need of continued bug fixes and optimizations at + this point. However, support in llvm-g++ is disabled with an + #ifdef for the 2.0 release (PR870). + +
- The code generator now has more accurate and general hooks for + describing addressing modes ("isLegalAddressingMode") to + optimizations like loop strength reduction and code sinking. + +
- Progress has been made on a direct Mach-o .o file writer. Many small + apps work, but it is still not quite complete. +
In addition, the LLVM target description format has itself been extended in several ways:
-
-
- tblgen now allows definition of 'multiclasses' which can be - used to factor instruction patterns more aggressively in .td files. -
- LLVM has a new TargetAsmInfo class which captures a variety of - information about the target assembly language format. -
- .td files now support "${:foo}" syntax for encoding - subtarget-specific assembler syntax into instruction descriptions. +
- TargetData now supports better target parameterization in + the .ll/.bc files, eliminating the 'pointersize/endianness' attributes + in the files (PR761). + +
- TargetData was generalized for finer grained alignment handling, + handling of vector alignment, and handling of preferred alignment + +
- LLVM now supports describing target calling conventions + explicitly in .td files, reducing the amount of C++ code that needs + to be written for a port. +
Further, several significant target-specific enhancements are included in -LLVM 1.9:
+X86-specific Code Generator Enhancements: +
-
-
- The LLVM ARM backend now supports more instructions - and the use of a frame pointer. It is now possible to build - libgcc and a simple cross compiler, but it is not considered "complete" yet. - -
- LLVM supports the Win32 dllimport/dllexport linkage and - stdcall/fastcall calling conventions. +
- The MMX instruction set is now supported through intrinsics. +
- The scheduler was improved to better reduce register pressure on + X86 and other targets that are register pressure sensitive. +
- Linux/x86-64 support is much better. +
- PIC support for linux/x86 has been added. +
- The X86 backend now supports the GCC regparm attribute. +
- LLVM now supports inline asm with multiple constraint letters per operand + (like "mri") which is common in X86 inline asms. +
ARM-specific Code Generator Enhancements:
+ +-
+
- The ARM code generator is now stable and fully supported. + +
- There are major new features, including support for ARM + v4-v6 chips, vfp support, soft float point support, pre/postinc support, + load/store multiple generation, constant pool entry motion (to support + large functions), inline asm support, weak linkage support, static + ctor/dtor support and many bug fixes. + +
- Added support for Thumb code generation (llc -march=thumb). + +
- The ARM backend now supports the ARM AAPCS/EABI ABI and PIC codegen on + arm/linux. + +
- Several bugs were fixed for DWARF debug info generation on arm/linux. + +
PowerPC-specific Code Generator Enhancements:
+ +-
+
- The PowerPC 64 JIT now supports addressing code loaded above the 2G + boundary. + +
- Improved support for the Linux/ppc ABI and the linux/ppc JIT is fully + functional now. llvm-gcc and static compilation are not fully supported + yet though. + +
- Many PowerPC 64 bug fixes. +
This release includes many other improvements, including improvements to - the optimizers and code generators (improving the generated code) changes to - speed up the compiler in many ways (improving algorithms and fine tuning - code), and changes to reduce the code size of the compiler itself.
More specific changes include:
-
-
- The llvm-test framework now supports SPEC2006. -
- LLVM now includes a FAQ about the -getelementptr instruction. -
- Bugpoint now supports a new "-find-bugs" mode. This mode makes - bugpoint permute pass sequences to try to expose bugs due to pass - sequencing. -
- The JIT now supports lazily streaming code from multiple modules at a - time, implicitly linking the code as it goes. -
Several significant API changes have been made. If you are maintaining -out-of-tree code, please be aware that:
+LLVM 2.0 contains a revamp of the type system and several other significant +internal changes. If you are programming to the C++ API, be aware of the +following major changes:
-
-
- The ConstantSInt and ConstantUInt classes have been merged into the - ConstantInt class. -
As a step towards making LLVM's integer types signless, several new -instructions have been added to LLVM. The Div instruction is now -UDiv, SDiv, and FDiv. The Rem instruction -is now URem, SRem and FRem. See the -Language Reference for details on these new -instructions.
-ConstantBool::True and ConstantBool::False have been - renamed to ConstantBool::getTrue() and - ConstantBool::getFalse().
-- The 'analyze' tool has been merged into the 'opt' tool. +
- Pass registration is slightly different in LLVM 2.0 (you now need an + intptr_t in your constructor), as explained in the Writing an LLVM Pass + document. + +
- ConstantBool, ConstantIntegral and ConstantInt + classes have been merged together, we now just have + ConstantInt. + +
- Type::IntTy, Type::UIntTy, Type::SByteTy, ... are + replaced by Type::Int8Ty, Type::Int16Ty, etc. LLVM types + have always corresponded to fixed size types + (e.g. long was always 64-bits), but the type system no longer includes + information about the sign of the type. Also, the + Type::isPrimitiveType() method now returns false for integers. + +
- Several classes (CallInst, GetElementPtrInst,
+ ConstantArray, etc), that once took std::vector as
+ arguments now take ranges instead. For example, you can create a
+ GetElementPtrInst with code like:
+
+
+ Value *Ops[] = { Op1, Op2, Op3 }; + GEP = new GetElementPtrInst(BasePtr, Ops, 3); ++ + This avoids creation of a temporary vector (and a call to malloc/free). If + you have an std::vector, use code like this: ++ std::vector<Value*> Ops = ...; + GEP = new GetElementPtrInst(BasePtr, &Ops[0], Ops.size()); +
+ +
+
+ - CastInst is now abstract and its functionality is split into + several parts, one for each of the new + cast instructions. +
- Instruction::getNext()/getPrev() are now private (along with + BasicBlock::getNext, etc), for efficiency reasons (they are now no + longer just simple pointers). Please use BasicBlock::iterator, etc + instead. + + +
- Module::getNamedFunction() is now called + Module::getFunction(). + +
- SymbolTable.h has been split into ValueSymbolTable.h and +TypeSymbolTable.h.
LLVM is known to work on the following platforms:
-
-
- Intel and AMD machines running Red Hat Linux, Fedora Core and FreeBSD +
- Intel and AMD machines running Red Hat Linux, Fedora Core and FreeBSD (and probably other unix-like systems). +
- PowerPC and X86-based Mac OS X systems, running 10.2 and above in 32-bit and + 64-bit modes.
- Intel and AMD machines running on Win32 using MinGW libraries (native) -
- Sun UltraSPARC workstations running Solaris 8.
- Intel and AMD machines running on Win32 with the Cygwin libraries (limited support is available for native builds with Visual C++). -
- PowerPC and X86-based Mac OS X systems, running 10.2 and above in 32-bit and - 64-bit modes. +
- Sun UltraSPARC workstations running Solaris 8.
- Alpha-based machines running Debian GNU/Linux.
- Itanium-based machines running Linux and HP-UX.
-
-
- The SPARC backend only supports the 32-bit SPARC ABI (-m32), it does not - support the 64-bit SPARC ABI (-m64). +
- Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6 +processors, thumb program can crash or produces wrong +results (PR1388). +
- Compilation for ARM Linux OABI (old ABI) is supported, but not fully tested. + +
- There is a bug in QEMU-ARM (<= 0.9.0) which causes it to incorrectly execute +programs compiled with LLVM. Please use more recent versions of QEMU.
-
-
-
- The C back-end produces code that violates the ANSI C Type-Based Alias -Analysis rules. As such, special options may be necessary to compile the code -(for example, GCC requires the -fno-strict-aliasing option). This -problem probably cannot be fixed. - -
- Zero arg vararg functions are not -supported. This should not affect LLVM produced by the C or C++ -frontends. - -
- The C backend does not correctly implement the llvm.stacksave or -llvm.stackrestore -intrinsics. This means that some code compiled by it can run out of stack -space if they depend on these (e.g. C99 varargs). - -
- The C backend does not support inline - assembly code. +
- The SPARC backend only supports the 32-bit SPARC ABI (-m32), it does not + support the 64-bit SPARC ABI (-m64).
-
-
- The ARM backend is currently in early development stages, it is not -ready for production use. +
- The C backend does not support inline + assembly code.
-
-
- In the JIT, dlsym() on a symbol compiled by the JIT will not - work. -
- -
llvm-gcc4 is far more stable and produces better code than llvm-gcc3, but -does not currently support Link-Time -Optimization or C++ Exception Handling, -which llvm-gcc3 does.
- -llvm-gcc4 does not support the GCC indirect -goto extension, but llvm-gcc3 does.
+llvm-gcc4 does not currently support Link-Time +Optimization on most platforms "out-of-the-box". Please inquire on the +llvmdev mailing list if you are interested.
-
-
- "long double" is transformed by the front-end into "double". There is no -support for floating point data types of any size other than 32 and 64 -bits. +
"long double" is silently transformed by the front-end into "double". There +is no support for floating point data types of any size other than 32 and 64 +bits.
-- Although many GCC extensions are supported, some are not. In particular,
- the following extensions are known to not be supported:
-
-
-
- Local Labels: Labels local to a block. -
- Nested Functions: As in Algol and Pascal, lexical scoping of functions. -
- Constructing Calls: Dispatching a call to another function. -
- Thread-Local: Per-thread variables. -
- Pragmas: Pragmas accepted by GCC. -
The following GCC extensions are partially supported. An ignored - attribute means that the LLVM compiler ignores the presence of the attribute, - but the code should still work. An unsupported attribute is one which is - ignored by the LLVM compiler and will cause a different interpretation of - the program.
+ llvm-gcc does not support __builtin_apply yet. + See Constructing Calls: Dispatching a call to another function.
+
+llvm-gcc partially supports these GCC extensions:
-
-
- Variable Length:
- Arrays whose length is computed at run time.
- Supported, but allocated stack space is not freed until the function returns (noted above).
+ - Nested Functions: As in Algol and Pascal, lexical scoping of functions.
+ Nested functions are supported, but llvm-gcc does not support non-local + gotos or taking the address of a nested function. - Function Attributes:
Declaring that functions have no side effects or that they can never
return.
- Supported: constructor, destructor, + Supported: alias, always_inline, cdecl, + constructor, destructor, deprecated, fastcall, format, - format_arg, non_null, noreturn, - stdcall, unused, used, - warn_unused_result, weak
- - Ignored: noinline, - always_inline, pure, const, nothrow, - malloc, no_instrument_function, cdecl
+ format_arg, non_null, noreturn, regparm + section, stdcall, unused, used, + visibility, warn_unused_result, weak
- Unsupported: section, alias, - visibility, regparm, all other target specific - attributes
-
- - Variable Attributes:
- Specifying attributes of variables.
- Supported: cleanup, common, nocommon, - deprecated, dllimport, - dllexport, transparent_union, - unused, used, weak
- - Unsupported: aligned, mode, packed, - section, shared, tls_model, - vector_size, all target specific attributes. -
-
- - Type Attributes: Specifying attributes of types.
- Supported: transparent_union, unused, - deprecated, may_alias
- - Unsupported: aligned, packed, - all target specific attributes.
-
- - Other Builtins:
- Other built-in functions.
- We support all builtins which have a C language equivalent (e.g., - __builtin_cos), __builtin_alloca, - __builtin_types_compatible_p, __builtin_choose_expr, - __builtin_constant_p, and __builtin_expect - (currently ignored). We also support builtins for ISO C99 floating - point comparison macros (e.g., __builtin_islessequal), - __builtin_prefetch, __builtin_popcount[ll], - __builtin_clz[ll], and __builtin_ctz[ll].
+ Ignored: noinline, pure, const, nothrow,
+ malloc, no_instrument_function
+
- - Variable Length:
- Arrays whose length is computed at run time.
llvm-gcc supports the vast majority of GCC extensions, including:
-
+
- Pragmas: Pragmas accepted by GCC. +
- Local Labels: Labels local to a block. +
- Other Builtins: + Other built-in functions. +
- Variable Attributes: + Specifying attributes of variables. +
- Type Attributes: Specifying attributes of types. +
- Thread-Local: Per-thread variables. +
- Variable Length: + Arrays whose length is computed at run time.
- Labels as Values: Getting pointers to labels and computed gotos.
- Statement Exprs: Putting statements and declarations inside expressions.
- Typeof:
typeof: referring to the type of an expression.
@@ -610,20 +789,15 @@ lists, please let us know (also including whether or not they work).
- llvm-gcc4 does not support C++ exception handling at all yet. +
- llvm-gcc4 only has partial support for C++ +Exception Handling, and it is not enabled by default. + +
-- - -For this release, the C++ front-end is considered to be fully +
The C++ front-end is considered to be fully tested and works for a number of non-trivial programs, including LLVM -itself.
+itself, Qt, Mozilla, etc. -- Notes -- -@@ -657,11 +831,10 @@ itself.-
-
A wide variety of additional information is available on the LLVM web page, including documentation and publications describing algorithms and -components implemented in LLVM. The web page also contains versions of the -API documentation which is up-to-date with the CVS version of the source code. +href="http://llvm.org">LLVM web page, in particular in the documentation section. The web page also +contains versions of the API documentation which is up-to-date with the +Subversion version of the source code. You can access versions of these documents specific to this release by going into the "llvm/doc/" directory in the LLVM tree.
@@ -680,7 +853,7 @@ lists.- The LLVM Compiler Infrastructure
+ LLVM Compiler Infrastructure
Last modified: $Date$
The following extensions are known to be supported:
+