LLVM 2.0 Progress Report

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

  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

  7. Anton contributed support for external weak linkage and hidden

  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

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

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

31. The PowerPC 64 JIT now supports addressing code loaded above the 2G

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:

If you have any questions or comments, please contact the LLVMdev
mailing list (llvmdev at cs.uiuc.edu)!