Hi LLVMers,
Sorry for the delay, this status update should have been out a couple
weeks ago. Things have been absolutely crazy here. :)
May Status Update
-----------------
Overall, since the LLVM 1.2 release, we've fixed several LLVM
optimizations to produce better code (most have fallen into the "stop
doing stupid things" category) and implemented some new optimizations.
There are a few minor bug fixes (at the end), but overall, LLVM 1.2 seems
to be quite stable. If you're interested in doing performance work,
we recommend that you upgrade to CVS.
High-level notes:
1. I'm happy to announce that Reid Spencer is now the first non-UIUC LLVM
developer with full write access to the CVS repository! Welcome, Reid!
2. We presented an LLVM paper at the CGO'04 conference, which seemed to be
well-received and helped increase awareness of LLVM in the compiler
research community. http://llvm.cs.uiuc.edu/pubs/2004-01-30-CGO-LLVM.html
3. The 'select' instruction is now 100% supported by all components of
LLVM, including the code generators, optimizer, and the interpreter.
4. The LLVM 'opt' utility defaults to emitting the bytecode result to
standard out. If it detects that stdout is a console (a common
mistake), it now prints a message instead of flooding you with binary
gunk.
5. Misha wrote the http://llvm.cs.uiuc.edu/docs/ExtendingLLVM.html doc.
6. The gccld utility now includes the -native-cbe option.
7. LLVM now uses a little 'fpcmp' utility to diff the output of
benchmarks
instead of diff, which allows it to tolerate small numerical errors for
some benchmarks (which are hard to avoid with the X86 FPU).
8. John added new C++ programs to the test suite (kimwitu++, hbd, treecc).
VMCore changes:
9. LLVM now supports structures with more than 256 elements, and no
longer requires array indexes to be 64-bit integers.
10. Vladimir Prus contributed changes to make the inst_iterator work like
a proper C++ iterator.
Code quality improvements (fixing stupid behavior):
11. The inliner was fixed to no longer continuously inline mutually
recursive functions up until the inlining threshold.
12. The CallGraph class was changed, which has the effect of making the
inliner much more predictable and make better decisions.
13. The induction variable substitution pass now generates primary
induction variables that can be coallesced into a single register
instead of requiring two.
14. We now run the -prune-eh pass (which deletes unreachable exception
handlers) at link-time as well as at compile time.
New optimizations:
15. LLVM now includes a completely new and more powerful induction
variable analysis infrastructure, based on chains of recurrences.
16. LLVM has a new loop unroller/peeler pass. This is currently very
simple, as it is only able to completely peel loops that execute a
small constant number of times. It will be improved to be more
general in the future.
17. LLVM now has a simple loop-unswitching pass. It does the job well,
but needs a loop cleanup pass to clean up the resultant loops to be
most useful (it is not enabled by default in the gccas tool yet).
18. The -indvars pass now performs linear function test replacement and
exit value substitution optimizations.
Other optimizer improvements:
19. The ADCE pass now deletes function calls without side effects (as
determined by an alias analysis) whose results are not used.
20. The -loopsimplify pass can now "reconstruct" nested loops that
were
merged into a single natural loop, making loop optimizations much more
useful. See PR35 for details and examples.
21. LLVM can now constant propagate (directly or sparse conditionally)
calls to functions that it knows about (such as sin/cos/...).
22. The LLVM trip count analysis code is much more powerful.
23. LLVM can now turn code like "if (A < B || A > C)" into code
like "if
(A < B | A > C)", when profitable (eliminating a conditional
branch).
24. Several optimizers were improved to generate select instructions,
which eliminates conditional branches from the program.
Code generator changes:
25. Brian added code to the MachineBasicBlock class that allows the code
generator to create and maintain its own CFG, which isn't necessarily
the same as the LLVM CFG. This will allow the code generator to be
more aggressive in the future, and to support targets that need to
implement certain LLVM instructions with conditional branches (like
the select instruction).
26. The X86 code generator now generates *substantially* better code for
64-bit integer and FP operations, and can fold loads into many more
instructions (e.g. fp instructions).
27. The X86 backend turns select instructions into efficient conditional
moves.
Bugpoint changes:
28. The bugpoint code-generator-miscompilation-debugger can now use the
loop-extractor to narrow down bad code generation bugs to a loop.
29. Misha fixed the annoying problem that made debugging the LLVM JIT code
generators almost impossible for many programs (PR38).
30. Brian implemented PR40, allowing bugpoint to debug code generator bugs
that require options to be passed into LLC (e.g., -regalloc=linearscan).
31. Several bugs in bugpoint were fixed relating to loop extraction.
In addition, we've fixed the following bugs in LLVM 1.2:
configure: PR301
LLVM optimizers: PR306, PR310, PR332
X86 (JIT only): PR313
Sparc: PR333
C front-end: PR326
If you have any questions or comments about LLVM or any of the features
in this status update, please feel free to email the llvmdev list!
Here's the next pointer in our linked-list of status updates:
http://mail.cs.uiuc.edu/pipermail/llvm-announce/2004-March/000006.html
Also, thanks go out to John and Misha for proofreading this status update.
:)
-Chris
--
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/