[llvm-commits] [llvm] r128992 - in /llvm/trunk/docs: CodeGenerator.html ReleaseNotes.html
Chris Lattner
sabre at nondot.org
Tue Apr 5 23:29:51 PDT 2011
Author: lattner
Date: Wed Apr 6 01:29:50 2011
New Revision: 128992
URL: http://llvm.org/viewvc/llvm-project?rev=128992&view=rev
Log:
Finish up the first draft of the release notes.
improvements are welcome, please commit any changes directly to SVN.
Modified:
llvm/trunk/docs/CodeGenerator.html
llvm/trunk/docs/ReleaseNotes.html
Modified: llvm/trunk/docs/CodeGenerator.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/CodeGenerator.html?rev=128992&r1=128991&r2=128992&view=diff
==============================================================================
--- llvm/trunk/docs/CodeGenerator.html (original)
+++ llvm/trunk/docs/CodeGenerator.html Wed Apr 6 01:29:50 2011
@@ -2532,7 +2532,7 @@
<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
Modified: llvm/trunk/docs/ReleaseNotes.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=128992&r1=128991&r2=128992&view=diff
==============================================================================
--- llvm/trunk/docs/ReleaseNotes.html (original)
+++ llvm/trunk/docs/ReleaseNotes.html Wed Apr 6 01:29:50 2011
@@ -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 @@
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 @@
</p>
<ul>
-<li>
-X86: Reimplemented all of MMX to introduce a new LLVM IR x86_mmx type. Now
- random types like <2 x i32> 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 <2 x i32> 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: Much better codegen for several cases using adc/sbb instead of cmovs 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>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>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>
- 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 @@
</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 @@
<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 @@
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>
-
-
- 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 PointerTracking pass has been removed from mainline, and moved to The
+ ClamAV project (its only client).</li>
+
+<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 @@
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 @@
<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 @@
<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
More information about the llvm-commits
mailing list