RPCSX/llvm
1
0
Fork 0
mirror of https://github.com/RPCSX/llvm.git synced 2024-12-02 00:36:36 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Finish up the first draft of the release notes.

Browse Source 
improvements are welcome, please commit any changes directly to SVN.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128992 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Chris Lattner 2011-04-06 06:29:50 +00:00
parent c5ac61d64f
commit 49123fd58c
2 changed files with 90 additions and 117 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/CodeGenerator.html
View File

@ -2532,7 +2532,7 @@ OperandTy: VirtReg, | VirtReg, UnsImm, VirtReg, SignExtImm PhysReg
<div class="doc_text"> <div class="doc_text">
<p>x86 has an experimental feature which provides <p>x86 has an feature which provides
the ability to perform loads and stores to different address spaces the ability to perform loads and stores to different address spaces
via the x86 segment registers. A segment override prefix byte on an via the x86 segment registers. A segment override prefix byte on an
instruction causes the instruction's memory access to go to the specified instruction causes the instruction's memory access to go to the specified

205
docs/ReleaseNotes.html
View File

@ -28,11 +28,13 @@
<p>Written by the <a href="http://llvm.org">LLVM Team</a></p> <p>Written by the <a href="http://llvm.org">LLVM Team</a></p>
</div> </div>
<!--
<h1 style="color:red">These are in-progress notes for the upcoming LLVM 2.9 <h1 style="color:red">These are in-progress notes for the upcoming LLVM 2.9
release.<br> release.<br>
You may prefer the You may prefer the
<a href="http://llvm.org/releases/2.8/docs/ReleaseNotes.html">LLVM 2.8 <a href="http://llvm.org/releases/2.8/docs/ReleaseNotes.html">LLVM 2.8
Release Notes</a>.</h1> Release Notes</a>.</h1>
-->
<!-- *********************************************************************** --> <!-- *********************************************************************** -->
<h1> <h1>
@ -579,35 +581,34 @@ infrastructure, which allows us to implement more aggressive algorithms and make
it run faster:</p> it run faster:</p>
<ul> <ul>
<!-- SplitKit -->
<li>The pre-register-allocation (preRA) instruction scheduler models register <li>The pre-register-allocation (preRA) instruction scheduler models register
pressure much more accurately in some cases. This allows the adoption of more pressure much more accurately in some cases. This allows the adoption of more
aggressive scheduling heuristics. aggressive scheduling heuristics without causing spills to be generated.
</li> </li>
LiveDebugVariables is a new pass that keeps track of debugging information for <li>LiveDebugVariables is a new pass that keeps track of debugging information
user variables that are kept in registers in optimized builds. for user variables that are promoted to registers in optimized builds.</li>
Scheduler now models operand latency and pipeline forwarding.
Major regalloc rewrite, not on by default for 2.9 and not advised to use it.
* New basic register allocator that can be used as a safe fallback when
debugging. Enable with -regalloc=basic.
* New infrastructure for live range splitting. SplitKit can break a live
interval into smaller pieces while preserving SSA form, and SpillPlacement
can help find the best split points. This is a work in progress so the API
is changing quickly.
* The inline spiller has learned to clean up after live range splitting. It
can hoist spills out of loops, and it can eliminate redundant spills.
Rematerialization works with live range splitting.
* New greedy register allocator using live range splitting. This will be the
default register allocator in the next LLVM release, but it is not turned on
by default in 2.9.
<li>The scheduler now models operand latency and pipeline forwarding.</li>
<li>A major register allocator infrastructure rewrite is underway. It is not on
by default for 2.9 and you are not advised to use it, but it has made
substantial progress in the 2.9 timeframe:
<ul>
<li>A new -regalloc=basic "basic" register allocator can be used as a simple
fallback when debugging. It uses the new infrastructure.</li>
<li>New infrastructure is in place for live range splitting. "SplitKit" can
break a live interval into smaller pieces while preserving SSA form, and
SpillPlacement can help find the best split points. This is a work in
progress so the API is changing quickly.</li>
<li>The inline spiller has learned to clean up after live range splitting. It
can hoist spills out of loops, and it can eliminate redundant spills.</li>
<li>Rematerialization works with live range splitting.</li>
<li>The new "greedy" register allocator using live range splitting. This will
be the default register allocator in the next LLVM release, but it is not
turned on by default in 2.9.</li>
</ul>
</li>
</ul> </ul>
</div> </div>
@ -621,31 +622,31 @@ Major regalloc rewrite, not on by default for 2.9 and not advised to use it.
</p> </p>
<ul> <ul>
<li> <li>LLVM 2.9 includes a complete reimplementation of the MMX instruction set.
X86: Reimplemented all of MMX to introduce a new LLVM IR x86_mmx type. Now The reimplementation uses a new LLVM IR <a
random types like &lt;2 x i32&gt; are not iseld to mmx without emms. The href="LangRef.html#t_x86mmx">x86_mmx</a> type to ensure that MMX operations
-disable-mmx flag is gone now. are <em>only</em> generated from source that uses MMX builtin operations. With
this, random types like &lt;2 x i32&gt; are not turned into to MMX operations
(which can be catastrophic without proper "emms" insertion). Because the X86
code generator always generates reliable code, the -disable-mmx flag is now
removed.
</li> </li>
<li> <li>X86 support for FS/GS relative loads and stores using <a
X86 support for FS/GS relative loads and stores using address space 256/257 are href="CodeGenerator.html#x86_memory">address space 256/257</a> work reliably
reliable now. now.</li>
</li>
<li> <li>LLVM 2.9 generates much better code in several cases by using adc/sbb to
X86: Much better codegen for several cases using adc/sbb instead of cmovs for avoid generation of conditional move instructions for conditional increment
conditional increment and other idioms. and other idioms.</li>
</li>
<li> <li>The X86 backend has adopted a new preRA scheduling mode, "list-ilp", to
The X86 backend has adopted a new preRA scheduling shorten the height of instruction schedules without inducing register spills.
mode, "list-ilp", to shorten the height of instruction schedules </li>
without inducing register spills.
</li>
MC assembler support for 3dNow! and 3DNowA instructions. <li>The MC assembler support for 3dNow! and 3DNowA instructions.</li>
<li>Several bugs have been fixed for Windows x64 code generator.</li> <li>Several bugs have been fixed for Windows x64 code generator.</li>
</ul> </ul>
</div> </div>
@ -660,17 +661,17 @@ X86: Much better codegen for several cases using adc/sbb instead of cmovs for
</p> </p>
<ul> <ul>
<li>ARM Fast ISel</li> <li>The ARM backend now has a fast instruction selector, which dramatically
<li>ARM: New code placement pass.</li> improves -O0 compile times.</li>
<li>ARM: Improved code generation for Cortex-A8 and Cortex-A9 CPUs.</li> <li>The ARM backend has new tuning for Cortex-A8 and Cortex-A9 CPUs.</li>
<li>ARM: __builtin_prefetch turns into prefetch instructions.</li> <li>The __builtin_prefetch builtin (and llvm.prefetch intrinsic) is compiled
<li>Countless ARM microoptimizations.</li> into prefetch instructions instead of being discarded.</li>
<li> The ARM backend preRA scheduler now models machine resources at cycle <li> The ARM backend preRA scheduler now models machine resources at cycle
granularity. This allows the scheduler to both accurately model granularity. This allows the scheduler to both accurately model
instruction latency and avoid overcommitting functional units.</li> instruction latency and avoid overcommitting functional units.</li>
<li>Countless ARM microoptimizations have landed in LLVM 2.9.</li>
</ul> </ul>
</div> </div>
@ -681,15 +682,16 @@ X86: Much better codegen for several cases using adc/sbb instead of cmovs for
<div class="doc_text"> <div class="doc_text">
<ul> <ul>
PPC: Switched to MCInstPrinter, and MCCodeEmitter. Ready to implement support <li>MicroBlaze: major updates for aggressive delay slot filler, MC-based
for directly writing out mach-o object files, but noone seems interested. assembly printing, assembly instruction parsing, ELF .o file emission, and MC
instruction disassembler have landed.</li>
MicroBlaze: major updates for aggressive delay slot filler, MC-based assembly
printing, assembly instruction parsing, ELF .o file emission, and MC <li>SPARC: Many improvements, including using the Y registers for
instruction disassembler. multiplications and addition of a simple delay slot filler.</li>
SPARC: Many improvements, including using the Y registers for multiplications <li>PowerPC: The backend has been largely MC'ized and is ready to support
and addition of a simple delay slot filler. directly writing out mach-o object files. Noone seems interested in finishing
this final step though.</li>
</ul> </ul>
</div> </div>
@ -706,48 +708,26 @@ on LLVM 2.8, this section lists some "gotchas" that you may run into upgrading
from the previous release.</p> from the previous release.</p>
<ul> <ul>
last release for llvm-gcc <li><b>This is the last release to support the llvm-gcc frontend.</b></li>
<li> <li>LLVM has a new <a href="CodingStandards.html#ll_naming">naming
New naming rules in coding standards: CodingStandards.html#ll_naming convention standard</a>, though the codebase hasn't fully adopted it yet.</li>
</li>
<li>The new DIBuilder class provides a simpler interface for front ends to
encode debug info in LLVM IR, and has replaced DIFactory.</li>
<li>LLVM IR and other tools always work on normalized target triples (which have
- DIBuilder provides simpler interface for front ends like Clang to encode debug info in LLVM IR. been run through <tt>Triple::normalize</tt>).</li>
- This interface hides implementation details (e.g. DIDerivedType, existence of compile unit etc..) that any front end should not know about.
For example, DIFactory DebugFactory; <li>The target triple x86_64--mingw64 is obsoleted. Use x86_64--mingw32
Ty = DebugFactory.CreateDerivedType(DW_TAG_volatile_type, instead.</li>
findRegion(TYPE_CONTEXT(type)),
StringRef(), <li>The PointerTracking pass has been removed from mainline, and moved to The
getOrCreateFile(main_input_filename), ClamAV project (its only client).</li>
0 /*line no*/,
NodeSizeInBits(type),
NodeAlignInBits(type),
0 /*offset */,
0 /* flags */,
MainTy);
can be replaced by
DbgTy = DBuilder.createQualifiedType(DW_TAG_volatile_type, MainTy);
DIFactory is gone now.
<li>The LoopIndexSplit, LiveValues, SimplifyHalfPowrLibCalls, GEPSplitter, and
PartialSpecialization passes were removed. They were unmaintained,
buggy, or decided to be a bad idea.</li>
LoopIndexSplit pass was removed, unmaintained.
LiveValues, SimplifyHalfPowrLibCalls, and GEPSplitter were removed.
Removed the PartialSpecialization pass, it was unmaintained and buggy.
DIFactory removed, use DIBuilder instead.
Triple::normalize is new, llvm triples are always stored in normalized form internally.
Triple x86_64--mingw64 is obsoleted. Use x86_64--mingw32 instead.
PointerTracking has been removed from mainline, moved to ClamAV.
</ul> </ul>
</div> </div>
@ -763,27 +743,18 @@ DIFactory is gone now.
LLVM API changes are:</p> LLVM API changes are:</p>
<ul> <ul>
<li>include/llvm/System merged into include/llvm/Support.</li>
include/llvm/System merged into include/llvm/Support. <li>The <a href="http://llvm.org/PR5207">llvm::APInt API</a> was significantly
cleaned up.</li>
APInt API changes, see PR5207.
MVT::Flag renamed to MVT::Glue
error_code + libsystem + PathV2 changes
The system_error header from C++0x was added.
* Use if (error_code ec = function()) to check for error conditions
from functions which return it.
* error_code::message returns a human readable description of the error.
PathV1 has been deprecated in favor of PathV2 (sorry I didn't finish
this before the release).
* No Path class, use a r-value convertible to a twine instead.
* Assumes all paths are UTF-8.
<li>In the code generator, MVT::Flag was renamed to MVT::Glue to more accurately
describe its behavior.</li>
<li>The system_error header from C++0x was added, and is now pervasively used to
capture and handle i/o and other errors in LLVM.</li>
<li>The old sys::Path API has been deprecated in favor of the new PathV2 API,
which is more efficient and flexible.</li>
</ul> </ul>
</div> </div>
@ -820,7 +791,7 @@ href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev list</a>.</p>
<li>The Alpha, Blackfin, CellSPU, MicroBlaze, MSP430, MIPS, PTX, SystemZ <li>The Alpha, Blackfin, CellSPU, MicroBlaze, MSP430, MIPS, PTX, SystemZ
and XCore backends are experimental.</li> and XCore backends are experimental.</li>
<li><tt>llc</tt> "<tt>-filetype=obj</tt>" is experimental on all targets <li><tt>llc</tt> "<tt>-filetype=obj</tt>" is experimental on all targets
other than darwin-i386 and darwin-x86_64. FIXME: Not true on ELF anymore?</li> other than darwin and ELF X86 systems.</li>
</ul> </ul>
@ -962,6 +933,8 @@ Depending on it for anything serious is not advised.</p>
<div class="doc_text"> <div class="doc_text">
<p><b>LLVM 2.9 will be the last release of llvm-gcc.</b></p>
<p>llvm-gcc is generally very stable for the C family of languages. The only <p>llvm-gcc is generally very stable for the C family of languages. The only
major language feature of GCC not supported by llvm-gcc is the major language feature of GCC not supported by llvm-gcc is the
<tt>__builtin_apply</tt> family of builtins. However, some extensions <tt>__builtin_apply</tt> family of builtins. However, some extensions