diff options
| author | Tanya Lattner <tonic@nondot.org> | 2007-09-27 04:52:22 +0000 |
|---|---|---|
| committer | Tanya Lattner <tonic@nondot.org> | 2007-09-27 04:52:22 +0000 |
| commit | e87e970ebe02fe71a80e0ae8b6adabeae836a31a (patch) | |
| tree | a7507c7a2bd3591371b1a1f3428352ca9ed69862 | |
| parent | f48c08a19317bd9ed3eebd509556697a768a0742 (diff) | |
Merge release notes from mainline.release_21
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_21@42386 91177308-0d34-0410-b5e6-96231b3b80d8
| -rw-r--r-- | docs/ReleaseNotes.html | 525 |
1 files changed, 177 insertions, 348 deletions
diff --git a/docs/ReleaseNotes.html b/docs/ReleaseNotes.html index 03d2db112f..917ca363a8 100644 --- a/docs/ReleaseNotes.html +++ b/docs/ReleaseNotes.html @@ -4,11 +4,11 @@ <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <link rel="stylesheet" href="llvm.css" type="text/css"> - <title>LLVM 2.0 Release Notes</title> + <title>LLVM 2.1 Release Notes</title> </head> <body> -<div class="doc_title">LLVM 2.0 Release Notes</div> +<div class="doc_title">LLVM 2.1 Release Notes</div> <ol> <li><a href="#intro">Introduction</a></li> @@ -32,7 +32,7 @@ <div class="doc_text"> <p>This document contains the release notes for the LLVM compiler -infrastructure, release 2.0. Here we describe the status of LLVM, including +infrastructure, release 2.1. Here we describe the status of LLVM, including major improvements from the previous release and any known problems. All LLVM releases may be downloaded from the <a href="http://llvm.org/releases/">LLVM releases web site</a>.</p> @@ -44,10 +44,9 @@ href="http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVM developer's mailing list</a> is a good place to send them.</p> <p>Note that if you are reading this file from a Subversion checkout or the -main LLVM web page, -this document applies to the <i>next</i> release, not the current one. To see -the release notes for the current or previous releases, see the <a -href="http://llvm.org/releases/">releases page</a>.</p> +main LLVM web page, this document applies to the <i>next</i> release, not the +current one. To see the release notes for a specific releases, please see the +<a href="http://llvm.org/releases/">releases page</a>.</p> </div> @@ -59,416 +58,235 @@ href="http://llvm.org/releases/">releases page</a>.</p> <div class="doc_text"> -<p>This is the eleventh public release of the LLVM Compiler Infrastructure. -Being the first major release since 1.0, this release is different in several -ways from our previous releases:</p> - -<ol> -<li>We took this as an opportunity to -break backwards compatibility with the LLVM 1.x bytecode and .ll file format. -If you have LLVM 1.9 .ll files that you would like to upgrade to LLVM 2.x, we -recommend the use of the stand alone <a href="#llvm-upgrade">llvm-upgrade</a> -tool (which is included with 2.0). We intend to keep compatibility with .ll -and .bc formats within the 2.x release series, like we did within the 1.x -series.</li> -<li>There are several significant change to the LLVM IR and internal APIs, such - as a major overhaul of the type system, the completely new bitcode file - format, etc (described below).</li> -<li>We designed the release around a 6 month release cycle instead of the usual - 3-month cycle. This gave us extra time to develop and test some of the - more invasive features in this release.</li> -<li>LLVM 2.0 no longer supports the llvm-gcc3 front-end. Users are required to - upgrade to llvm-gcc4. llvm-gcc4 includes many features over - llvm-gcc3, is faster, and is <a href="CFEBuildInstrs.html">much easier to - build from source</a>.</li> -</ol> - -<p>Note that while this is a major version bump, this release has been - extensively tested on a wide range of software. It is easy to say that this - is our best release yet, in terms of both features and correctness. This is - the first LLVM release to correctly compile and optimize major software like - LLVM itself, Mozilla/Seamonkey, Qt 4.3rc1, kOffice, etc out of the box on - linux/x86. - </p> +<p>This is the twelfth public release of the LLVM Compiler Infrastructure. +It includes many features and refinements from LLVM 2.0.</p> </div> <!--=========================================================================--> <div class="doc_subsection"> -<a name="newfeatures">New Features in LLVM 2.0</a> +<a name="frontends">New Frontends</a> </div> -<!--_________________________________________________________________________--> -<div class="doc_subsubsection"><a name="majorchanges">Major Changes</a></div> <div class="doc_text"> -<p>Changes to the LLVM IR itself:</p> +<p>LLVM 2.1 brings two new beta C front-ends. First, a new version of llvm-gcc +based on GCC 4.2, innovatively called "llvm-gcc-4.2". This promises to bring +FORTRAN and Ada support to LLVM as well as features like atomic builtins and +OpenMP. None of these actually work yet, but don't let that stop you checking +it out!</p> -<ul> +<p>Second, LLVM now includes its own native C and Objective-C front-end (C++ is +in progress, but is not very far along) code named "<a +href="http://clang.llvm.org/">clang</a>". This front-end has a number of great +features, primarily aimed at source-level analysis and speeding up compile-time. +At this point though, the LLVM Code Generator component is still very early in +development, so it's mostly useful for people looking to build source-level +analysis tools or source-to-source translators.</p> -<li>Integer types are now completely signless. This means that we - have types like i8/i16/i32 instead of ubyte/sbyte/short/ushort/int - etc. LLVM operations that depend on sign have been split up into - separate instructions (<a href="http://llvm.org/PR950">PR950</a>). This - eliminates cast instructions that just change the sign of the operands (e.g. - int -> uint), which reduces the size of the IR and makes optimizers - simpler to write.</li> - -<li>Integer types with arbitrary bitwidths (e.g. i13, i36, i42, i1057, etc) are - now supported in the LLVM IR and optimizations (<a - href="http://llvm.org/PR1043">PR1043</a>). However, neither llvm-gcc - (<a href="http://llvm.org/PR1284">PR1284</a>) nor the native code generators - (<a href="http://llvm.org/PR1270">PR1270</a>) support non-standard width - integers yet.</li> - -<li>'Type planes' have been removed (<a href="http://llvm.org/PR411">PR411</a>). - It is no longer possible to have two values with the same name in the - same symbol table. This simplifies LLVM internals, allowing significant - speedups.</li> - -<li>Global variables and functions in .ll files are now prefixed with - @ instead of % (<a href="http://llvm.org/PR645">PR645</a>).</li> - -<li>The LLVM 1.x "bytecode" format has been replaced with a - completely new binary representation, named 'bitcode'. The <a - href="BitCodeFormat.html">Bitcode Format</a> brings a - number of advantages to the LLVM over the old bytecode format: it is denser - (files are smaller), more extensible, requires less memory to read, - is easier to keep backwards compatible (so LLVM 2.5 will read 2.0 .bc - files), and has many other nice features.</li> - -<li>Load and store instructions now track the alignment of their pointer - (<a href="http://www.llvm.org/PR400">PR400</a>). This allows the IR to - express loads that are not sufficiently aligned (e.g. due to '<tt>#pragma - packed</tt>') or to capture extra alignment information.</li> -</ul> +</div> -<p>Major new features:</p> +<!--=========================================================================--> +<div class="doc_subsection"> +<a name="optimizer">Optimizer Improvements</a> +</div> -<ul> +<div class="doc_text"> + +<p>Some of the most noticable feature improvements this release have been in the +optimizer, speeding it up and making it more aggressive. For example:</p> -<li>A number of ELF features are now supported by LLVM, including 'visibility', - extern weak linkage, Thread Local Storage (TLS) with the <tt>__thread</tt> - keyword, and symbol aliases. - Among other things, this means that many of the special options needed to - configure llvm-gcc on linux are no longer needed, and special hacks to build - large C++ libraries like Qt are not needed.</li> +<ul> -<li>LLVM now has a new MSIL backend. <tt>llc -march=msil</tt> will now turn LLVM - into MSIL (".net") bytecode. This is still fairly early development - with a number of limitations.</li> +<li>Owen Anderson wrote the new MemoryDependenceAnalysis pass, which provides + a lazy, caching layer on top of <a + href="AliasAnalysis.html">AliasAnalysis</a>. He then used it to rewrite + DeadStoreElimination which resulted in significantly better compile time in + common cases, </li> +<li>Owen implemented the new GVN pass, which is also based on + MemoryDependenceAnalysis. This pass replaces GCSE/LoadVN in the standard + set of passes, providing more aggressive optimization at a some-what + improved compile-time cost.</li> +<li>Owen implemented GVN-PRE, a partial redundancy elimination algorithm that + shares some details with the new GVN pass. It is still in need of compile + time tuning, and is not turned on by default.</li> +<li>Devang merged ETForest and DomTree into a single easier to use data + structure. This makes it more obvious which datastructure to choose + (because there is only one) and makes the compiler more memory and time + efficient (less stuff to keep up-to-date).</li> +<li>Nick Lewycky improved loop trip count analysis to handle many more common + cases.</li> -<li>A new <a href="CommandGuide/html/llvm-upgrade.html">llvm-upgrade</a> tool - exists to migrates LLVM 1.9 .ll files to LLVM 2.0 syntax.</li> </ul> </div> +<!--=========================================================================--> +<div class="doc_subsection"> +<a name="codegen">Code Generator Improvements</a> +</div> -<!--_________________________________________________________________________--> -<div class="doc_subsubsection"><a name="llvmgccfeatures">llvm-gcc -Improvements</a></div> <div class="doc_text"> -<p>New features include: -</p> + +<p>One of the main focuses of this release was performance tuning and bug + fixing. In addition to these, several new major changes occurred:</p> <ul> -<li>Precompiled Headers (PCH) are now supported.</li> -<li>"<tt>#pragma packed</tt>" is now supported, as are the various features - described above (visibility, extern weak linkage, __thread, aliases, - etc).</li> +<li>Dale finished up the Tail Merging optimization in the code generator, and + enabled it by default. This produces smaller code that is also faster in + some cases.</li> -<li>Tracking function parameter/result attributes is now possible.</li> +<li>Christopher Lamb implemented support for virtual register sub-registers, + which can be used to better model many forms of subregisters. As an example + use, he modified the X86 backend to use this to model truncates and + extends more accurately (leading to better code).</li> -<li>Many internal enhancements have been added, such as improvements to - NON_LVALUE_EXPR, arrays with non-zero base, structs with variable sized - fields, VIEW_CONVERT_EXPR, CEIL_DIV_EXPR, nested functions, and many other - things. This is primarily to supports non-C GCC front-ends, like Ada.</li> +<li>Dan Gohman changed the way we represent vectors before legalization, + significantly simplifying the SelectionDAG representation for these and + making the code generator faster for vector code.</li> -<li>It is simpler to configure llvm-gcc for linux.</li> +<li>Evan contributed a new target independent if-converter. While it is + target independent, so far only the ARM backend uses it.</li> -</ul> - -</div> +<li>Evan rewrite the way the register allocator handles rematerialization, + allowing it to be much more effective on two-address targets like X86, + and taught it to fold loads away when possible (also a big win on X86).</li> -<!--_________________________________________________________________________--> -<div class="doc_subsubsection"><a name="optimizer">Optimizer -Improvements</a></div> +<li>Dan Gohman contributed support for better alignment and volatility handling + in the code generator, and significantly enhanced alignment analysis for SSE + load/store instructions. With his changes, an insufficiently-aligned SSE + load instruction turns into <tt>movups</tt>, for example.</li> -<div class="doc_text"> -<p>New features include: -</p> +<li>Duraid Madina contributed a new "bigblock" register allocator, and Roman + Levenstein contributed several big improvements. BigBlock is optimized for + code that uses very large basic blocks. It is slightly slower than the + "local" allocator, but produces much better code.</li> -<ul> -<li>The <a href="WritingAnLLVMPass.html">pass manager</a> has been entirely - rewritten, making it significantly smaller, simpler, and more extensible. - Support has been added to run <tt>FunctionPass</tt>es interlaced with - <tt>CallGraphSCCPass</tt>es, we now support loop transformations - explicitly with <tt>LoopPass</tt>, and <tt>ModulePass</tt>es may now use the - result of <tt>FunctionPass</tt>es.</li> +<li>David Greene refactored the register allocator to split coalescing out from + allocation, making coalescers pluggable.</li> -<li>LLVM 2.0 includes a new loop rotation pass, which converts "for loops" into - "do/while loops", where the condition is at the bottom of the loop.</li> - -<li>The Loop Strength Reduction pass has been improved, and we now support - sinking expressions across blocks to reduce register pressure.</li> - -<li>The <tt>-scalarrepl</tt> pass can now promote unions containing FP values - into a register, it can also handle unions of vectors of the same - size.</li> - -<li>The [Post]DominatorSet classes have been removed from LLVM and clients - switched to use the more-efficient ETForest class instead.</li> +</ul> -<li>The ImmediateDominator class has also been removed, and clients have been - switched to use DominatorTree instead.</li> +</div> -<li>The predicate simplifier pass has been improved, making it able to do - simple value range propagation and eliminate more conditionals. However, - note that predsimplify is not enabled by default in llvm-gcc.</li> -</ul> - +<!--=========================================================================--> +<div class="doc_subsection"> +<a name="targetspecific">Target Specific Improvements</a> </div> -<!--_________________________________________________________________________--> -<div class="doc_subsubsection"><a name="codegen">Code -Generator Enhancements</a></div> - <div class="doc_text"> -<p> -New features include: +<p>New features include: </p> <ul> +<li>Bruno Cardoso Lopes contributed initial MIPS support. It is sufficient to + run many small programs, but is still incomplete and is not yet + fully performant.</li> + +<li>Bill Wendling added SSSE3 support to the X86 backend.</li> -<li>LLVM now supports software floating point, which allows LLVM to target - chips that don't have hardware FPUs (e.g. ARM thumb mode).</li> - -<li>A new register scavenger has been implemented, which is useful for - finding free registers after register allocation. This is useful when - rewriting frame references on RISC targets, for example.</li> - -<li>Heuristics have been added to avoid coalescing vregs with very large live - ranges to physregs. This was bad because it effectively pinned the physical - register for the entire lifetime of the virtual register (<a - href="http://llvm.org/PR711">PR711</a>).</li> - -<li>Support now exists for very simple (but still very useful) - rematerialization the register allocator, enough to move - instructions like "load immediate" and constant pool loads.</li> +<li>Nicholas Geoffray contributed improved linux/ppc ABI and JIT support.</li> -<li>Switch statement lowering is significantly better, improving codegen for - sparse switches that have dense subregions, and implemented support - for the shift/and trick.</li> +<li>Dale Johannesen rewrote handling of 32-bit float values in the X86 backend + when using the floating point stack, fixing several nasty bugs.</li> -<li>LLVM now supports tracking physreg sub-registers and super-registers - in the code generator, and includes extensive register - allocator changes to track them.</li> +<li>Dan contributed rematerialization support for the X86 backend, in addition + to several X86-specific micro optimizations.</li> +</ul> + +</div> -<li>There is initial support for virtreg sub-registers - (<a href="http://llvm.org/PR1350">PR1350</a>).</li> -</ul> +<!--=========================================================================--> +<div class="doc_subsection"> +<a name="llvmgccimprovements">llvm-gcc Improvements</a> +</div> -<p> -Other improvements include: +<div class="doc_text"> +<p>New features include: </p> <ul> +<li>Duncan and Anton made significant progress chasing down a number of problems + with C++ Zero-Cost exception handling in llvm-gcc 4.0 and 4.2. It is now at + the point where it "just works" on linux/X86-32 and has partial support on + other targets.</li> -<li>Inline assembly support is much more solid that before. - The two primary features still missing are support for 80-bit floating point - stack registers on X86 (<a href="http://llvm.org/PR879">PR879</a>), and - support for inline asm in the C backend (<a - href="http://llvm.org/PR802">PR802</a>).</li> - -<li>DWARF debug information generation has been improved. LLVM now passes - most of the GDB testsuite on MacOS and debug info is more dense.</li> +<li>Devang and Duncan fixed a huge number of bugs relating to bitfields, pragma + pack, and variable sized fields in structures.</li> -<li>Codegen support for Zero-cost DWARF exception handling has been added (<a - href="http://llvm.org/PR592">PR592</a>). It is mostly - complete and just in need of continued bug fixes and optimizations at - this point. However, support in llvm-g++ is disabled with an - #ifdef for the 2.0 release (<a - href="http://llvm.org/PR870">PR870</a>).</li> +<li>Tanya implemented support for <tt>__attribute__((noinline))</tt> in + llvm-gcc, and added support for generic variable annotations which are + propagated into the LLVM IR, e.g. + "<tt>int X __attribute__((annotate("myproperty")));</tt>".</li> -<li>The code generator now has more accurate and general hooks for - describing addressing modes ("isLegalAddressingMode") to - optimizations like loop strength reduction and code sinking.</li> +<li>Sheng Zhou and Christopher Lamb implemented alias analysis support for +"restrict" pointer arguments to functions.</li> -<li>Progress has been made on a direct Mach-o .o file writer. Many small - apps work, but it is still not quite complete.</li> +<li>Duncan contributed support for trampolines (taking the address of a nested + function). Currently this is only supported on the X86-32 target.</li> +<li>Lauro Ramos Venancio contributed support to encode alignment info in + load and store instructions, the foundation for other alignment-related + work.</li> </ul> + +</div> -<p>In addition, the LLVM target description format has itself been extended in - several ways:</p> - -<ul> -<li>TargetData now supports better target parameterization in - the .ll/.bc files, eliminating the 'pointersize/endianness' attributes - in the files (<a href="http://llvm.org/PR761">PR761</a>).</li> - -<li>TargetData was generalized for finer grained alignment handling, - handling of vector alignment, and handling of preferred alignment</li> - -<li>LLVM now supports describing target calling conventions - explicitly in .td files, reducing the amount of C++ code that needs - to be written for a port.</li> - -</ul> +<!--=========================================================================--> +<div class="doc_subsection"> +<a name="coreimprovements">LLVM Core Improvements</a> </div> -<!--_________________________________________________________________________--> -<div class="doc_subsubsection"><a name="specifictargets">Target-Specific -Improvements</a></div> - <div class="doc_text"> - -<p>X86-specific Code Generator Enhancements: +<p>New features include: </p> <ul> -<li>The MMX instruction set is now supported through intrinsics.</li> -<li>The scheduler was improved to better reduce register pressure on - X86 and other targets that are register pressure sensitive.</li> -<li>Linux/x86-64 support is much better.</li> -<li>PIC support for linux/x86 has been added.</li> -<li>The X86 backend now supports the GCC regparm attribute.</li> -<li>LLVM now supports inline asm with multiple constraint letters per operand - (like "mri") which is common in X86 inline asms.</li> -</ul> - -<p>ARM-specific Code Generator Enhancements:</p> - -<ul> -<li>The ARM code generator is now stable and fully supported.</li> - -<li>There are major new features, including support for ARM - v4-v6 chips, vfp support, soft float point support, pre/postinc support, - load/store multiple generation, constant pool entry motion (to support - large functions), inline asm support, weak linkage support, static - ctor/dtor support and many bug fixes.</li> +<li>Neil Booth contributed a new "APFloat" class, which ensures that floating + point representation and constant folding is not dependent on the host + architecture that builds the application. This support is the foundation + for "long double" support that will be wrapped up in LLVM 2.2.</li> -<li>Added support for Thumb code generation (<tt>llc -march=thumb</tt>).</li> +<li>Based on the APFloat class, Dale redesigned the internals of the ConstantFP + class and has been working on extending the core and optimizer components to + support various target-specific 'long double's. We expect this work to be + completed in LLVM 2.2.</li> -<li>The ARM backend now supports the ARM AAPCS/EABI ABI and PIC codegen on - arm/linux.</li> - -<li>Several bugs were fixed for DWARF debug info generation on arm/linux.</li> +<li>LLVM now provides an LLVMBuilder class, which makes it significantly easier + to create LLVM IR instructions.</li> +<li>Reid contributed support for intrinsics that take arbitrary integer typed + arguments. Dan Gohman and Chandler extended it to support arbitrary + floating point arguments and vectors.</li> </ul> - -<p>PowerPC-specific Code Generator Enhancements:</p> - -<ul> -<li>The PowerPC 64 JIT now supports addressing code loaded above the 2G - boundary.</li> - -<li>Improved support for the Linux/ppc ABI and the linux/ppc JIT is fully - functional now. llvm-gcc and static compilation are not fully supported - yet though.</li> - -<li>Many PowerPC 64 bug fixes.</li> - -</ul> - + </div> - -<!--_________________________________________________________________________--> -<div class="doc_subsubsection"><a name="other">Other Improvements</a></div> -<div class="doc_text"> - -<p>More specific changes include:</p> - -<ul> -<li>LLVM no longer relies on static destructors to shut itself down. Instead, - it lazily initializes itself and shuts down when <tt>llvm_shutdown()</tt> is - explicitly called.</li> - -<li>LLVM now has significantly fewer static constructors, reducing startup time. - </li> - -<li>Several classes have been refactored to reduce the amount of code that - gets linked into apps that use the JIT.</li> - -<li>Construction of intrinsic function declarations has been simplified.</li> - -<li>The gccas/gccld tools have been replaced with small shell scripts.</li> - -<li>Support has been added to llvm-test for running on low-memory - or slow machines (make SMALL_PROBLEM_SIZE=1).</li> - -</ul> +<!--=========================================================================--> +<div class="doc_subsection"> +<a name="otherimprovements">Other Improvements</a> </div> -<!--_________________________________________________________________________--> -<div class="doc_subsubsection"><a name="apichanges">API Changes</a></div> <div class="doc_text"> - -<p>LLVM 2.0 contains a revamp of the type system and several other significant -internal changes. If you are programming to the C++ API, be aware of the -following major changes:</p> +<p>New features include: +</p> <ul> -<li>Pass registration is slightly different in LLVM 2.0 (you now need an - <tt>intptr_t</tt> in your constructor), as explained in the <a - href="WritingAnLLVMPass.html#basiccode">Writing an LLVM Pass</a> - document.</li> - -<li><tt>ConstantBool</tt>, <tt>ConstantIntegral</tt> and <tt>ConstantInt</tt> - classes have been merged together, we now just have - <tt>ConstantInt</tt>.</li> - -<li><tt>Type::IntTy</tt>, <tt>Type::UIntTy</tt>, <tt>Type::SByteTy</tt>, ... are - replaced by <tt>Type::Int8Ty</tt>, <tt>Type::Int16Ty</tt>, etc. LLVM types - have always corresponded to fixed size types - (e.g. long was always 64-bits), but the type system no longer includes - information about the sign of the type. Also, the - <tt>Type::isPrimitiveType()</tt> method now returns false for integers.</li> - -<li>Several classes (<tt>CallInst</tt>, <tt>GetElementPtrInst</tt>, - <tt>ConstantArray</tt>, etc), that once took <tt>std::vector</tt> as - arguments now take ranges instead. For example, you can create a - <tt>GetElementPtrInst</tt> with code like: - - <pre> - Value *Ops[] = { Op1, Op2, Op3 }; - GEP = new GetElementPtrInst(BasePtr, Ops, 3); - </pre> - - This avoids creation of a temporary vector (and a call to malloc/free). If - you have an <tt>std::vector</tt>, use code like this: - <pre> - std::vector<Value*> Ops = ...; - GEP = new GetElementPtrInst(BasePtr, &Ops[0], Ops.size()); - </pre> - - </li> - -<li><tt>CastInst</tt> is now abstract and its functionality is split into - several parts, one for each of the <a href="LangRef.html#convertops">new - cast instructions</a>.</li> - -<li><tt>Instruction::getNext()/getPrev()</tt> are now private (along with - <tt>BasicBlock::getNext</tt>, etc), for efficiency reasons (they are now no - longer just simple pointers). Please use <tt>BasicBlock::iterator</tt>, etc - instead. -</li> - -<li><tt>Module::getNamedFunction()</tt> is now called - <tt>Module::getFunction()</tt>.</li> +<li>Sterling Stein contributed a new BrainF frontend, located in llvm/examples. + This shows a some of the more modern APIs for building a front-end, and + demonstrates JIT compiler support.</li> -<li><tt>SymbolTable.h</tt> has been split into <tt>ValueSymbolTable.h</tt> and -<tt>TypeSymbolTable.h</tt>.</li> +<li>David Green contributed a new <tt>--enable-expensive-checks</tt> configure + option which enables STL checking, and fixed several bugs exposed by + it.</li> </ul> + </div> - <!-- *********************************************************************** --> <div class="doc_section"> <a name="portability">Portability and Supported Platforms</a> @@ -530,12 +348,11 @@ useful to some people. In particular, if you would like to work on one of these components, please contact us on the <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev list</a>.</p> <ul> -<li>The <tt>-cee</tt> pass is known to be buggy, and may be removed in in a +<li>The <tt>-cee</tt> pass is known to be buggy, and may be removed in a future release.</li> -<li>C++ EH support is disabled for this release.</li> <li>The MSIL backend is experimental.</li> <li>The IA64 code generator is experimental.</li> -<li>The Alpha JIT is experimental.</li> +<li>The Alpha backend is experimental.</li> <li>"<tt>-filetype=asm</tt>" (the default) is the only supported value for the <tt>-filetype</tt> llc option.</li> </ul> @@ -552,6 +369,9 @@ components, please contact us on the <a href="http://lists.cs.uiuc.edu/mailman/l <ul> <li>The X86 backend does not yet support <a href="http://llvm.org/PR879">inline assembly that uses the X86 floating point stack</a>.</li> +<li>The X86 backend occasionally has <a href="http://llvm.org/PR1649">alignment + problems</a> on operating systems that don't require 16-byte stack alignment + (including most non-darwin OS's like linux).</li> </ul> </div> @@ -581,7 +401,7 @@ compilation, and lacks support for debug information.</li> <ul> <li>Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6 -processors, thumb program can crash or produces wrong +processors, thumb programs can crash or produce wrong results (<a href="http://llvm.org/PR1388">PR1388</a>).</li> <li>Compilation for ARM Linux OABI (old ABI) is supported, but not fully tested. </li> @@ -661,6 +481,11 @@ programs.</li> <ul> <li><a href="http://llvm.org/PR802">The C backend does not support inline assembly code</a>.</li> +<li><a href="http://llvm.org/PR1126">The C backend does not support vectors + yet</a>.</li> +<li><a href="http://llvm.org/PR1658">The C backend violates the ABI of common + C++ programs</a>, preventing intermixing between C++ compiled by the CBE and + C++ code compiled with LLC or native compilers.</li> </ul> </div> @@ -700,9 +525,12 @@ bits.</p></li> <li><p>llvm-gcc <b>partially</b> supports these GCC extensions:</p> <ol> - <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html#Nested%20Functions">Nested Functions</a>: As in Algol and Pascal, lexical scoping of functions.<br> - Nested functions are supported, but llvm-gcc does not support non-local - gotos or taking the address of a nested function.</li> + <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html#Nested%20Functions">Nested Functions</a>: + + As in Algol and Pascal, lexical scoping of functions. + Nested functions are supported, but llvm-gcc does not support + taking the address of a nested function (except on the X86-32 target) + or non-local gotos.</li> <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function%20Attributes">Function Attributes</a>: @@ -712,11 +540,11 @@ bits.</p></li> <b>Supported:</b> <tt>alias</tt>, <tt>always_inline</tt>, <tt>cdecl</tt>, <tt>constructor</tt>, <tt>destructor</tt>, <tt>deprecated</tt>, <tt>fastcall</tt>, <tt>format</tt>, - <tt>format_arg</tt>, <tt>non_null</tt>, <tt>noreturn</tt>, <tt>regparm</tt> + <tt>format_arg</tt>, <tt>non_null</tt>, <tt>noinline</tt>, <tt>noreturn</tt>, <tt>regparm</tt> <tt>section</tt>, <tt>stdcall</tt>, <tt>unused</tt>, <tt>used</tt>, <tt>visibility</tt>, <tt>warn_unused_result</tt>, <tt>weak</tt><br> - <b>Ignored:</b> <tt>noinline</tt>, <tt>pure</tt>, <tt>const</tt>, <tt>nothrow</tt>, + <b>Ignored:</b> <tt>pure</tt>, <tt>const</tt>, <tt>nothrow</tt>, <tt>malloc</tt>, <tt>no_instrument_function</tt></li> </ol> </li> @@ -794,8 +622,9 @@ tested and works for a number of non-trivial programs, including LLVM itself, Qt, Mozilla, etc.</p> <ul> -<li>llvm-gcc4 only has partial support for <a href="http://llvm.org/PR870">C++ -Exception Handling</a>, and it is not enabled by default.</li> +<li>Exception handling only works well on the linux/X86-32 target. +In some cases, illegally throwing an exception does not result +in a call to terminate.</li> <!-- NO EH Support! |