LLVM 1.5 Release Notes

-This release includes new native code generators for Alpha, IA-64, and SPARC-V8 (32-bit -SPARC). These code generators are still beta quality, but are progressing -rapidly. -

+ +

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.

New Instruction Selector Framework

llvm-gcc +Improvements

New Support For Custom Calling Convetions

Optimizer +Improvements

New Support for "Proper Tail Calls"

Code +Generator Enhancements

The release now includes support for proper tail calls, as -required to implement languages like Scheme. Tail calls make use of two -features: custom calling conventions (described above), which allow the code -generator to emit code for the caller to deallocate its own stack when it -returns. The second feature is a flag on the call -instruction, which indicates that the callee does not access the callers -stack frame (indicating that it is acceptable to deallocate the caller stack -before invoking the callee). LLVM proper tail calls run on the system stack (as -do normal calls), supports indirect tail calls, tail calls with arbitrary -numbers of arguments, tail calls where the callee requires more argument space -than the caller, etc. The only case not supported are varargs calls, but that -could be added if desired. +

+New features include:

In order for a front-end to get guaranteed tail call, it must mark functions -as "fastcc", mark calls with the 'tail' marker, and follow the call with a -return of the called value (or void). The optimizer and code generator attempt -to handle more general cases, but the simple case will always work if the code -generator supports tail calls. Here is a simple example:

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.

-fastcc int %bar(int %X, int(double, int)* %FP) {        ; fastcc
-     %Y = tail call fastcc int %FP(double 0.0, int %X)  ; tail, fastcc
-     ret int %Y
-}
-

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:

+ +

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.

In LLVM 1.5, the X86 code generator is the only target that has been enhanced -to support proper tail calls (other targets will be enhanced in future). -Further, because this support was added very close to the release, it is -disabled by default. Pass -enable-x86-fastcc to llc to enable it. X86 -support will be enabled by default in the next LLVM release.

Target-Specific +Improvements

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:

Bugs fixed in the LLVM Core:

[dse] DSE deletes stores that - are partially overwritten by smaller stores
[instcombine] miscompilation of - setcc or setcc in one case
Transition code for LLVM 1.0 style varargs was removed from the .ll file - parser. LLVM 1.0 bytecode files are still supported.

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.

Code Generator Bugs:

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

Bugs in the C/C++ front-end:

Module::getNamedFunction() is now called + Module::getFunction().
SymbolTable.h has been split into ValueSymbolTable.h and +TypeSymbolTable.h.

- Notes + +

+ Known problems with the Alpha back-end

Inline assembly is not yet supported.
On 21164s, some rare FP arithmetic sequences which may trap do not have the +appropriate nops inserted to ensure restartability.
"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.
The following Unix system functionality has not been tested and may not -work: -
1. sigsetjmp, siglongjmp - These are not turned into the - appropriate invoke/unwind instructions. Note that - setjmp and longjmp are compiled correctly. -
2. getcontext, setcontext, makecontext - - These functions have not been tested. -

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.
Extended Asm: Assembler instructions with C expressions as operands.
Constraints: Constraints for asm operands.
Asm Labels: Specifying the assembler name to use for a C symbol.
Explicit Reg Vars: Defining variables residing in specified registers.
Vector Extensions: Using vector instructions through built-in functions.
Target Builtins: Built-in functions specific to particular targets.
Thread-Local: Per-thread variables.
Pragmas: Pragmas accepted by GCC.

+ +

+ Known problems with the IA64 back-end +

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.

Variable Length: - Arrays whose length is computed at run time.
- Supported, but allocated stack space is not freed until the function returns (noted above).

Function Attributes: +
C++ programs are likely to fail on IA64, as calls to setjmp are +made where the argument is not 16-byte aligned, as required on IA64. (Strictly +speaking this is not a bug in the IA64 back-end; it will also be encountered +when building C++ programs using the C back-end.)

The C++ front-end does not use IA64 +ABI compliant layout of v-tables. In particular, it just stores function +pointers instead of function descriptors in the vtable. This bug prevents +mixing C++ code compiled with LLVM with C++ objects compiled by other C++ +compilers.

Supported:

format

format_arg

non_null

noreturn

constructor

destructor

unused

deprecated

warn_unused_result

weak

There are a few ABI violations which will lead to problems when mixing LLVM +output with code built with other compilers, particularly for floating-point +programs.

Ignored:

noinline

always_inline

pure

const

nothrow

malloc

no_instrument_function

cdecl

Defining vararg functions is not supported (but calling them is ok).

Unsupported:

used

section

alias

visibility

regparm

stdcall

fastcall

Variable Attributes: - Specifying attributes of variables.
- Supported: cleanup, common, nocommon, - deprecated, transparent_union, - unused, weak
+
The Itanium backend has bitrotted somewhat.

Unsupported:

aligned

mode

packed

section

shared

tls_model

vector_size

dllimport

dllexport

Type Attributes: Specifying attributes of types.
- Supported: transparent_union, unused, - deprecated, may_alias
+ +

+ Known problems with the C back-end +

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

The C backend does not support inline + assembly code.

+ +

+ + + +

+ Known problems with the C front-end +

+ + +

Bugs

+ +

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.

+ +

+ + +

+ Notes +

+ +

"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.
llvm-gcc does not support __builtin_apply yet. + See Constructing Calls: Dispatching a call to another function.
+
llvm-gcc partially supports these GCC extensions:
+
1. 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.
2. Function Attributes: + + Declaring that functions have no side effects or that they can never + return.
  + + Supported: alias, always_inline, cdecl, + constructor, destructor, + deprecated, fastcall, format, + format_arg, non_null, noreturn, regparm + section, stdcall, unused, used, + visibility, warn_unused_result, weak
  + + Ignored: noinline, pure, const, nothrow, + malloc, no_instrument_function
+

The following extensions are known to be supported:

llvm-gcc supports the vast majority of GCC extensions, including:
1. Pragmas: Pragmas accepted by GCC.
2. Local Labels: Labels local to a block.
3. Other Builtins: + Other built-in functions.
4. Variable Attributes: + Specifying attributes of variables.
5. Type Attributes: Specifying attributes of types.
6. Thread-Local: Per-thread variables.
7. Variable Length: + Arrays whose length is computed at run time.
8. Labels as Values: Getting pointers to labels and computed gotos.
9. Statement Exprs: Putting statements and declarations inside expressions.
10. Typeof: typeof: referring to the type of an expression.
11. Empty Structures: Structures with no members.
12. Variadic Macros: Macros with a variable number of arguments.
13. Escaped Newlines: Slightly looser rules for escaped newlines.
14. Extended Asm: Assembler instructions with C expressions as operands.
15. Constraints: Constraints for asm operands.
16. Asm Labels: Specifying the assembler name to use for a C symbol.
17. Explicit Reg Vars: Defining variables residing in specified registers.
18. Vector Extensions: Using vector instructions through built-in functions.
19. Target Builtins: Built-in functions specific to particular targets.
20. Subscripting: Any array can be subscripted, even if not an lvalue.
21. Pointer Arith: Arithmetic on void-pointers and function pointers.
22. Initializers: Non-constant initializers.