mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2025-01-13 23:20:41 +00:00
several edits
llvm-svn: 52107
This commit is contained in:
parent
cc9adb2070
commit
16b9a37b1b
@ -195,6 +195,14 @@ bugs in C and Objective-C code.</p>
|
|||||||
</div>
|
</div>
|
||||||
<!-- *********************************************************************** -->
|
<!-- *********************************************************************** -->
|
||||||
|
|
||||||
|
<div class="doc_text">
|
||||||
|
|
||||||
|
<p>LLVM 2.3 includes a huge number of bug fixes, performance tweaks and minor
|
||||||
|
improvements. Some of the major improvements and new features are listed in
|
||||||
|
this section.
|
||||||
|
</p>
|
||||||
|
</div>
|
||||||
|
|
||||||
<!--=========================================================================-->
|
<!--=========================================================================-->
|
||||||
<div class="doc_subsection">
|
<div class="doc_subsection">
|
||||||
<a name="majorfeatures">Major New Features</a>
|
<a name="majorfeatures">Major New Features</a>
|
||||||
@ -261,15 +269,20 @@ bugs in C and Objective-C code.</p>
|
|||||||
|
|
||||||
<div class="doc_text">
|
<div class="doc_text">
|
||||||
|
|
||||||
<p>LLVM 2.3 fully supports the llvm-gcc 4.2 front-end.</p>
|
<p>LLVM 2.3 fully supports the llvm-gcc 4.2 front-end, and includes support
|
||||||
|
for the C, C++, Objective-C, Ada, and Fortran front-ends.</p>
|
||||||
|
|
||||||
<p>llvm-gcc 4.2 includes numerous fixes to better support the Objective-C
|
<p>
|
||||||
front-end. Objective-C now works very well on Mac OS/X.</p>
|
<ul>
|
||||||
|
<li>llvm-gcc 4.2 includes numerous fixes to better support the Objective-C
|
||||||
|
front-end. Objective-C now works very well on Mac OS/X.</li>
|
||||||
|
|
||||||
<p>Fortran EQUIVALENCEs are now supported by the gfortran front-end.</p>
|
<li>Fortran EQUIVALENCEs are now supported by the gfortran front-end.</li>
|
||||||
|
|
||||||
<p>llvm-gcc 4.2 includes many other fixes which improve conformance with the
|
<li>llvm-gcc 4.2 includes many other fixes which improve conformance with the
|
||||||
relevant parts of the GCC testsuite.</p>
|
relevant parts of the GCC testsuite.</li>
|
||||||
|
|
||||||
|
</ul></p>
|
||||||
|
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
@ -283,16 +296,18 @@ relevant parts of the GCC testsuite.</p>
|
|||||||
<p>New features include:
|
<p>New features include:
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
|
|
||||||
Common linkage?
|
|
||||||
|
|
||||||
Atomic operation support, Alpha, X86, X86-64, PowerPC. "__sync_synchronize",
|
|
||||||
"__sync_val_compare_and_swap", etc
|
|
||||||
|
|
||||||
<ul>
|
<ul>
|
||||||
<li>The C and Ocaml bindings have received additional improvements. The
|
<li>LLVM IR now directly represents "common" linkage, instead of representing it
|
||||||
bindings now cover pass managers, several transformation passes, iteration
|
as a form of weak linkage.</li>
|
||||||
over the LLVM IR, target data, and parameter attribute lists.</li>
|
|
||||||
|
<li>LLVM IR now has support for atomic operations, and this functionality can
|
||||||
|
be accessed through the llvm-gcc "__sync_synchronize",
|
||||||
|
"__sync_val_compare_and_swap", and related builtins. Support for atomics are
|
||||||
|
available in the Alpha, X86, X86-64, and PowerPC backends.</li>
|
||||||
|
|
||||||
|
<li>The C and Ocaml bindings have extended to cover pass managers, several
|
||||||
|
transformation passes, iteration over the LLVM IR, target data, and parameter
|
||||||
|
attribute lists.</li>
|
||||||
</ul>
|
</ul>
|
||||||
|
|
||||||
</div>
|
</div>
|
||||||
@ -309,15 +324,18 @@ LLVM 2.3 optimizers support a few major enhancements:</p>
|
|||||||
|
|
||||||
<ul>
|
<ul>
|
||||||
|
|
||||||
<li>Loop index set splitting on by default.<p>
|
<li><p>Loop index set splitting on by default.
|
||||||
This transformation hoists conditions from loop bodies and reduces loop's
|
This transformation hoists conditions from loop bodies and reduces a loop's
|
||||||
iteration space to improve performance. For example, <p>
|
iteration space to improve performance. For example,</p>
|
||||||
|
|
||||||
<pre>
|
<pre>
|
||||||
for (i = LB; i < UB; ++i)
|
for (i = LB; i < UB; ++i)
|
||||||
if (i <= NV)
|
if (i <= NV)
|
||||||
LOOP_BODY
|
LOOP_BODY
|
||||||
</pre>
|
</pre>
|
||||||
is transformed into
|
|
||||||
|
<p>is transformed into:</p>
|
||||||
|
|
||||||
<pre>
|
<pre>
|
||||||
NUB = min(NV+1, UB)
|
NUB = min(NV+1, UB)
|
||||||
for (i = LB; i < NUB; ++i)
|
for (i = LB; i < NUB; ++i)
|
||||||
@ -325,7 +343,7 @@ for (i = LB; i < NUB; ++i)
|
|||||||
</pre>
|
</pre>
|
||||||
</li>
|
</li>
|
||||||
|
|
||||||
<li>LLVM includes a new <tt>memcpy</tt> optimization pass which removes
|
<li>LLVM now includes a new <tt>memcpy</tt> optimization pass which removes
|
||||||
dead <tt>memcpy</tt> calls, unneeded copies of aggregates, and performs
|
dead <tt>memcpy</tt> calls, unneeded copies of aggregates, and performs
|
||||||
return slot optimization. The LLVM optimizer now notices long sequences of
|
return slot optimization. The LLVM optimizer now notices long sequences of
|
||||||
consecutive stores and merges them into <tt>memcpy</tt>'s where profitable.</li>
|
consecutive stores and merges them into <tt>memcpy</tt>'s where profitable.</li>
|
||||||
@ -333,14 +351,12 @@ consecutive 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
|
<li>Alignment detection for vector memory references and for <tt>memcpy</tt> and
|
||||||
<tt>memset</tt> is now more aggressive.</li>
|
<tt>memset</tt> is now more aggressive.</li>
|
||||||
|
|
||||||
<li>The aggressive dead code elimination (ADCE) optimization has been rewritten
|
<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
|
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
|
loops. Some of its prior functionality has been factored out into the loop
|
||||||
deletion pass, which <em>is</em> safe for infinite loops.</li>
|
deletion pass, which <em>is</em> safe for infinite loops. The new ADCE pass is
|
||||||
|
no longer based on control dependence, making it run faster.</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
|
<li>The 'SimplifyLibCalls' pass, which optimizes calls to libc and libm
|
||||||
functions for C-based languages, has been rewritten to be a FunctionPass
|
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
|
instead a ModulePass. This allows it to be run more often and to be
|
||||||
@ -354,6 +370,10 @@ deletion pass, which <em>is</em> safe for infinite loops.</li>
|
|||||||
|
|
||||||
<li>Several corner case bugs which could lead to deleting volatile memory
|
<li>Several corner case bugs which could lead to deleting volatile memory
|
||||||
accesses have been fixed.</li>
|
accesses have been fixed.</li>
|
||||||
|
|
||||||
|
<li>Several optimizations have been sped up, leading to faster code generation
|
||||||
|
with the same code quality.</li>
|
||||||
|
|
||||||
</ul>
|
</ul>
|
||||||
|
|
||||||
</div>
|
</div>
|
||||||
|
Loading…
x
Reference in New Issue
Block a user