<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.7 Release Notes</title>
</head>
<body>
-<div class="doc_title">LLVM 2.0 Release Notes</div>
-
+<div class="doc_title">LLVM 2.7 Release Notes</div>
+
<ol>
<li><a href="#intro">Introduction</a></li>
- <li><a href="#whatsnew">What's New?</a></li>
+ <li><a href="#subproj">Sub-project Status Update</a></li>
+ <li><a href="#externalproj">External Projects Using LLVM 2.7</a></li>
+ <li><a href="#whatsnew">What's New in LLVM 2.7?</a></li>
<li><a href="GettingStarted.html">Installation Instructions</a></li>
<li><a href="#portability">Portability and Supported Platforms</a></li>
- <li><a href="#knownproblems">Known Problems</a>
+ <li><a href="#knownproblems">Known Problems</a></li>
<li><a href="#additionalinfo">Additional Information</a></li>
</ol>
<div class="doc_author">
- <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>
+<h1 style="color:red">These are in-progress notes for the upcoming LLVM 2.7
+release.<br>
+You may prefer the
+<a href="http://llvm.org/releases/2.6/docs/ReleaseNotes.html">LLVM 2.6
+Release Notes</a>.</h1>
+
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="intro">Introduction</a>
<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 any
-known problems and major improvements from the previous release. All LLVM
-releases may be downloaded from the <a href="http://llvm.org/releases/">LLVM
-releases web site</a>.
+<p>This document contains the release notes for the LLVM Compiler
+Infrastructure, release 2.7. Here we describe the status of LLVM, including
+major improvements from the previous release and significant known problems.
+All LLVM releases may be downloaded from the <a
+href="http://llvm.org/releases/">LLVM releases web site</a>.</p>
<p>For more information about LLVM, including information about the latest
release, please check out the <a href="http://llvm.org/">main LLVM
web site</a>. If you have questions or comments, the <a
-href="http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVM developer's mailing
-list</a> is a good place to send them.</p>
+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 CVS 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>
+<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 a specific release, please see the
+<a href="http://llvm.org/releases/">releases page</a>.</p>
</div>
+
+
+<!--
+Almost dead code.
+ include/llvm/Analysis/LiveValues.h => Dan
+ lib/Transforms/IPO/MergeFunctions.cpp => consider for 2.8.
+ llvm/Analysis/PointerTracking.h => Edwin wants this, consider for 2.8.
+ ABCD, SCCVN, GEPSplitterPass
+ MSIL backend?
+ AndersAA -> Unsupported, zap after branch.
+-->
+
+
+<!-- Features that need text if they're finished for 2.7:
+ gcc plugin.
+ strong phi elim
+ variable debug info for optimized code
+ postalloc scheduler: anti dependence breaking, hazard recognizer?
+ metadata
+ loop dependence analysis
+ ELF Writer? How stable?
+ <li>PostRA scheduler improvements, ARM adoption (David Goodwin).</li>
+ 2.7 supports the GDB 7.0 jit interfaces for debug info.
+ 2.7 eliminates ADT/iterator.h
+ -->
+
+ <!-- for announcement email:
+ Logo web page.
+ llvm devmtg
+ compiler_rt
+ KLEE web page at klee.llvm.org
+ Many new papers added to /pubs/
+ Mention gcc plugin.
+
+ -->
<!-- *********************************************************************** -->
<div class="doc_section">
- <a name="whatsnew">What's New?</a>
+ <a name="subproj">Sub-project Status Update</a>
</div>
<!-- *********************************************************************** -->
<div class="doc_text">
+<p>
+The LLVM 2.7 distribution currently consists of code from the core LLVM
+repository (which roughly includes the LLVM optimizers, code generators
+and supporting tools), the Clang repository and the llvm-gcc repository. In
+addition to this code, the LLVM Project includes other sub-projects that are in
+development. Here we include updates on these subprojects.
+</p>
-<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>
+</div>
-<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.</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.</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.</p>
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="clang">Clang: C/C++/Objective-C Frontend Toolkit</a>
+</div>
+
+<div class="doc_text">
+<p>The <a href="http://clang.llvm.org/">Clang project</a> is ...</p>
+
+<p>In the LLVM 2.7 time-frame, the Clang team has made many improvements:</p>
+
+<ul>
+<li>...</li>
+</ul>
</div>
<!--=========================================================================-->
<div class="doc_subsection">
-<a name="newfeatures">New Features in LLVM 2.0</a>
+<a name="clangsa">Clang Static Analyzer</a>
</div>
-<!--_________________________________________________________________________-->
-<div class="doc_subsubsection"><a name="majorchanges">Major Changes</a></div>
<div class="doc_text">
-<p>blah
-</p>
+
+<p>Previously announced in the 2.4, 2.5, and 2.6 LLVM releases, the Clang project also
+includes an early stage static source code analysis tool for <a
+href="http://clang.llvm.org/StaticAnalysis.html">automatically finding bugs</a>
+in C and Objective-C programs. The tool performs checks to find
+bugs that occur on a specific path within a program.</p>
+
+<p>In the LLVM 2.7 time-frame, the analyzer core has ...</p>
+
+</div>
+
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="vmkit">VMKit: JVM/CLI Virtual Machine Implementation</a>
+</div>
+
+<div class="doc_text">
+<p>
+The <a href="http://vmkit.llvm.org/">VMKit project</a> is an implementation of
+a JVM and a CLI Virtual Machine (Microsoft .NET is an
+implementation of the CLI) using LLVM for static and just-in-time
+compilation.</p>
+
+<p>
+VMKit version ?? builds with LLVM 2.7 and you can find it on its
+<a href="http://vmkit.llvm.org/releases/">web page</a>. The release includes
+bug fixes, cleanup and new features. The major changes are:</p>
<ul>
-<li>llvm-gcc3 is now officially unsupported. Users are required to
- upgrade to llvm-gcc4. llvm-gcc4 includes many features over
- llvm-gcc3, is faster, and is much easier to build.</li>
+<li>...</li>
-<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>).</li>
+</ul>
+</div>
-<li>Arbitrary bitwidth integers (e.g. i13, i36, i42, etc) are now
- supported in the LLVM IR and optimizations. However, neither llvm-gcc nor
- the native code generators support non-standard width integers
- (<a href="http://llvm.org/PR1043">PR1043</a>).</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>
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="compiler-rt">compiler-rt: Compiler Runtime Library</a>
+</div>
-<li>Global variables and functions in .ll files are now prefixed with
- @ instead of % (<a href="http://llvm.org/PR645">PR645</a>).</li>
+<div class="doc_text">
+<p>
+The new LLVM <a href="http://compiler-rt.llvm.org/">compiler-rt project</a>
+is a simple library that provides an implementation of the low-level
+target-specific hooks required by code generation and other runtime components.
+For example, when compiling for a 32-bit target, converting a double to a 64-bit
+unsigned integer is compiled into a runtime call to the "__fixunsdfdi"
+function. The compiler-rt library provides highly optimized implementations of
+this and other low-level routines (some are 3x faster than the equivalent
+libgcc routines).</p>
-<li>The LLVM 1.x "bytecode" format has been replaced with a
- completely new binary representation, named 'bitcode'. Because we
- plan to maintain binary compatibility between LLVM 2.x ".bc" files,
- this is an important change to get right. Bitcode 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>
+<p>
+All of the code in the compiler-rt project is available under the standard LLVM
+License, a "BSD-style" license.</p>
-<li>Support was added for alignment values on load and store
- instructions (<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 pragma packed) or to capture extra
- alignment information. </li>
+</div>
-<li>LLVM now has a new MSIL backend. llc - march=msil will now turn LLVM
- into MSIL (".net") bytecode. This is still fairly early development
- with a number of limitations.</li>
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="klee">KLEE: Symbolic Execution and Automatic Test Case Generator</a>
+</div>
-<li>Support has been added for 'protected visibility' in ELF.</li>
+<div class="doc_text">
+<p>
+The new LLVM <a href="http://klee.llvm.org/">KLEE project</a> is a symbolic
+execution framework for programs in LLVM bitcode form. KLEE tries to
+symbolically evaluate "all" paths through the application and records state
+transitions that lead to fault states. This allows it to construct testcases
+that lead to faults and can even be used to verify algorithms. For more
+details, please see the <a
+href="http://llvm.org/pubs/2008-12-OSDI-KLEE.html">OSDI 2008 paper</a> about
+KLEE.</p>
-<li>Thread Local Storage with the __thread keyword was implemented along
- with added codegen support for Linux on X86 and ARM.</li>
+</div>
-<li>ELF symbol aliases supported has been added.</li>
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="dragonegg">DragonEgg: GCC-4.5 as an LLVM frontend</a>
+</div>
-<li>Added support for 'polymorphic intrinsics', allowing things like
- llvm.ctpop to work on arbitrary width integers.</li>
+<div class="doc_text">
+<p>
+The goal of <a href="http://dragonegg.llvm.org/">DragonEgg</a> is to make
+gcc-4.5 act like llvm-gcc without requiring any gcc modifications whatsoever.
+<a href="http://dragonegg.llvm.org/">DragonEgg</a> is a shared library (dragonegg.so)
+that is loaded by gcc at runtime. It ...
+</p>
-</ul>
-
</div>
-<!--_________________________________________________________________________-->
-<div class="doc_subsubsection"><a name="llvmgccfeatures">llvm-gcc
-Improvements</a></div>
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="mc">llvm-mc: Machine Code Toolkit</a>
+</div>
+
<div class="doc_text">
-<p>New features include:
+<p>
+The LLVM Machine Code (MC) Toolkit project is ...
</p>
-<ul>
-<li>Precompiled Headers (PCH) support has been implemented.</li>
+</div>
+
+
+<!-- *********************************************************************** -->
+<div class="doc_section">
+ <a name="externalproj">External Open Source Projects Using LLVM 2.7</a>
+</div>
+<!-- *********************************************************************** -->
-<li>Support for external weak linkage and hidden visibility has been added.</li>
+<div class="doc_text">
+
+<p>An exciting aspect of LLVM is that it is used as an enabling technology for
+ a lot of other language and tools projects. This section lists some of the
+ projects that have already been updated to work with LLVM 2.7.</p>
+</div>
-<li>Packed structure types are now supported , which allows LLVM to express
- unaligned data more naturally.</li>
-<li>Inline assembly support has been improved and many bugs were fixed.
- The two large missing features 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>
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="Rubinius">Rubinius</a>
+</div>
+
+<div class="doc_text">
+<p><a href="http://github.com/evanphx/rubinius">Rubinius</a> is an environment
+for running Ruby code which strives to write as much of the core class
+implementation in Ruby as possible. Combined with a bytecode interpreting VM, it
+uses LLVM to optimize and compile ruby code down to machine code. Techniques
+such as type feedback, method inlining, and uncommon traps are all used to
+remove dynamism from ruby execution and increase performance.</p>
+
+<p>Since LLVM 2.5, Rubinius has made several major leaps forward, implementing
+a counter based JIT, type feedback and speculative method inlining.
+</p>
-<li>Ada support, such as nested functions, has been improved.</li>
+</div>
-<li>Tracking function parameter/result attributes is now possible.</li>
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="macruby">MacRuby</a>
+</div>
-<li>Its is now easier to configure llvm-gcc for linux.</li>
+<div class="doc_text">
-<li>Many 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, and many other things.</li>
+<p>
+<a href="http://macruby.org">MacRuby</a> is an implementation of Ruby on top of
+core Mac OS X technologies, such as the Objective-C common runtime and garbage
+collector and the CoreFoundation framework. It is principally developed by
+Apple and aims at enabling the creation of full-fledged Mac OS X applications.
+</p>
-<li>Improved "attribute packed" support in the CFE, and handle many
- other obscure struct layout cases correctly.</li>
+<p>
+MacRuby uses LLVM for optimization passes, JIT and AOT compilation of Ruby
+expressions. It also uses zero-cost DWARF exceptions to implement Ruby exception
+handling.</p>
-</ul>
-
</div>
-<!--_________________________________________________________________________-->
-<div class="doc_subsubsection"><a name="optimizer">Optimizer
-Improvements</a></div>
+
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="pure">Pure</a>
+</div>
+
<div class="doc_text">
-<p>New features include:
+<p>
+<a href="http://pure-lang.googlecode.com/">Pure</a>
+is an algebraic/functional programming language based on term rewriting.
+Programs are collections of equations which are used to evaluate expressions in
+a symbolic fashion. Pure offers dynamic typing, eager and lazy evaluation,
+lexical closures, a hygienic macro system (also based on term rewriting),
+built-in list and matrix support (including list and matrix comprehensions) and
+an easy-to-use C interface. The interpreter uses LLVM as a backend to
+ JIT-compile Pure programs to fast native code.</p>
+
+<p>Pure versions ??? and later have been tested and are known to work with
+LLVM 2.7 (and continue to work with older LLVM releases >= 2.3 as well).
</p>
+</div>
-<ul>
-<li>The pass manager has been entirely rewritten, making it significantly
- smaller, simpler, and more extensible. Support has been added to run
- FunctionPasses interlaced with CallGraphSCCPasses.</li>
-<li>The -scalarrepl pass can now promote unions containing FP values into
- a register, it can also handle unions of vectors of the same size.</li>
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="ldc">LLVM D Compiler</a>
+</div>
-<li>The predicate simplifier pass has been improved, making it able to do
- simple value range propagation and eliminate more conditionals.</li>
+<div class="doc_text">
+<p>
+<a href="http://www.dsource.org/projects/ldc">LDC</a> is an implementation of
+the D Programming Language using the LLVM optimizer and code generator.
+The LDC project works great with the LLVM 2.6 release. General improvements in
+this
+cycle have included new inline asm constraint handling, better debug info
+support, general bug fixes and better x86-64 support. This has allowed
+some major improvements in LDC, getting it much closer to being as
+fully featured as the original DMD compiler from DigitalMars.
+</p>
+</div>
-<li>There is a new new LoopPass class. The passmanager has been
- modified to support it, and all existing loop xforms have been
- converted to use it. </li>
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="RoadsendPHP">Roadsend PHP</a>
+</div>
-<li>There is a new loop rotation pass, which converts "for loops" into
- "do/while loops", where the condition is at the bottom of the loop.</li>
+<div class="doc_text">
+<p>
+<a href="http://code.roadsend.com/rphp">Roadsend PHP</a> (rphp) is an open
+source implementation of the PHP programming
+language that uses LLVM for its optimizer, JIT and static compiler. This is a
+reimplementation of an earlier project that is now based on LLVM.</p>
+</div>
-<li>ModulePasses may now use the result of FunctionPasses.</li>
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="UnladenSwallow">Unladen Swallow</a>
+</div>
-<li>The [Post]DominatorSet classes have been removed from LLVM and clients switched to use the far-more-efficient ETForest class instead. </li>
+<div class="doc_text">
+<p>
+<a href="http://code.google.com/p/unladen-swallow/">Unladen Swallow</a> is a
+branch of <a href="http://python.org/">Python</a> intended to be fully
+compatible and significantly faster. It uses LLVM's optimization passes and JIT
+compiler.</p>
+</div>
-<li>The ImmediateDominator class has also been removed, and clients have been switched to use DominatorTree instead.</li>
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="llvm-lua">llvm-lua</a>
+</div>
-</ul>
-
+<div class="doc_text">
+<p>
+<a href="http://code.google.com/p/llvm-lua/">LLVM-Lua</a> uses LLVM to add JIT
+and static compiling support to the Lua VM. Lua bytecode is analyzed to
+remove type checks, then LLVM is used to compile the bytecode down to machine
+code.</p>
</div>
-<!--_________________________________________________________________________-->
-<div class="doc_subsubsection"><a name="codegen">Code
-Generator Enhancements</a></div>
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="icedtea">IcedTea Java Virtual Machine Implementation</a>
+</div>
<div class="doc_text">
<p>
-New features include:
+<a href="http://icedtea.classpath.org/wiki/Main_Page">IcedTea</a> provides a
+harness to build OpenJDK using only free software build tools and to provide
+replacements for the not-yet free parts of OpenJDK. One of the extensions that
+IcedTea provides is a new JIT compiler named <a
+href="http://icedtea.classpath.org/wiki/ZeroSharkFaq">Shark</a> which uses LLVM
+to provide native code generation without introducing processor-dependent
+code.
</p>
+</div>
-<ul>
-<li>Support for Zero-cost DWARF exception handling has been added. It is mostly
- complete and just in need of continued bug fixes and optimizations at
- this point.</li>
-<li>Progress has been made on a direct Mach-o .o file writer. Many small
- apps work, but it is not quite complete yet.</li>
-<li>Support was added for software floating point routines.</li>
+<!-- *********************************************************************** -->
+<div class="doc_section">
+ <a name="whatsnew">What's New in LLVM 2.7?</a>
+</div>
+<!-- *********************************************************************** -->
-<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>
+<div class="doc_text">
-<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>
+<p>This release 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>
-<li>Heuristics have been added to avoid coalescing vregs with very large live
- ranges to physregs.</li>
+</div>
-<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>
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="majorfeatures">Major New Features</a>
+</div>
-<li>Significantly improved 'switch' lowering, improving codegen for
- sparse switches that have dense subregions, and implemented support
- for the shift/and trick.</li>
+<div class="doc_text">
-<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>
+<p>LLVM 2.7 includes several major new capabilities:</p>
-<li>The Loop Strength Reduction pass has been improved, and support added
- for sinking expressions across blocks to reduce register pressure.</li>
+<ul>
+<li>...</li>
+</ul>
-<li>Added support for tracking physreg sub-registers and super-registers
- in the code generator, as well as extensive register
- allocator changes to track them.</li>
+</div>
-<li>There is initial support for virtreg sub-registers
- (<a href="http://llvm.org/PR1350">PR1350</a>).</li>
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="coreimprovements">LLVM IR and Core Improvements</a>
+</div>
+
+<div class="doc_text">
+<p>LLVM IR has several new features for better support of new targets and that
+expose new optimization opportunities:</p>
+<ul>
+<li>...</li>
</ul>
-<p>In addition, the LLVM target description format has itself been extended in
- several ways:</p>
-
+</div>
+
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="optimizer">Optimizer Improvements</a>
+</div>
+
+<div class="doc_text">
+
+<p>In addition to a large array of minor performance tweaks and bug fixes, this
+release includes a few major enhancements and additions to the optimizers:</p>
+
<ul>
-<li>Extended TargetData to support 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>...</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>
+
+
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="executionengine">Interpreter and JIT Improvements</a>
+</div>
+
+<div class="doc_text">
+
+<ul>
+<li>The JIT now <a
+href="http://llvm.org/viewvc/llvm-project?view=rev&revision=85295">defaults
+to compiling eagerly</a> to avoid a race condition in the lazy JIT.
+Clients that still want the lazy JIT can switch it on by calling
+<tt>ExecutionEngine::DisableLazyCompilation(false)</tt>.</li>
+<li>It is now possible to create more than one JIT instance in the same process.
+These JITs can generate machine code in parallel,
+although <a href="http://llvm.org/docs/ProgrammersManual.html#jitthreading">you
+still have to obey the other threading restrictions</a>.</li>
</ul>
</div>
-<!--_________________________________________________________________________-->
-<div class="doc_subsubsection"><a name="specifictargets">Target-Specific
-Improvements</a></div>
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="codegen">Target Independent Code Generator Improvements</a>
+</div>
<div class="doc_text">
-<p>X86-Specific Code Generator Enhancements:
-</p>
+<p>We have put a significant amount of work into the code generator
+infrastructure, which allows us to implement more aggressive algorithms and make
+it run faster:</p>
<ul>
-<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 has been improved.</li>
-<li>PIC support for linux/x86 has been added.</li>
-<li>Support now exists for the GCC regparm attribute, and code in the X86
- backend to respect it.</li>
-<li>Various improvements have been made for the X86-64 JIT, allowing it to
- generate code in the large code model</li>
-<li>LLVM now supports inline asm with multiple constraint letters per operand
- (like "ri") which is common in X86 inline asms.</li>
-<li>Early support has been added for X86 inline asm in the C backend.</li>
-<li>Added support for the X86 MMX instruction set.</li>
+<li>...</li>
</ul>
+</div>
+
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="x86">X86-32 and X86-64 Target Improvements</a>
+</div>
-<p>ARM-Specific Code Generator Enhancements:
+<div class="doc_text">
+<p>New features of the X86 target include:
</p>
<ul>
-<li>Several improvements have been made to the ARM backend, including basic
- inline asm support, weak linkage support, static ctor/dtor support and
- many bug fixes.</li>
-<li>There are major enhancements to the ARM backend, including support for ARM
- v4-v6, vfp support, soft float, pre/postinc support, load/store multiple
- generation, constant pool entry motion (to support large functions),
- and enhancements to ARM constant island pass.
- </li>
-<li>Added support for Thumb code generation (an ARM subtarget).</li>
-<li>More aggressive size analysis for ARM inline asm strings was
- implemented.</li>
+
+<li>...</li>
+
</ul>
</div>
-<p>Other Target-Specific Code Generator Enhancements:
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="pic16">PIC16 Target Improvements</a>
+</div>
+
+<div class="doc_text">
+<p>New features of the PIC16 target include:
</p>
<ul>
-<li>The PowerPC 64 JIT now supports addressing code loaded above the 2G
- boundary.</li>
+<li>...</li>
+</ul>
-<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>
+<p>Things not yet supported:</p>
-<li>Many bugs fixed for PowerPC 64.</li>
+<ul>
+<li>Variable arguments.</li>
+<li>Interrupts/programs.</li>
+</ul>
-<li>Support was added for the ARM AAPCS and EABI ABIs and PIC codegen on
- arm/linux.</li>
+</div>
-<li>Several bugs in DWARF debug emission on linux and cygwin/mingw were fixed.
- Debugging basically works on these targets now.</li>
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="ARM">ARM Target Improvements</a>
+</div>
-<li>Support has been added for the X86-64 large code model to the JIT,
- which is useful if JIT'd function bodies are more than 2G away from
- library functions.</li>
+<div class="doc_text">
+<p>New features of the ARM target include:
+</p>
-<li>Several bugs were fixed for DWARF debug info generation on arm/linux.</li>
+<ul>
+<li>...</li>
</ul>
+
</div>
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="OtherTarget">Other Target Specific Improvements</a>
+</div>
-<!--_________________________________________________________________________-->
-<div class="doc_subsubsection"><a name="other">Other Improvements</a></div>
<div class="doc_text">
+<p>New features of other targets include:
+</p>
-<p>This release includes many other improvements, including
-performance work, specifically designed to tune datastructure
-usage. This makes several critical components faster.</p>
+<ul>
+<li>...</li>
+</ul>
-<p>More specific changes include:</p>
+</div>
-<ul>
-<li>LLVM no longer relies on static destructors to shut itself down. Instead,
- it lazily initializes itself and shuts down when llvm_shutdown() is
- explicitly called.</li>
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="newapis">New Useful APIs</a>
+</div>
-<li>LLVM now has significantly fewer static constructors, reducing startup time.
- </li>
+<div class="doc_text">
-<li>Several classes have been refactored to reduce the amount of code that
- gets linked into apps that use the JIT.</li>
+<p>This release includes a number of new APIs that are used internally, which
+ may also be useful for external clients.
+</p>
-<li>Construction of intrinsic function declarations has been simplified.</li>
+<ul>
+<li>...</li>
+</ul>
-<li>The llvm-upgrade tool now exists. This migrates LLVM 1.9 .ll files to
- LLVM 2.0 syntax.</li>
-<li>The gccas/gccld tools have been removed.</li>
+</div>
-<li>Support has been added to llvm-test for running on low-memory
- or slow machines (make SMALL_PROBLEM_SIZE=1).</li>
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="otherimprovements">Other Improvements and New Features</a>
+</div>
-<li>llvm-test is now more portable and should build with MS Visual Studio.</li>
+<div class="doc_text">
+<p>Other miscellaneous features include:</p>
+<ul>
+<li>...</li>
</ul>
+
+</div>
+
+
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="changes">Major Changes and Removed Features</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>If you're already an LLVM user or developer with out-of-tree changes based
+on LLVM 2.6, this section lists some "gotchas" that you may run into upgrading
+from the previous release.</p>
<ul>
-<li>Pass registration is slightly different in LLVM 2.0 (you now needs an
- intptr_t 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.</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 std::vector, use code like this:
- <pre>
- std::vector<Value*> Ops = ...;
- GEP = new GetElementPtrInst(BasePtr, &Ops[0], Ops.size());
- </pre>
-
- </li>
-
-<li>CastInst 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 BasicBlock::iterator, etc instead.
+<li>The LLVM interpreter now defaults to <em>not</em> using <tt>libffi</tt> even
+if you have it installed. This makes it more likely that an LLVM built on one
+system will work when copied to a similar system. To use <tt>libffi</tt>,
+configure with <tt>--enable-libffi</tt>.
</li>
+</ul>
-<li><tt>Module::getNamedFunction()</tt> is now called
- <tt>Module::getFunction()</tt>.</li>
-<li><tt>SymbolTable.h</tt> has been split into <tt>ValueSymbolTable.h</tt> and
-<tt>TypeSymbolTable.h</tt>.</li>
+<p>In addition, many APIs have changed in this release. Some of the major LLVM
+API changes are:</p>
+
+<ul>
+<li><tt>ModuleProvider</tt> has been <a
+href="http://llvm.org/viewvc/llvm-project?view=rev&revision=94686">removed</a>
+and its methods moved to <tt>Module</tt> and <tt>GlobalValue</tt>.
+Most clients can remove uses of <tt>ExistingModuleProvider</tt>,
+replace <tt>getBitcodeModuleProvider</tt> with
+<tt>getLazyBitcodeModule</tt>, and pass their <tt>Module</tt> to
+functions that used to accept <tt>ModuleProvider</tt>. Clients who
+wrote their own <tt>ModuleProvider</tt>s will need to derive from
+<tt>GVMaterializer</tt> instead and use
+<tt>Module::setMaterializer</tt> to attach it to a
+<tt>Module</tt>.</li>
+
+<li><tt>GhostLinkage</tt> has given up the ghost.
+<tt>GlobalValue</tt>s that have not yet been read from their backing
+storage have the same linkage they will have after being read in.
+Clients must replace calls to
+<tt>GlobalValue::hasNotBeenReadFromBitcode</tt> with
+<tt>GlobalValue::isMaterializable</tt>.</li>
+
+<li>FIXME: Debug info has been totally redone. Add pointers to new APIs. Substantial caveats about compatibility of .ll and .bc files.</li>
+
+<li>The <tt>llvm/Support/DataTypes.h</tt> header has moved
+to <tt>llvm/System/DataTypes.h</tt>.</li>
+
+<li>The <tt>isInteger</tt>, <tt>isIntOrIntVector</tt>, <tt>isFloatingPoint</tt>,
+<tt>isFPOrFPVector</tt> and <tt>isFPOrFPVector</tt> methods have been renamed
+<tt>isIntegerTy</tt>, <tt>isIntOrIntVectorTy</tt>, <tt>isFloatingPointTy</tt>,
+<tt>isFPOrFPVectorTy</tt> and <tt>isFPOrFPVectorTy</tt> respectively.</li>
</ul>
+
</div>
+
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="portability">Portability and Supported Platforms</a>
<p>LLVM is known to work on the following platforms:</p>
<ul>
- <li>Intel and AMD machines running Red Hat Linux, Fedora Core and FreeBSD
- (and probably other unix-like systems).</li>
-<li>Intel and AMD machines running on Win32 using MinGW libraries (native)</li>
-<li>Sun UltraSPARC workstations running Solaris 8.</li>
+<li>Intel and AMD machines (IA32, X86-64, AMD64, EMT-64) running Red Hat
+ Linux, Fedora Core, FreeBSD and AuroraUX (and probably other unix-like
+ systems).</li>
+<li>PowerPC and X86-based Mac OS X systems, running 10.3 and above in 32-bit
+ and 64-bit modes.</li>
+<li>Intel and AMD machines running on Win32 using MinGW libraries (native).</li>
<li>Intel and AMD machines running on Win32 with the Cygwin libraries (limited
support is available for native builds with Visual C++).</li>
-<li>PowerPC and X86-based Mac OS X systems, running 10.2 and above in 32-bit and
- 64-bit modes.</li>
+<li>Sun x86 and AMD64 machines running Solaris 10, OpenSolaris 0906.</li>
<li>Alpha-based machines running Debian GNU/Linux.</li>
-<li>Itanium-based machines running Linux and HP-UX.</li>
</ul>
-<p>The core LLVM infrastructure uses
-<a href="http://www.gnu.org/software/autoconf/">GNU autoconf</a> to adapt itself
+<p>The core LLVM infrastructure uses GNU autoconf to adapt itself
to the machine and operating system on which it is built. However, minor
porting may be required to get LLVM to work on new platforms. We welcome your
portability patches and reports of successful builds or error messages.</p>
<div class="doc_text">
-<p>This section contains all known problems with the LLVM system, listed by
-component. As new problems are discovered, they will be added to these
-sections. If you run into a problem, please check the <a
+<p>This section contains significant known problems with the LLVM system,
+listed by component. If you run into a problem, please check the <a
href="http://llvm.org/bugs/">LLVM bug database</a> and submit a bug if
there isn't already one.</p>
+<ul>
+<li>The llvm-gcc bootstrap will fail with some versions of binutils (e.g. 2.15)
+ with a message of "<tt><a href="http://llvm.org/PR5004">Error: can not do 8
+ byte pc-relative relocation</a></tt>" when building C++ code. We intend to
+ fix this on mainline, but a workaround is to upgrade to binutils 2.17 or
+ later.</li>
+
+<li>LLVM will not correctly compile on Solaris and/or OpenSolaris
+using the stock GCC 3.x.x series 'out the box',
+See: <a href="GettingStarted.html#brokengcc">Broken versions of GCC and other tools</a>.
+However, A <a href="http://pkg.auroraux.org/GCC">Modern GCC Build</a>
+for x86/x86-64 has been made available from the third party AuroraUX Project
+that has been meticulously tested for bootstrapping LLVM & Clang.</li>
+</ul>
+
</div>
<!-- ======================================================================= -->
be broken or unreliable, or are in early development. These components should
not be relied on, and bugs should not be filed against them, but they may be
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>
+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
- future release.</li>
-<li>C++ EH support</li>
-<li>The IA64 code generator is experimental.</li>
-<li>The Alpha JIT is experimental.</li>
-<li>"<tt>-filetype=asm</tt>" (the default) is the only supported value for the
- <tt>-filetype</tt> llc option.</li>
+<li>The MSIL, Alpha, SPU, MIPS, PIC16, Blackfin, MSP430 and SystemZ backends are
+ experimental.</li>
+<li>The <tt>llc</tt> "<tt>-filetype=asm</tt>" (the default) is the only
+ supported value for this option. The ELF writer is experimental.</li>
+<li>The implementation of Andersen's Alias Analysis has many known bugs.</li>
</ul>
</div>
<div class="doc_text">
<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 does not yet support
+ all <a href="http://llvm.org/PR879">inline assembly that uses the X86
+ floating point stack</a>. It supports the 'f' and 't' constraints, but not
+ 'u'.</li>
+ <li>The X86 backend generates inefficient floating point code when configured
+ to generate code for systems that don't have SSE2.</li>
+ <li>Win64 code generation wasn't widely tested. Everything should work, but we
+ expect small issues to happen. Also, llvm-gcc cannot build the mingw64
+ runtime currently due
+ to <a href="http://llvm.org/PR2255">several</a>
+ <a href="http://llvm.org/PR2257">bugs</a> and due to lack of support for
+ the
+ 'u' inline assembly constraint and for X87 floating point inline assembly.</li>
+ <li>The X86-64 backend does not yet support the LLVM IR instruction
+ <tt>va_arg</tt>. Currently, the llvm-gcc and front-ends support variadic
+ argument constructs on X86-64 by lowering them manually.</li>
</ul>
</div>
<div class="doc_text">
<ul>
-<li><a href="http://llvm.org/PR642">PowerPC backend does not correctly
-implement ordered FP comparisons</a>.</li>
<li>The Linux PPC32/ABI support needs testing for the interpreter and static
-compilation, and lacks Dwarf debugging informations.
+compilation, and lacks support for debug information.</li>
</ul>
</div>
<div class="doc_text">
<ul>
-<li>The Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6
-processors, any thumb program compiled with LLVM crashes or produces 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>Support for the Advanced SIMD (Neon) instruction set is still incomplete
+and not well tested. Some features may not work at all, and the code quality
+may be poor in some cases.</li>
+<li>Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6
+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>
-<li>QEMU-ARM (<= 0.9.0) wrongly executes programs compiled with LLVM. A non-affected QEMU version must be used or this
-<a href="http://cvs.savannah.nongnu.org/viewcvs/qemu/target-arm/translate.c?root=qemu&r1=1.46&r2=1.47&makepatch=1&diff_format=h">
-patch</a> must be applied on QEMU.</li>
</ul>
</div>
<div class="doc_text">
<ul>
-<li>The SPARC backend only supports the 32-bit SPARC ABI (-m32), it does not
+<li>The SPARC backend only supports the 32-bit SPARC ABI (-m32); it does not
support the 64-bit SPARC ABI (-m64).</li>
</ul>
<!-- ======================================================================= -->
<div class="doc_subsection">
- <a name="alpha-be">Known problems with the Alpha back-end</a>
+ <a name="mips-be">Known problems with the MIPS back-end</a>
</div>
<div class="doc_text">
<ul>
-
-<li>On 21164s, some rare FP arithmetic sequences which may trap do not have the
-appropriate nops inserted to ensure restartability.</li>
-
+<li>64-bit MIPS targets are not supported yet.</li>
</ul>
+
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
- <a name="ia64-be">Known problems with the IA64 back-end</a>
+ <a name="alpha-be">Known problems with the Alpha back-end</a>
</div>
<div class="doc_text">
<ul>
-<li>C++ programs are likely to fail on IA64, as calls to <tt>setjmp</tt> are
-made where the argument is not 16-byte aligned, as required on IA64. (Strictly
-speaking this is not a bug in the IA64 back-end; it will also be encountered
-when building C++ programs using the C back-end.)</li>
-
-<li>The C++ front-end does not use <a href="http://llvm.org/PR406">IA64
-ABI compliant layout of v-tables</a>. In particular, it just stores function
-pointers instead of function descriptors in the vtable. This bug prevents
-mixing C++ code compiled with LLVM with C++ objects compiled by other C++
-compilers.</li>
-
-<li>There are a few ABI violations which will lead to problems when mixing LLVM
-output with code built with other compilers, particularly for floating-point
-programs.</li>
-
-<li>Defining vararg functions is not supported (but calling them is ok).</li>
+<li>On 21164s, some rare FP arithmetic sequences which may trap do not have the
+appropriate nops inserted to ensure restartability.</li>
-<li>The Itanium backend has bitrotted somewhat.</li>
</ul>
-
</div>
<!-- ======================================================================= -->
<div class="doc_text">
<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/PR802">The C backend has only basic support for
+ inline assembly code</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 <tt>llc</tt> or native compilers.</li>
+<li>The C backend does not support all exception handling constructs.</li>
+<li>The C backend does not support arbitrary precision integers.</li>
</ul>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
- <a name="c-fe">Known problems with the C front-end</a>
+ <a name="c-fe">Known problems with the llvm-gcc C front-end</a>
</div>
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">Bugs</div>
-
<div class="doc_text">
-<p>llvm-gcc4 does not currently support <a href="http://llvm.org/PR869">Link-Time
-Optimization</a> on most platforms "out-of-the-box". Please inquire on the
-llvmdev mailing list if you are interested.</p>
+<p>The only major language feature of GCC not supported by llvm-gcc is
+ the <tt>__builtin_apply</tt> family of builtins. However, some extensions
+ are only supported on some targets. For example, trampolines are only
+ supported on some targets (these are used when you take the address of a
+ nested function).</p>
+
+<p>If you run into GCC extensions which are not supported, please let us know.
+</p>
-<p>FIXME: the list of supported stuff below needs to be updated. We do support
-tls now, what else??</p>
</div>
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- Notes
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+ <a name="c++-fe">Known problems with the llvm-gcc C++ front-end</a>
</div>
<div class="doc_text">
-<ul>
-
-<li>"long double" is transformed by the front-end into "double". There is no
-support for floating point data types of any size other than 32 and 64
-bits.</li>
-
-<li>Although many GCC extensions are supported, some are not. In particular,
- the following extensions are known to <b>not be</b> supported:
- <ol>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Local-Labels.html#Local%20Labels">Local Labels</a>: Labels local to a block.</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.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Constructing-Calls.html#Constructing%20Calls">Constructing Calls</a>: Dispatching a call to another function.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Thread_002dLocal.html">Thread-Local</a>: Per-thread variables.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Pragmas.html#Pragmas">Pragmas</a>: Pragmas accepted by GCC.</li>
- </ol>
-
- <p>The following GCC extensions are <b>partially</b> supported. An ignored
- attribute means that the LLVM compiler ignores the presence of the attribute,
- but the code should still work. An unsupported attribute is one which is
- ignored by the LLVM compiler and will cause a different interpretation of
- the program.</p>
-
- <ol>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html#Variable%20Length">Variable Length</a>:
- Arrays whose length is computed at run time.<br>
- Supported, but allocated stack space is not freed until the function returns (noted above).</li>
-
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function%20Attributes">Function Attributes</a>:
-
- Declaring that functions have no side effects or that they can never
- return.<br>
-
- <b>Supported:</b> <tt>alias</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>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>always_inline</tt>, <tt>pure</tt>, <tt>const</tt>, <tt>nothrow</tt>,
- <tt>malloc</tt>, <tt>no_instrument_function</tt>, <tt>cdecl</tt><br>
-
- <b>Unsupported:</b> All other target specific attributes</li>
-
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html#Variable%20Attributes">Variable Attributes</a>:
- Specifying attributes of variables.<br>
- <b>Supported:</b> <tt>alias</tt>, <tt>cleanup</tt>, <tt>common</tt>,
- <tt>nocommon</tt>, <tt>deprecated</tt>, <tt>dllimport</tt>,
- <tt>dllexport</tt>, <tt>section</tt>, <tt>transparent_union</tt>,
- <tt>unused</tt>, <tt>used</tt>, <tt>weak</tt><br>
-
- <b>Unsupported:</b> <tt>aligned</tt>, <tt>mode</tt>, <tt>packed</tt>,
- <tt>shared</tt>, <tt>tls_model</tt>,
- <tt>vector_size</tt>, all target specific attributes.
- </li>
-
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html#Type%20Attributes">Type Attributes</a>: Specifying attributes of types.<br>
- <b>Supported:</b> <tt>transparent_union</tt>, <tt>unused</tt>,
- <tt>deprecated</tt>, <tt>may_alias</tt><br>
-
- <b>Unsupported:</b> <tt>aligned</tt>, <tt>packed</tt>,
- all target specific attributes.</li>
-
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other%20Builtins">Other Builtins</a>:
- Other built-in functions.<br>
- We support all builtins which have a C language equivalent (e.g.,
- <tt>__builtin_cos</tt>), <tt>__builtin_alloca</tt>,
- <tt>__builtin_types_compatible_p</tt>, <tt>__builtin_choose_expr</tt>,
- <tt>__builtin_constant_p</tt>, and <tt>__builtin_expect</tt>
- (currently ignored). We also support builtins for ISO C99 floating
- point comparison macros (e.g., <tt>__builtin_islessequal</tt>),
- <tt>__builtin_prefetch</tt>, <tt>__builtin_popcount[ll]</tt>,
- <tt>__builtin_clz[ll]</tt>, and <tt>__builtin_ctz[ll]</tt>.</li>
- </ol>
-
- <p>The following extensions <b>are</b> known to be supported:</p>
-
- <ol>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html#Labels%20as%20Values">Labels as Values</a>: Getting pointers to labels and computed gotos.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html#Statement%20Exprs">Statement Exprs</a>: Putting statements and declarations inside expressions.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Typeof.html#Typeof">Typeof</a>: <code>typeof</code>: referring to the type of an expression.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc-3.4.0/gcc/Lvalues.html#Lvalues">Lvalues</a>: Using <code>?:</code>, "<code>,</code>" and casts in lvalues.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Conditionals.html#Conditionals">Conditionals</a>: Omitting the middle operand of a <code>?:</code> expression.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Long-Long.html#Long%20Long">Long Long</a>: Double-word integers.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Complex.html#Complex">Complex</a>: Data types for complex numbers.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Hex-Floats.html#Hex%20Floats">Hex Floats</a>:Hexadecimal floating-point constants.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html#Zero%20Length">Zero Length</a>: Zero-length arrays.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Empty-Structures.html#Empty%20Structures">Empty Structures</a>: Structures with no members.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Variadic-Macros.html#Variadic%20Macros">Variadic Macros</a>: Macros with a variable number of arguments.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Escaped-Newlines.html#Escaped%20Newlines">Escaped Newlines</a>: Slightly looser rules for escaped newlines.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Extended%20Asm">Extended Asm</a>: Assembler instructions with C expressions as operands.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Constraints.html#Constraints">Constraints</a>: Constraints for asm operands.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Asm-Labels.html#Asm%20Labels">Asm Labels</a>: Specifying the assembler name to use for a C symbol.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Explicit-Reg-Vars.html#Explicit%20Reg%20Vars">Explicit Reg Vars</a>: Defining variables residing in specified registers.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html#Vector%20Extensions">Vector Extensions</a>: Using vector instructions through built-in functions.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Target-Builtins.html#Target%20Builtins">Target Builtins</a>: Built-in functions specific to particular targets.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Subscripting.html#Subscripting">Subscripting</a>: Any array can be subscripted, even if not an lvalue.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html#Pointer%20Arith">Pointer Arith</a>: Arithmetic on <code>void</code>-pointers and function pointers.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Initializers.html#Initializers">Initializers</a>: Non-constant initializers.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Compound-Literals.html#Compound%20Literals">Compound Literals</a>: Compound literals give structures, unions,
-or arrays as values.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html#Designated%20Inits">Designated Inits</a>: Labeling elements of initializers.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Cast-to-Union.html#Cast%20to%20Union">Cast to Union</a>: Casting to union type from any member of the union.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Case-Ranges.html#Case%20Ranges">Case Ranges</a>: `case 1 ... 9' and such.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Mixed-Declarations.html#Mixed%20Declarations">Mixed Declarations</a>: Mixing declarations and code.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Function-Prototypes.html#Function%20Prototypes">Function Prototypes</a>: Prototype declarations and old-style definitions.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Comments.html#C_002b_002b-Comments">C++ Comments</a>: C++ comments are recognized.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Dollar-Signs.html#Dollar%20Signs">Dollar Signs</a>: Dollar sign is allowed in identifiers.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Character-Escapes.html#Character%20Escapes">Character Escapes</a>: <code>\e</code> stands for the character <ESC>.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Alignment.html#Alignment">Alignment</a>: Inquiring about the alignment of a type or variable.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Inline.html#Inline">Inline</a>: Defining inline functions (as fast as macros).</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Alternate-Keywords.html#Alternate%20Keywords">Alternate Keywords</a>:<code>__const__</code>, <code>__asm__</code>, etc., for header files.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Incomplete-Enums.html#Incomplete%20Enums">Incomplete Enums</a>: <code>enum foo;</code>, with details to follow.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Function-Names.html#Function%20Names">Function Names</a>: Printable strings which are the name of the current function.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Return-Address.html#Return%20Address">Return Address</a>: Getting the return or frame address of a function.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html#Unnamed%20Fields">Unnamed Fields</a>: Unnamed struct/union fields within structs/unions.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute%20Syntax">Attribute Syntax</a>: Formal syntax for attributes.</li>
- </ol></li>
+<p>The C++ front-end is considered to be fully
+tested and works for a number of non-trivial programs, including LLVM
+itself, Qt, Mozilla, etc.</p>
+<ul>
+<li>Exception handling works well on the X86 and PowerPC targets. Currently
+ only Linux and Darwin targets are supported (both 32 and 64 bit).</li>
</ul>
-<p>If you run into GCC extensions which have not been included in any of these
-lists, please let us know (also including whether or not they work).</p>
-
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
- <a name="c++-fe">Known problems with the C++ front-end</a>
+ <a name="fortran-fe">Known problems with the llvm-gcc Fortran front-end</a>
</div>
<div class="doc_text">
+<ul>
+<li>Fortran support generally works, but there are still several unresolved bugs
+ in <a href="http://llvm.org/bugs/">Bugzilla</a>. Please see the
+ tools/gfortran component for details.</li>
+</ul>
+</div>
-<p>The C++ front-end is considered to be fully
-tested and works for a number of non-trivial programs, including LLVM
-itself, Qt, Mozilla, etc.</p>
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+ <a name="ada-fe">Known problems with the llvm-gcc Ada front-end</a>
+</div>
+<div class="doc_text">
+The llvm-gcc 4.2 Ada compiler works fairly well; however, this is not a mature
+technology, and problems should be expected.
<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>
-
-<!-- NO EH Support!
-
-<li>Destructors for local objects are not always run when a <tt>longjmp</tt> is
- performed. In particular, destructors for objects in the <tt>longjmp</tt>ing
- function and in the <tt>setjmp</tt> receiver function may not be run.
- Objects in intervening stack frames will be destroyed, however (which is
- better than most compilers).</li>
-
-<li>The LLVM C++ front-end follows the <a
- href="http://www.codesourcery.com/cxx-abi">Itanium C++ ABI</a>.
- This document, which is not Itanium specific, specifies a standard for name
- mangling, class layout, v-table layout, RTTI formats, and other C++
- representation issues. Because we use this API, code generated by the LLVM
- compilers should be binary compatible with machine code generated by other
- Itanium ABI C++ compilers (such as G++, the Intel and HP compilers, etc).
- <i>However</i>, the exception handling mechanism used by llvm-gcc3 is very
- different from the model used in the Itanium ABI, so <b>exceptions will not
- interact correctly</b>. </li>
--->
+<li>The Ada front-end currently only builds on X86-32. This is mainly due
+to lack of trampoline support (pointers to nested functions) on other platforms.
+However, it <a href="http://llvm.org/PR2006">also fails to build on X86-64</a>
+which does support trampolines.</li>
+<li>The Ada front-end <a href="http://llvm.org/PR2007">fails to bootstrap</a>.
+This is due to lack of LLVM support for <tt>setjmp</tt>/<tt>longjmp</tt> style
+exception handling, which is used internally by the compiler.
+Workaround: configure with <tt>--disable-bootstrap</tt>.</li>
+<li>The c380004, <a href="http://llvm.org/PR2010">c393010</a>
+and <a href="http://llvm.org/PR2421">cxg2021</a> ACATS tests fail
+(c380004 also fails with gcc-4.2 mainline).
+If the compiler is built with checks disabled then <a href="http://llvm.org/PR2010">c393010</a>
+causes the compiler to go into an infinite loop, using up all system memory.</li>
+<li>Some GCC specific Ada tests continue to crash the compiler.</li>
+<li>The <tt>-E</tt> binder option (exception backtraces)
+<a href="http://llvm.org/PR1982">does not work</a> and will result in programs
+crashing if an exception is raised. Workaround: do not use <tt>-E</tt>.</li>
+<li>Only discrete types <a href="http://llvm.org/PR1981">are allowed to start
+or finish at a non-byte offset</a> in a record. Workaround: do not pack records
+or use representation clauses that result in a field of a non-discrete type
+starting or finishing in the middle of a byte.</li>
+<li>The <tt>lli</tt> interpreter <a href="http://llvm.org/PR2009">considers
+'main' as generated by the Ada binder to be invalid</a>.
+Workaround: hand edit the file to use pointers for <tt>argv</tt> and
+<tt>envp</tt> rather than integers.</li>
+<li>The <tt>-fstack-check</tt> option <a href="http://llvm.org/PR2008">is
+ignored</a>.</li>
</ul>
+</div>
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+ <a name="ocaml-bindings">Known problems with the O'Caml bindings</a>
</div>
+<div class="doc_text">
+<p>The <tt>Llvm.Linkage</tt> module is broken, and has incorrect values. Only
+<tt>Llvm.Linkage.External</tt>, <tt>Llvm.Linkage.Available_externally</tt>, and
+<tt>Llvm.Linkage.Link_once</tt> will be correct. If you need any of the other linkage
+modes, you'll have to write an external C library in order to expose the
+functionality. This has been fixed in the trunk.</p>
+</div>
<!-- *********************************************************************** -->
<div class="doc_section">
<div class="doc_text">
<p>A wide variety of additional information is available on the <a
-href="http://llvm.org">LLVM web page</a>, including <a
-href="http://llvm.org/docs/">documentation</a> and <a
-href="http://llvm.org/pubs/">publications describing algorithms and
-components implemented in LLVM</a>. The web page also contains versions of the
-API documentation which is up-to-date with the CVS version of the source code.
+href="http://llvm.org">LLVM web page</a>, in particular in the <a
+href="http://llvm.org/docs/">documentation</a> section. The web page also
+contains versions of the API documentation which is up-to-date with the
+Subversion version of the source code.
You can access versions of these documents specific to this release by going
into the "<tt>llvm/doc/</tt>" directory in the LLVM tree.</p>
<hr>
<address>
<a href="http://jigsaw.w3.org/css-validator/check/referer"><img
- src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
<a href="http://validator.w3.org/check/referer"><img
- src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
- <a href="http://llvm.org/">The LLVM Compiler Infrastructure</a><br>
+ <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br>
Last modified: $Date$
</address>
projects / oota-llvm.git / blobdiff