[llvm-announce] LLVM 1.2 Release & Status update
Fri, 19 Mar 2004 23:00:21 -0600 (CST)
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
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:
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)
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()
The new intrinsics are documented here:
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
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!