RPCSX/llvm
1
0
Fork 0
mirror of https://github.com/RPCSX/llvm.git synced 2024-11-29 22:50:47 +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">
<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
via the x86 segment registers. A segment override prefix byte on an
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>
</div>
<!--
<h1 style="color:red">These are in-progress notes for the upcoming LLVM 2.9
release.<br>
You may prefer the
<a href="http://llvm.org/releases/2.8/docs/ReleaseNotes.html">LLVM 2.8
Release Notes</a>.</h1>
-->
<!-- *********************************************************************** -->
<h1>
@ -579,35 +581,34 @@ infrastructure, which allows us to implement more aggressive algorithms and make
it run faster:</p>
<ul>
<!-- SplitKit -->
<li>The pre-register-allocation (preRA) instruction scheduler models register
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>
LiveDebugVariables is a new pass that keeps track of debugging information for
user variables that are kept in registers in optimized builds.
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>LiveDebugVariables is a new pass that keeps track of debugging information
for user variables that are promoted to registers in optimized builds.</li>
<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>
</div>
@ -621,31 +622,31 @@ Major regalloc rewrite, not on by default for 2.9 and not advised to use it.
</p>
<ul>
<li>
X86: Reimplemented all of MMX to introduce a new LLVM IR x86_mmx type. Now
random types like &lt;2 x i32&gt; are not iseld to mmx without emms. The
-disable-mmx flag is gone now.
<li>LLVM 2.9 includes a complete reimplementation of the MMX instruction set.
The reimplementation uses a new LLVM IR <a
href="LangRef.html#t_x86mmx">x86_mmx</a> type to ensure that MMX operations
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>
X86 support for FS/GS relative loads and stores using address space 256/257 are
reliable now.
</li>
<li>X86 support for FS/GS relative loads and stores using <a
href="CodeGenerator.html#x86_memory">address space 256/257</a> work reliably
now.</li>
<li>
X86: Much better codegen for several cases using adc/sbb instead of cmovs for
conditional increment and other idioms.
</li>
<li>LLVM 2.9 generates much better code in several cases by using adc/sbb to
avoid generation of conditional move instructions for conditional increment
and other idioms.</li>
<li>
The X86 backend has adopted a new preRA scheduling
mode, "list-ilp", to shorten the height of instruction schedules
without inducing register spills.
</li>
<li>The X86 backend has adopted a new preRA scheduling mode, "list-ilp", to
shorten the height of instruction schedules 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>
</div>
@ -660,17 +661,17 @@ X86: Much better codegen for several cases using adc/sbb instead of cmovs for
</p>
<ul>
<li>ARM Fast ISel</li>
<li>ARM: New code placement pass.</li>
<li>ARM: Improved code generation for Cortex-A8 and Cortex-A9 CPUs.</li>
<li>ARM: __builtin_prefetch turns into prefetch instructions.</li>
<li>Countless ARM microoptimizations.</li>
<li>The ARM backend now has a fast instruction selector, which dramatically
improves -O0 compile times.</li>
<li>The ARM backend has new tuning for Cortex-A8 and Cortex-A9 CPUs.</li>
<li>The __builtin_prefetch builtin (and llvm.prefetch intrinsic) is compiled
into prefetch instructions instead of being discarded.</li>
<li> The ARM backend preRA scheduler now models machine resources at cycle
granularity. This allows the scheduler to both accurately model
instruction latency and avoid overcommitting functional units.</li>
<li>Countless ARM microoptimizations have landed in LLVM 2.9.</li>
</ul>
</div>
@ -681,15 +682,16 @@ X86: Much better codegen for several cases using adc/sbb instead of cmovs for
<div class="doc_text">
<ul>
PPC: Switched to MCInstPrinter, and MCCodeEmitter. Ready to implement support
for directly writing out mach-o object files, but noone seems interested.
MicroBlaze: major updates for aggressive delay slot filler, MC-based assembly
printing, assembly instruction parsing, ELF .o file emission, and MC
instruction disassembler.
SPARC: Many improvements, including using the Y registers for multiplications
and addition of a simple delay slot filler.
<li>MicroBlaze: major updates for aggressive delay slot filler, MC-based
assembly printing, assembly instruction parsing, ELF .o file emission, and MC
instruction disassembler have landed.</li>
<li>SPARC: Many improvements, including using the Y registers for
multiplications and addition of a simple delay slot filler.</li>
<li>PowerPC: The backend has been largely MC'ized and is ready to support
directly writing out mach-o object files. Noone seems interested in finishing
this final step though.</li>
</ul>
</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>
<ul>
last release for llvm-gcc
<li><b>This is the last release to support the llvm-gcc frontend.</b></li>
<li>
New naming rules in coding standards: CodingStandards.html#ll_naming
</li>
<li>LLVM has a new <a href="CodingStandards.html#ll_naming">naming
convention standard</a>, though the codebase hasn't fully adopted it yet.</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>
- DIBuilder provides simpler interface for front ends like Clang to encode debug info in LLVM IR.
- 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;
Ty = DebugFactory.CreateDerivedType(DW_TAG_volatile_type,
findRegion(TYPE_CONTEXT(type)),
StringRef(),
getOrCreateFile(main_input_filename),
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>LLVM IR and other tools always work on normalized target triples (which have
been run through <tt>Triple::normalize</tt>).</li>
<li>The target triple x86_64--mingw64 is obsoleted. Use x86_64--mingw32
instead.</li>
<li>The PointerTracking pass has been removed from mainline, and moved to The
ClamAV project (its only client).</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.
<li>The LoopIndexSplit, LiveValues, SimplifyHalfPowrLibCalls, GEPSplitter, and
PartialSpecialization passes were removed. They were unmaintained,
buggy, or decided to be a bad idea.</li>
</ul>
</div>
@ -763,27 +743,18 @@ DIFactory is gone now.
LLVM API changes are:</p>
<ul>
include/llvm/System merged into include/llvm/Support.
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>include/llvm/System merged into include/llvm/Support.</li>
<li>The <a href="http://llvm.org/PR5207">llvm::APInt API</a> was significantly
cleaned up.</li>
<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>
</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
and XCore backends are experimental.</li>
<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>
@ -962,6 +933,8 @@ Depending on it for anything serious is not advised.</p>
<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
major language feature of GCC not supported by llvm-gcc is the
<tt>__builtin_apply</tt> family of builtins. However, some extensions