[llvm-announce] LLVM 1.2 Release & Status update

Chris Lattner sabre at nondot.org
Fri Mar 19 21:00:21 PST 2004

News flash: LLVM 1.2 is now available!

LLVM 1.2 is the result of ~3 months of hard work by many people in the
LLVM community.  It contains a bunch of new features, produces
substantially better code, and has many bug fixes over the 1.1 release.
A detailed list of new and improved features are included in the 1.2
release notes:

If you are using LLVM 1.0 or 1.1, we *highly* recommend upgrading to LLVM
1.2.  You can download LLVM from the releases page:

March Status Update

Since the February status update, LLVM received substantial code quality
improvements, compiler performance improvements, and even has some new
features.  All of these changes are in the new 1.2 release:

High-level changes:

1. The LLVM C-backend has been moved from the llvm-dis tool to the llc
   tool.  Instead of using 'llvm-dis -c x.bc -o x.cbe.c', now you should
   use 'llc -march=c x.bc -o x.cbe.c'.  This allows the C backend to share
   a bunch of code with the other code generators.
2. Brian fixed our autoconf configuration to not allow the definitions
   from our config.h file to leak into external client's code (PR180).
3. Brian wrote 'make install' and simple RPM generation targets.
4. 81 PRs have been fixed with a 1.2 milestone (these include code
   quality, code cleanup, quality of implementation improvements)

VMCore changes:

5. LLVM now handles large zero-initialized global variables much more
   efficiently than before (used by SPECINT95 among other programs).
6. LLVM has initial support for a new "select" instruction, which is
   useful for flattening control structures and recognizing idioms like
   min/max and saturated arithmetic.  Currently only the C backend
   supports it, though full support will be available in LLVM 1.3.  Here
   are the docs: http://llvm.cs.uiuc.edu/docs/LangRef.html#i_select
7. Misha added support to the pass manager for adding 'transitive'
   relationships between passes.
8. llvm.memset, llvm.memcpy, and llvm.memmove intrinsics were added to
   LLVM.  These allow code generators to produce fast inline code for
   these functions and for the optimizer to understand them.
9. LLVM now includes llvm.returnaddress & llvm.frameaddress intrinsics.
   These intrinsics are supported by the X86 and C backends and are
   produced by the C front-end (from the __builtin_return/frame_address()
   GCC extensions).

The new intrinsics are documented here:

Optimizer changes:

10. The LLVM profiler can now gather edge profiles and provide them to
    profile-guided optimization passes.
11. LLVM now includes a simple profile-guided basic block layout pass.
12. The LLVM optimizer can now transform code like "if (X == 0 || X ==
    12 || X == .." into a big switch statement.
13. The LLVM optimizer can now mark global variables 'constant' if they
    are obviously never written to, enabling many subsequent
14. LLVM has a new aggressive interprocedural optimization (-argpromotion)
    that turns small "by reference" arguments into by-value arguments.
    This is particularly useful for C++ programs, but does speed up some C
    programs a lot too.
15. LLVM can now hoist loop-invariant calls out of loops and eliminate
    redundant expressions involving calls (if they have no side effects).
    This is particularly useful for functions like sin/cos/strlen/...
16. The "basicaa" alias analysis pass is more aggressive when considering
    what local stack objects can be modified by a function call.

Code generator changes:

17. The LLVM native code generators now support exception handling
    constructs correctly (which include setjmp/longjmp).
18. The linear scan register allocator that Alkis wrote works much better
    than it did in 1.1.  There is one outstanding known problem (PR264),
    but it otherwise seems to work well, and generate much faster code
    than the local allocator (2x speedups are not uncommon, and it beats
    the C backend+GCC in some cases).  We would really appreciate testing
    of this allocator (use -regalloc=linearscan on the lli or llc command
    lines), as we hope to make it the default for 1.3.
19. Alkis and Brian have been working hard on the code generator, cleaning
    it up and simplifying it.
20. The target-independent code generator is now substantially faster than
    it used to be and uses less memory.
21. Alkis added support in the target-independent code generator to fold
    spill code into instructions on targets that support it (e.g. X86).
22. The X86 code generator now generates substantially better code than it
    used to and can take advantage of its powerful addressing modes.
23. Alkis wrote a generic "spiller" interface that can be used by
    arbitrary global register allocators.
24. The X86 code generator compiles memcpy and memset into rep movs/stos
25. Brian made the -print-machineinstrs debugging option common across all
    of the code generators.
26. Alkis converted the MachineBasicBlock class from "vector of pointers
    to instructions" to "doubly-linked ilist of instructions", making the
    code generator faster and easier to program.

C/C++ front-end changes:

27. The C front-end generates much more efficient code when expanding
    large aggregate value initializations and copies.
28. The C front-end now implements the GCC "labels as values" extension,
    which is often used to implement "threaded interpreters".
29. Several miscellaneous bugfixes and code quality improvements

Miscellaneous changes:

30. Reid Spencer contributed a patch that allowed us to remove our one
    annoying dependency on the boost library.
31. John added several new programs to the test suite.
32. Misha wrote a new generic 'code extractor' which can be used to rip a
    region of code out of one function into another, without breaking the
33. Bugpoint has several important improvements:
   1. It now has a code generator crash debugging mode.
   2. It is now faster, especially when debugging crashes.
   3. Bugpoint can now try to narrow down miscompilations to the loop nest
      being miscompiled, instead of just down to a function.  This is made
      possible by Misha's code extractor.
34. Alkis tweaked the problem sizes for many of the benchmarks in the
    testsuite, allowing us to get meaningful performance numbers from
35. The .ll file parser is substantially faster in some nasty cases.
36. Many minor bugs are dead and miscellaneous improvements have been

Also, as with the 1.0 and 1.1 releases, John Criswell was the one
primarily responsible for pulling the release together and ensuring that
it worked well.  Many, many, thanks go out to him for all of his hard

Here's a link to the February status update, which also includes a bunch
of new 1.2 additions/improvements/features:

If you have any questions or comments about LLVM or any of the features
in this status update, please feel free to contact us on the llvmdev list!



More information about the llvm-announce mailing list