maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity

add some notes. 

llvm-svn: 52087
This commit is contained in:
Chris Lattner 2008-06-08 02:45:07 +00:00
parent 041604ba9f
commit 7795ea929a
1 changed files with 86 additions and 38 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

124
llvm/docs/ReleaseNotes.html
View File

@ -84,9 +84,22 @@ upgrading LLVM 1.9 files to LLVM 2.x syntax, but you can always use a previous
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 @@ this project, please see its <a href="http://clang.llvm.org/">web site</a>.</p>
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
@ -182,31 +196,6 @@ over the LLVM IR, target data, and parameter attribute lists.</li>
</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>
</ul>
</div>
<!--=========================================================================-->
<div class="doc_subsection">
<a name="optimizer">Optimizer Improvements</a>
@ -234,17 +223,69 @@ for (i = LB; i < NUB; ++i)
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 @@ pass, which <em>is</em> safe for infinite loops.</li>
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 @@ pass, which <em>is</em> safe for infinite loops.</li>
<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 @@ pass, which <em>is</em> safe for infinite loops.</li>
<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>