[llvm-announce] LLVM May Status Update

Chris Lattner sabre@nondot.org
Thu, 6 May 2004 12:29:18 -0500 (CDT)


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/