Hi Everyone,
I'm happy to say that LLVM has made many leaps and bounds since the
last update in November. Because we are bumping the major version
number with this release, we're letting the release go for twice as
long as our planned release schedule (6 months instead of 3). We are
currently half way through the LLVM 2.0 development cycle.
So far, many important and invasive changes have landed in 2.0,
including a complete replacement of the integer type system
(necessitating replacement of many instructions), lots of new features
have been added (e.g. ARM/Thumb is now fully supported), and of course
many bugs have been found and fixed.
Here are some of the most notable aspects of LLVM CVS (to become LLVM
2.0) so far:
Major LLVM Changes:
1. llvm-gcc3 is now officially unsupported. LLVM 2.0 will require
users to upgrade to llvm-gcc4. llvm-gcc4 includes many features
over llvm-gcc3, is faster, and is much easier to build. Whenever
I refer to llvm-gcc in this email, I mean llvm-gcc4.
2. Reid contributed changes to make the integer types in LLVM
completely signless. This means that we have types like i8/i16/i32
instead of ubyte/sbyte/short/ushort/int etc.
In order to support this, the LLVM operations that depend on sign
have been split up into separate instructions. For example,
instead of shr, we now have ashr/lshr. Instead of 'cast', we now
12 explicit instructions like trunc, zext, and sext. See
http://llvm.org/PR950 for more details.
This change makes the IR more powerful and efficient. We now
no-longer have casts that simply change sign (e.g. int <-> uint),
and we now support new operations like bitcast from fp to integer.
3. Reid and Sheng contributed changes to support arbitrary bitwidth
integers (e.g. i13, i36, i42, etc) in the front-end and LLVM IR
(the code generator does not support them yet). CVS currently
supports bitwidths <= 64 bits. Work to support bitwidths larger
than 64 bits is underway. See http://llvm.org/PR1043 for more
details.
4. Reid removed the 'type planes' of LLVM 1.x. 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. See http://llvm.org/PR411 for more information.
5. Global variables and functions in .ll files are now prefixed with
@ instead of %. This fixes some long-standing ambiguity problems
with some cases. See http://llvm.org/PR645 for more details.
New Features:
6. Devang implemented support for Precompiled Headers (PCH) in
llvm-gcc.
7. Anton contributed support for external weak linkage and hidden
visibility.
8. Andrew contributed support for packed structure types, which allows
LLVM to express unaligned data more naturally.
9. Support for inline assembly in llvm-gcc is much improved, and many
related bugs have been fixed.
10. Duncan Sands has contributed many llvm-gcc patches to better
support Ada, including support for nested functions.
11. Reid added support for tracking function parameter/result
attributes in LLVM.
Optimizer Improvements:
12. Devang rewrote the pass manager, making it significantly smaller,
simpler and more extensible. He added support for running
FunctionPass's interlaced with CallGraphSCCPass's, which improves
the cost model in the inliner and speeds it up.
13. The -scalarrepl pass can now promote unions containing FP values
into
a register, it can also handle unions of vectors of the same size.
14. Nick Lewycky contributed significant improvements to the predicate
simplifier pass, making it able to do simple value range
propagation
and eliminate more conditionals.
Target-Independent Code Generator Enhancements:
15. Jim contributed initial pieces of support for Zero-cost DWARF
exception handling. It is now possible to throw through
LLVM-compiled stack frames (callee save registers are properly
restored) and C++ 'catch' statements work in simple cases.
16. Owen extended TargetData to support better target parameterization
in the .ll/.bc files, eliminating the 'pointersize/endianness'
attributes in the files. See http://llvm.org/PR761 for more info.
17. Scott Michel contributed patches to generalize TargetData for finer
grained alignment handling, handling of vector alignment, and
handling of preferred alignment.
18. Evan improved the scheduler to better reduce register pressure on
X86 and other targets that are register pressure sensitive.
19. Evan contributed support for software floating point routines.
20. Jim improved DWARF debug information generation. LLVM now passes
most of the GDB testsuite on MacOS and debug info is more dense.
21. Nate's work on a direct Mach-o .o file writer is making great
progress. Many small apps work, but it is not quite complete yet.
X86-Specific Code Generator Enhancements:
22. Dan Gohman contributed several patches to improve linux/x86-64
support.
23. Anton contributed PIC support for linux/x86.
24. Anton contributed support for the GCC regparm attribute, and code
in the X86 backend to respect it.
25. Evan added various improvements for the X86-64 JIT, allowing it to
generate code in the large code model.
26. LLVM now supports inline asm with multiple constraint letters per
operand (like "ri") which is common in X86 inline asms.
27. Andrew contributed early support for X86 inline asm in the C
backend.
Other Target-Specific Code Generator Enhancements:
28. Lauro and Rafael contributed several improvements to the ARM
backend, including basic inline asm support, weak linkage support,
static ctor/dtor support and many bug fixes.
29. Evan contributed major enhancements to the ARM backend, including
support for ARM v4-v6, vfp support, soft float, pre/postinc
support, load/store multiple generation, and constant pool entry
motion (to support large functions).
30. Evan contributed support for Thumb code generation (an ARM
subtarget).
31. The PowerPC 64 JIT now supports addressing code loaded above the 2G
boundary.
32. Nick Lewycky contributed several patches to improve support for the
Linux/ppc ABI.
33. Jim contributed many bug fixes for PowerPC 64.
Internal Cleanups:
34. Sheng merged the ConstantBool, ConstantIntegral and ConstantInt
classes together, we now just have ConstantInt.
35. LLVM no longer relies on static destructors to shut itself
down. Instead, it lazily initializes itself and shuts down when
llvm_shutdown() is explicitly called.
36. LLVM now has significantly fewer static contructors, reducing
startup time.
37. Bill refactored several classes to reduce the amount of code that
gets linked into apps that use the JIT.
38. Dan Gohman contributed patches to simplify construction of
intrinsic function declarations.
Other Changes:
39. Reid contributed the llvm-upgrade tool, which migrates LLVM 1.9 .ll
files to LLVM 2.0 syntax. This is the primary upgrade path for
files compiled with LLVM 1.x to LLVM 2.x.
40. Reid removed the gccas/gccld tools. They have been replaced with
small shell scripts that invoke opt/llvm-ld respectively. These
scripts may be removed before LLVM 2.0 is released, so please
migrate away from them. This reduces LLVM's install footprint.
41. LLVM has had a lot of performance work, specifically designed to
tune datastructure usage. This makes several critical components
faster. http://llvm.org/docs/ProgrammersManual.html#datastructure
42. As the community has continued to grow, we found it useful to
codify some of the development practices we use for new
contributors. If you're interested in our "community
architecture", I encourage you to read through the 'LLVM Developer
Policy' document: http://llvm.org/docs/DeveloperPolicy.html
As usual, there have been a ton of bug fixes and other improvements.
LLVM has successfully built a number of large projects like Mozilla,
Qt, etc. There have also been a large number of minor codegen
improvements - the compiler generates better code than ever before.
As you can see, LLVM 2.0 is shaping up to be an amazing release. Many
thanks go out to everyone who has contributed to it in both large and
small ways. The LLVM community is vibrant and growing!
Finally, here is the previous status report, the LLVM 1.9 Release:
http://lists.cs.uiuc.edu/pipermail/llvm-announce/2006-November/
000020.html
If you have any questions or comments, please contact the LLVMdev
mailing list (llvmdev at cs.uiuc.edu)!
-Chris
--
http://nondot.org/sabre/
http://llvm.org/
