diff --git a/docs/ReleaseNotes.html b/docs/ReleaseNotes.html index 7b0696c5bb3..68cc2cf78c0 100644 --- a/docs/ReleaseNotes.html +++ b/docs/ReleaseNotes.html @@ -71,15 +71,14 @@ href="http://llvm.cs.uiuc.edu/releases/">releases page.

This is the fourth public release of the LLVM compiler infrastructure. This release primarily improves the performance of the -code produced by all aspects of the LLVM compiler and adds many new features, and fixes a few -bugs as well.

+code produced by all aspects of the LLVM compiler, adds many new features, fixes a few +bugs, and speeds up the compiler.

At this time, LLVM is known to correctly compile and run all C & C++ -SPEC CPU2000 benchmarks, the Olden benchmarks, and the Ptrdist benchmarks. It -has also been used to compile many other programs. LLVM now also works -with a broad variety of C++ programs, though it has still received less testing -than the C front-end.

+SPEC CPU95 & 2000 benchmarks, the Olden benchmarks, and the Ptrdist +benchmarks, and many other programs. LLVM now also works +with a broad variety of C++ programs.

@@ -97,8 +96,8 @@ generators, and the interpreter.
  • Bugpoint can now narrow down code-generation bugs to a loop nest, where before it could only narrow them down to a function being miscompiled.
  • Bugpoint can now debug arbitrary -modes of llc and lli, by passing them command line flags (e.g., --regalloc=linearscan, -enable-correct-eh-support, etc.)
  • +modes of llc and lli, by passing them command line flags (e.g. +-regalloc=linearscan).
  • The Control Flow Graph in the native code generators is no longer constrained to be the same as the CFG for the LLVM input code.
  • The LLVM induction variable analysis routines have been rewritten.
  • @@ -108,8 +107,9 @@ replacement and exit value replacement optimizations.
  • LLVM now has first-class support for Accurate Garbage Collection, enabling the use of aggressive copying and generational collectors.
  • -
  • LLVM now includes an implementation of Andersen's interprocedural alias -analysis algorithm.
  • +
  • LLVM now includes a simple implementation of Andersen's interprocedural alias +analysis algorithm.
  • Bugpoint can extract individual basic blocks to track down reduce miscompilation testcases.
  • LLVM and the C front-end now work under Win32 using the @@ -117,29 +117,35 @@ basic blocks to track down reduce miscompilation testcases.
  • This includes the JIT compiler.
  • The LLVM code generator is now being documented.
  • -
  • There is a new tool, llvm-bcanalyzer. This tool can compute basic -statistics and bytecode density statistics on a module or function basis and -also dump out bytecode in a textual format that is lower level than assembly -(values are not resolved from slot numbers). It should only be of interest to -(a) those who are working to improve the bytecode format and (b) those who -really want to understand or document the details of the bytecode format.
  • -
  • The LLVM Bytecode file format is now +
  • LLVM includes a new tool, llvm-bcanalyzer, This tool +can compute various statistics and dump information about LLVM bytecode +encoding.
  • +
  • The LLVM bytecode file format is now documented.
  • LLVM now provides an llvm.isunordered intrinsic for efficient implementation of unordered floating point comparisons.
  • The llvmgcc front-end now supports the GCC builtins for ISO C99 floating point comparison macros (e.g., __builtin_islessequal).
  • -
  • Now that there are more source files than can fit on a 32Kbyte command -line (Linux's limit), there's a new utility for searching the sources. The -llvmgrep tool in the utils directory combines an egrep and a find without -passing filenames through the command line. This improves performance -slightly. Simply run llvmgrep like you might egrep but leave off the file -names.
  • -
  • We now generate HTML documentation and man pages for the tools from a single -source (perl-style POD files).
  • +
  • We now generate HTML documentation and man pages +for the tools from a single source (perl-style POD files).
  • The LLVM code generator can now dynamically load targets from shared objects.
  • +
  • LLVM now includes a "skeleton" target, which makes it easier to get +started porting LLVM to new architectures.
  • +
  • The linear scan register allocator is now enabled by default in the +target-independent code generator.
  • +
  • LLVM now includes a dead store elimination pass.
  • +
  • Bugpoint can now debug miscompilations that lead to the program going +into an infinite loop.
  • +
  • LLVM now provides interfaces to support ML-style pattern matching on the +LLVM IR.
  • +
  • LLVM now includes a context-sensitive mod/ref analysis +for global variables, which is now enabled by default in gccld.
  • +
  • LLVM can now autogenerate assembly printers for code generators from the +tablegen description of the target (before they were hand coded).
  • @@ -161,6 +167,10 @@ non-instruction entities, such as global constant initializer with 64-bit pointers.
  • Bugpoint doesn't support uses of external fns by immediate constant exprs
  • +
  • Can't add function passes that +depend on immutable passes to the FunctionPassManager.
  • +
  • Archive file reader doesn't +understand abbreviated names in headers
  • @@ -189,6 +199,10 @@ Bytecode Reader
  • Bytecode Enhancements Needed
  • [loopsimplify] Loop simplify is really slow on 252.eon
  • +
  • [code-cleanup] SymbolTable + class cleanup, Type should not derive from Value, eliminate + ConstantPointerRef class.
  • +
  • The memory footprint of the LLVM IR has been reduced substantially.
  • @@ -231,7 +245,7 @@ hits the inlining threshold.
  • The -inline pass no longer misses obvious inlining opportunities just because the callee eventually calls into an external function.
  • -
  • The -simplifycfg pass can now "if convert" simple statements into the new +
  • The -simplifycfg pass can now "if convert" simple statements into the select instruction.
  • The -loopsimplify pass can now break
  • The link-time optimizer now runs the -prune-eh pass (to remove unused exception handlers).
  • +
  • The link-time optimizer now runs dead store elimination and uses a simple +interprocedural alias analysis.
  • +
  • The -simplifycfg pass can now eliminate simple correlated branches (such as "if (A < B && A < B)", and can turn short-circuiting operators into the strict versions when useful (such as "if (A < B || A @@ -254,16 +271,14 @@ operators into the strict versions when useful (such as "if (A < B || A propagation of function calls. It currently supports a few math library functions like sqrt/sin/cos/etc.
  • -
  • The C backend now emits Syntactic +
  • The C backend now emits syntactic loops in the code to help C compilers whose optimizers do not recognize loops formed from gotos (like GCC).
  • -
  • Fixed: [sparcv9] null -often spilled to constant pool.
  • +
  • The SparcV9 backend no longers spills the null constant to the constant +pool.
  • -
  • Fixed: [code-cleanup] SymbolTable - class cleanup, Type should not derive from Value, eliminate - ConstantPointerRef class. All three changes have been made. @@ -274,7 +289,7 @@ were fixed: - -
    -In this release, the following portability problems were fixed: -
    - - -
    Known Problems @@ -635,14 +627,15 @@ Please report any bugs or problems.

    • The C++ front-end inherits all problems afflicting the C front-end.
    • -
    -

    IA64 note: The C++ front-end does not use IA64 ABI compliant layout of vtables. +

  • IA-64 specific: The C++ front-end does not use IA64 ABI compliant layout of v-tables. In particular, it just stores function pointers instead of function descriptors in the vtable. This bug prevents mixing C++ code compiled with LLVM with C++ objects compiled by other C++ compilers.

    + + @@ -688,13 +681,7 @@ href="http://gcc.gnu.org/gcc-3.4/changes.html">GCC 3.4 release notes.
    • -
    • Optimized (Release) versions of LLVM built with GCC 3.3.2 or 3.3.3 will - produce an llc tool that always enters an infinite loop due to what - appears to be an optimization bug (-O2 and -O3) in those versions of GCC. - This problem does not happen in GCC 3.3.1 nor GCC 3.4.0 nor does it happen if - you build a Debug version of LLVM. You are cautioned not to use GCC 3.3.2 or - GCC 3.3.3 to build Optimized versions of LLVM. It is unclear whether this problem - affects other backends but it is unlikely.
    • +
    • none yet