[llvm-commits] [llvm] r52087 - /llvm/trunk/docs/ReleaseNotes.html
Chris Lattner
sabre at nondot.org
Sat Jun 7 19:45:07 PDT 2008
Author: lattner
Date: Sat Jun 7 21:45:07 2008
New Revision: 52087
URL: http://llvm.org/viewvc/llvm-project?rev=52087&view=rev
Log:
add some notes.
Modified:
llvm/trunk/docs/ReleaseNotes.html
Modified: llvm/trunk/docs/ReleaseNotes.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=52087&r1=52086&r2=52087&view=diff
==============================================================================
--- llvm/trunk/docs/ReleaseNotes.html (original)
+++ llvm/trunk/docs/ReleaseNotes.html Sat Jun 7 21:45:07 2008
@@ -84,9 +84,22 @@
LLVM release to do this. One nice impact of this is that the LLVM regression
test suite no longer depends on llvm-upgrade, which makes it run faster.</p>
-<p>LLVM 2.3 renames the LLVMBuilder and LLVMFoldingBuilder classes to
- IRBuilder.</p>
+<p>LLVM API Changes:</p>
+<ul>
+<li>Several core LLVM IR classes have migrated to use 'FOOCLASS::Create(...)'
+ instead of 'new FOOCLASS(...)' (e.g. where FOOCLASS=BasicBlock). We hope to
+ standardize on FOOCLASS::Create for all IR classes in the future, but not
+ all of them have been moved over yet.</li>
+<li>LLVM 2.3 renames the LLVMBuilder and LLVMFoldingBuilder classes to
+ IRBuilder.</li>
+<li>MRegisterInfo was renamed to TargetRegisterInfo.</li>
+<li>The MappedFile class is gone, please use MemoryBuffer instead.</li>
+<li>The '-enable-eh' flag to LLC has been removed. Now code should encode
+ whether it is safe to not generate unwind information for a function by
+ tagging the Function object with the 'nounwind' attribute.</li>
+
+</ul>
</div>
<!--=========================================================================-->
@@ -172,7 +185,8 @@
Common linkage?
-Atomic operation support, Alpha, X86, X86-64, PowerPC. "__sync_synchronize"
+Atomic operation support, Alpha, X86, X86-64, PowerPC. "__sync_synchronize",
+"__sync_val_compare_and_swap", etc"
<ul>
<li>The C and Ocaml bindings have received additional improvements. The
@@ -184,31 +198,6 @@
<!--=========================================================================-->
<div class="doc_subsection">
-<a name="codegen">Code Generator Improvements</a>
-</div>
-
-<div class="doc_text">
-
-<p>We put a significant amount of work into the code generator infrastructure,
-which allows us to implement more aggressive algorithms and make it run
-faster:</p>
-
-<ul>
-<li>MemOperand in the code generator: describe me!.</li>
-<li>The target-independent code generator infrastructure now uses LLVM's APInt
- class to handle integer values, which allows it to support integer types
- larger than 64 bits. Note that support for such types is also dependent on
- target-specific support. Use of APInt is also a step toward support for
- non-power-of-2 integer sizes.</li>
-<li>Several compile time speedups for code with large basic blocks.</li>
-<li>Several improvements which make llc's <tt>--view-sunit-dags</tt>
- visualization of scheduling dependency graphs easier to understand.</li>
-</ul>
-
-</div>
-
-<!--=========================================================================-->
-<div class="doc_subsection">
<a name="optimizer">Optimizer Improvements</a>
</div>
@@ -234,17 +223,69 @@
LOOP_BODY
</pre>
</li>
-<li>LLVM includes a new <tt>memcpy</tt> optimization pass which optimizes out dead
-<tt>memcpy</tt> calls, unneeded copies of aggregates, and handles the return slot
-optimization. The LLVM optimizer now notices long sequences of consequtive
-stores and merges them into <tt>memcpy</tt>s where profitable.</li>
+
+<li>LLVM includes a new <tt>memcpy</tt> optimization pass which optimizes out
+dead <tt>memcpy</tt> calls, unneeded copies of aggregates, and handles the
+return slot optimization. The LLVM optimizer now notices long sequences of
+consequtive stores and merges them into <tt>memcpy</tt>s where profitable.</li>
+
<li>Alignment detection for vector memory references and for <tt>memcpy</tt> and
<tt>memset</tt> is now more aggressive.</li>
-<li>The aggressive dead code elimination (ADCE) optimization has been rewritten to make
-it both faster and safer in the presence of code containing infinite loops.
-Some of its prior functionality has been factored out into the loop deletion
-pass, which <em>is</em> safe for infinite loops.</li>
+<li>The aggressive dead code elimination (ADCE) optimization has been rewritten
+to make it both faster and safer in the presence of code containing infinite
+loops. Some of its prior functionality has been factored out into the loop
+deletion pass, which <em>is</em> safe for infinite loops.</li>
+
+<li>Several optimizations have been sped up, leading to faster code generation
+ with the same code quality.</li>
+
+<li>The 'SimplifyLibCalls' pass, which optimizes calls to libc and libm
+ functions for C-based languages, has been rewritten to be a FunctionPass
+ instead a ModulePass. This allows it to be run more often and to be
+ included at -O1 in llvm-gcc. It was also extended to include more
+ optimizations and several corner case bugs are fixed.</li>
+
+<li>LLVM now includes a simple 'Jump Threading' pass, which attemps to simplify
+ the conditional branches with information about predecessor blocks. This
+ simplifies the control flow graph. This pass is pretty basic at this point,
+ but catches some important cases and provides a foundation to build off
+ of.</li>
+</ul>
+
+</div>
+
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="codegen">Code Generator Improvements</a>
+</div>
+
+<div class="doc_text">
+
+<p>We put a significant amount of work into the code generator infrastructure,
+which allows us to implement more aggressive algorithms and make it run
+faster:</p>
+
+<ul>
+<li>MemOperand in the code generator: describe me!.</li>
+
+<li>The target-independent code generator infrastructure now uses LLVM's APInt
+ class to handle integer values, which allows it to support integer types
+ larger than 64 bits. Note that support for such types is also dependent on
+ target-specific support. Use of APInt is also a step toward support for
+ non-power-of-2 integer sizes.</li>
+
+<li>Several compile time speedups for code with large basic blocks.</li>
+
+<li>Several improvements which make llc's <tt>--view-sunit-dags</tt>
+ visualization of scheduling dependency graphs easier to understand.</li>
+
+<li>The code generator allows targets to write patterns that generate subreg
+ references directly in .td files now.</li>
+
+<li><tt>memcpy</tt> lowering in the backend is more aggressive, particularly for
+ <tt>memcpy</tt> calls introduced by the code generator when handling
+ pass-by-value structure argument copies.</li>
</ul>
</div>
@@ -265,7 +306,11 @@
now interoperates very well on X86-64 systems with other compilers.</li>
<li>The LLVM X86 backend now supports the support SSE 4.1 instruction set, and
- the llvm-gcc 4.2 front-end supports the SSE 4.1 compiler builtins.</li>
+ the llvm-gcc 4.2 front-end supports the SSE 4.1 compiler builtins. Various
+ generic vector operations (insert/extract/shuffle) are much more efficient
+ when SSE 4.1 is enabled. The JIT automatically takes advantage of these
+ instructions, but llvm-gcc must be explicitly told to use them, e.g. with
+ <tt>-march=penryn</tt>.</li>
<li>The X86 backend now does a number of optimizations that aim to avoid
converting numbers back and forth from SSE registers to the X87 floating
@@ -286,6 +331,8 @@
<li>128-bit integers are now supported on x86-64 targets.</li>
+<li>The register allocator can now rematerialize PIC-base computations.</li>
+
</ul>
</div>
@@ -320,7 +367,8 @@
<ul>
<li>LLVM now builds with GCC 4.3.</li>
-<li>llvm2cpp tool has been folded into llc, use <tt>llc -march=cpp</tt></li>
+<li><tt>llvm2cpp</tt> tool has been folded into llc, use
+ <tt>llc -march=cpp</tt></li>
</ul>
</div>
More information about the llvm-commits
mailing list