<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<link rel="stylesheet" href="llvm.css" type="text/css">
- <title>LLVM 1.6 Release Notes</title>
+ <title>LLVM 1.9 Release Notes</title>
</head>
<body>
-<div class="doc_title">LLVM 1.6 Release Notes</div>
+<div class="doc_title">LLVM 1.9 Release Notes</div>
<ol>
<li><a href="#intro">Introduction</a></li>
<div class="doc_text">
<p>This document contains the release notes for the LLVM compiler
-infrastructure, release 1.6. Here we describe the status of LLVM, including any
+infrastructure, release 1.9. Here we describe the status of LLVM, including any
known problems and major improvements from the previous release. The most
-up-to-date version of this document can be found on the <a
-href="http://llvm.org/releases/1.6/">LLVM 1.6 web site</a>. If you are
+up-to-date version of this document (corresponding to LLVM CVS) can be found
+on the <a
+href="http://llvm.org/releases/">LLVM releases web site</a>. If you are
not reading this on the LLVM web pages, you should probably go there because
this document may be updated after the release.</p>
<div class="doc_text">
-<p>This is the seventh public release of the LLVM Compiler Infrastructure. This
-release incorporates a large number of enhancements and additions (primarily in
-the code generator), which combine to improve the quality of the code generated
-by LLVM by up to 30% in some cases. This release is also the first release to
-have first-class support for Mac OS/X: all of the major bugs have been shaken
-out and it is now as well supported as Linux on X86.</p>
+<p>This is the tenth public release of the LLVM Compiler Infrastructure. This
+release incorporates a large number of enhancements, new features, and bug
+fixes. We recommend that all users of previous LLVM versions upgrade.
+</p>
</div>
<!--=========================================================================-->
<div class="doc_subsection">
-<a name="newfeatures">New Features in LLVM 1.6</a>
+<a name="newfeatures">New Features in LLVM 1.9</a>
</div>
<!--_________________________________________________________________________-->
-<div class="doc_subsubsection"><a name="iselgen">Instruction Selector
-Generation from Target Description</a></div>
-
+<div class="doc_subsubsection"><a name="x86-64">New X86-64 Backend</a></div>
<div class="doc_text">
-<p>LLVM now includes support for auto-generating large portions of the
-instruction selectors from target descriptions. This allows us to
-write patterns in the target .td file, instead of writing lots of
-nasty C++ code. Most of the PowerPC instruction selector is now
-generated from the PowerPC target description files and other targets
-are adding support that will be live for LLVM 1.7.</p>
-
-<p>For example, here are some patterns used by the PowerPC backend. A
-floating-point multiply then subtract instruction (FMSUBS):</p>
-
-<div class="doc_code"><p>
-<tt>(set F4RC:$FRT, (fsub (fmul F4RC:$FRA, F4RC:$FRC), F4RC:$FRB))</tt>
-</p></div>
-
-<p>Exclusive-or by 16-bit immediate (XORI):</p>
-
-<div class="doc_code"><p>
-<tt>(set GPRC:$dst, (xor GPRC:$src1, immZExt16:$src2))</tt>
-</p></div>
-
-<p>Exclusive-or by 16-bit immediate shifted right 16-bits (XORIS):</p>
-
-<div class="doc_code"><p>
-<tt>(set GPRC:$dst, (xor GPRC:$src1, imm16Shifted:$src2))</tt>
-</p></div>
-
-<p>With these definitions, we teach the code generator how to combine these two
-instructions to xor an abitrary 32-bit immediate with the following
-definition. The first line specifies what to match (a xor with an arbitrary
-immediate) the second line specifies what to produce:</p>
-
-<div class="doc_code"><p>
-<pre>def : Pat<(xor GPRC:$in, imm:$imm),
- (XORIS (XORI GPRC:$in, (LO16 imm:$imm)), (HI16 imm:$imm))>;
-</pre>
-</p></div>
-
+<p>LLVM 1.9 now fully supports the x86-64 instruction set on Mac OS/X, and
+supports it on Linux (and other operating systems) when compiling in -static
+mode. LLVM includes JIT support for X86-64, and supports both Intel EMT-64T
+and AMD-64 architectures. The X86-64 instruction set permits addressing a
+64-bit addressing space and provides the compiler with twice the
+number of integer registers to use.</p>
</div>
<!--_________________________________________________________________________-->
-<div class="doc_subsubsection"><a name="sched">Instruction Scheduling
-Support</a></div>
-
+<div class="doc_subsubsection"><a name="lto">Link-Time Optimization integration
+with native linkers</a></div>
<div class="doc_text">
-
-<p>Instruction selectors using the refined <a
-href="CodeGenerator.html#instselect">instruction selection framework</a> can now
-use a simple pre-pass scheduler included with LLVM 1.6. This scheduler is
-currently simple (cannot be configured much by the targets), but will be
-extended in the future.</p>
+<p>LLVM now includes <a href="LinkTimeOptimization.html">liblto</a> which can
+be used to integrate LLVM Link-Time Optimization support into a native linker.
+This allows LLVM .bc to transparently participate with linking an application,
+even when some .o files are in LLVM form and some are not.</p>
</div>
<!--_________________________________________________________________________-->
-<div class="doc_subsubsection"><a name="subtarget">Code Generator Subtarget
-Support</a></div>
-
+<div class="doc_subsubsection"><a name="dwarf">DWARF debugging
+support for Linux, Cygwin and MinGW on X86</a></div>
<div class="doc_text">
-<p>It is now straight-forward to parameterize a target implementation, and
-provide a mapping from CPU names to sets of target parameters. LLC now supports
-a <tt>-mcpu=cpu</tt> option that lets you choose a subtarget by CPU name: use
-"<tt>llvm-as < /dev/null | llc -march=XXX -mcpu=help</tt>" to get a list of
-supported CPUs for target "XXX". It also provides a
-<tt>-mattr=+attr1,-attr2</tt> option that can be used to control individual
-features of a target (the previous command will list available features as
-well).</p>
+<p>llvm-gcc4 now supports generating debugging info for Linux, Cygwin and MinGW.
+This extends the PPC/Darwin and X86/Darwin debugging support available in the
+1.8 release. DWARF is a standard debugging format used on many platforms.</p>
+</div>
-<p>This functionality is nice when you want tell LLC something like "compile to
-code that is specialized for the PowerPC G5, but doesn't use altivec code. In
-this case, using "<tt>llc -march=ppc32 -mcpu=g5 -mattr=-altivec</tt>".</p>
+<!--_________________________________________________________________________-->
+<div class="doc_subsubsection"><a name="optimizer">Optimizer
+Improvements</a></div>
+<div class="doc_text">
+<p>The mid-level optimizer is now faster and produces better code in many cases.
+ Significant changes include:</p>
+<ul>
+<li>LLVM includes a new 'predicate simplifier' pass, which
+ currently performs dominator tree-based optimizations.</li>
+<li>The complete loop unroll pass now supports unrolling of
+ multiple basic block loops.</li>
+<li>The 'globalopt' pass can now perform the scalar replacement of
+ aggregates transformation on some heap allocations.</li>
+<li>The globalsmodref-aa alias analysis can now track 'indirect pointer
+ globals' more accurately.</li>
+<li>The instruction combiner can now perform element propagation
+analysis of vector expressions, eliminating computation of vector elements
+that are not used.</li>
+</ul>
+
</div>
<!--_________________________________________________________________________-->
-<div class="doc_subsubsection"><a name="jitlock">Other New Features</a></div>
+<div class="doc_subsubsection"><a name="codegen">Code
+Generator Enhancements</a></div>
<div class="doc_text">
-<ol>
- <li>The JIT now uses mutexes to protect its internal data structures. This
- allows multi-threaded programs to be run from the JIT or interpreter without
- corruption of the internal data structures. See
- <a href="http://llvm.org/PR418">PR418</a> and
- <a href="http://llvm.org/PR540">PR540</a> for the details.
- </li>
- <li>LLVM on Win32 <a href="http://llvm.org/PR614">no longer requires sed,
- flex, or bison when compiling with Visual C++</a>.</li>
- <li>The llvm-test suite can now use the NAG Fortran to C compiler to compile
- SPEC FP programs if available (allowing us to test all of SPEC'95 &
- 2000).</li>
- <li>When bugpoint is grinding away and the user hits ctrl-C, it now
- gracefully stops and gives what it has reduced so far, instead of
- giving up completely. In addition, <a href="http://llvm.org/PR576">the JIT
- debugging mode of bugpoint is much faster</a>.</li>
- <li>LLVM now includes Xcode project files in the llvm/Xcode directory.</li>
- <li>LLVM now supports Mac OS/X on Intel.</li>
- <li>LLVM now builds cleanly with GCC 4.1.</li>
-</ol>
-</div>
+<p>
+The LLVM Target-Independent code generator now supports more target features and
+optimizes many cases more aggressively. New features include:
+</p>
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="codequality">Code Quality Improvements in LLVM 1.6</a>
-</div>
+<ul>
+<li>LLVM now includes a late branch folding pass which optimizes code
+ layout, performs several branch optzns, and deletes unreachable code.</li>
+<li>The code generator now support targets that have pre/post-increment
+ addressing modes.</li>
+<li>LLVM now supports dynamically-loadable register allocators and
+ schedulers.</li>
+<li>LLVM 1.9 includes several improvements to inline asm support,
+ including support for new constraints and modifiers.</li>
+<li>The register coalescer is now more aggressive than before,
+ allowing it to eliminate more copies.</li>
+</ul>
-<div class="doc_text">
-<ol>
- <li>The <tt>-globalopt</tt> pass can now statically evaluate C++ static
- constructors when they are simple enough. For example, it can
- now statically initialize "<tt>struct X { int a; X() : a(4) {} } g;</tt>".
- </li>
- <li>The Loop Strength Reduction pass has been completely rewritten, is far
- more aggressive, and is turned on by default in the RISC targets. On PPC,
- we find that it often speeds up programs from 10-40% depending on the
- program.</li>
- <li>The code produced when exception handling is enabled is far more
- efficient in some cases, particularly on Mac OS/X.</li>
-</ol>
-</div>
+<p>In addition, the LLVM target description format has itself been extended in
+ several ways:</p>
+
+<ul>
+<li>tblgen now allows definition of '<a
+ href="TableGenFundamentals.html#multiclass">multiclasses</a>' which can be
+ used to factor instruction patterns more aggressively in .td files.</li>
+<li>LLVM has a new TargetAsmInfo class which captures a variety of
+ information about the target assembly language format.</li>
+<li>.td files now support "<tt>${:foo}</tt>" syntax for encoding
+ subtarget-specific assembler syntax into instruction descriptions.</li>
+</ul>
+<p>Further, several significant target-specific enhancements are included in
+LLVM 1.9:</p>
+
+<ul>
+<li>The LLVM ARM backend now supports more instructions
+ and the use of a frame pointer. It is now possible to build
+ libgcc and a simple cross compiler, but it is not considered "complete" yet.
+ </li>
+<li>LLVM supports the Win32 dllimport/dllexport linkage and
+ stdcall/fastcall calling conventions.</li>
+</ul>
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="codequality">Code Generator Improvements in LLVM 1.6</a>
</div>
+<!--_________________________________________________________________________-->
+<div class="doc_subsubsection"><a name="other">Other Improvements</a></div>
<div class="doc_text">
-<ol>
-<li>The Alpha backend is substantially more stable and robust than in LLVM 1.5.
- For example, it now fully supports varargs functions. The Alpha backend
- also now features beta JIT support.</li>
-<li>The code generator contains a new component, the DAG Combiner. This allows
- us to optimize lowered code (e.g. after 64-bit operations have been lowered
- to use 32-bit registers on 32-bit targets) and do fine-grained bit-twiddling
- optimizations for the backend.</li>
-<li>The SelectionDAG infrastructure is far more capable and mature, able to
- handle many new target peculiarities in a target-independent way.</li>
-<li>The default <a href="http://llvm.org/PR547">register allocator is now far
- faster on some testcases</a>,
- particularly on targets with a large number of registers (e.g. IA64
- and PPC).</li>
-</ol>
+<p>This release includes many other improvements, including improvements to
+ the optimizers and code generators (improving the generated code) changes to
+ speed up the compiler in many ways (improving algorithms and fine tuning
+ code), and changes to reduce the code size of the compiler itself.</p>
+
+<p>More specific changes include:</p>
+
+<ul>
+<li>The llvm-test framework now supports SPEC2006.</li>
+<li>LLVM now includes a <a href="GetElementPtr.html">FAQ about the
+<tt>getelementptr</tt> instruction</a>.</li>
+<li>Bugpoint now supports a new "<tt>-find-bugs</tt>" mode. This mode makes
+ bugpoint permute pass sequences to try to expose bugs due to pass
+ sequencing.</li>
+<li>The JIT now supports lazily streaming code from multiple modules at a
+ time, implicitly linking the code as it goes.</li>
+</ul>
</div>
<!--=========================================================================-->
<div class="doc_subsection">
-<a name="bugfix">Significant Bugs Fixed in LLVM 1.6</a>
+<a name="apichanges">Significant API Changes in LLVM 1.9</a>
</div>
<div class="doc_text">
-<ol>
- <li>A vast number of bugs have been fixed in the PowerPC backend and in
- llvm-gcc when configured for Mac OS/X (particularly relating to ABI
- issues). For example:
- <a href="http://llvm.org/PR603">PR449</a>,
- <a href="http://llvm.org/PR594">PR594</a>,
- <a href="http://llvm.org/PR603">PR603</a>,
- <a href="http://llvm.org/PR609">PR609</a>,
- <a href="http://llvm.org/PR630">PR630</a>,
- <a href="http://llvm.org/PR643">PR643</a>,
- and several others without bugzilla bugs.</li>
- <li>Several bugs in tail call support have been fixed.</li>
- <li><a href="http://llvm.org/PR608">configure does not correctly detect gcc
- version on cygwin</a>.</li>
- <li>Many many other random bugs have been fixed. Query <a
- href="http://llvm.org/bugs">our bugzilla</a> with a target of 1.6 for more
- information.</li>
-</ol>
+
+<p>Several significant API changes have been made. If you are maintaining
+out-of-tree code, please be aware that:</p>
+
+<ul>
+<li>The ConstantSInt and ConstantUInt classes have been merged into the
+ ConstantInt class.</li>
+<li><p>As a step towards making LLVM's integer types signless, several new
+instructions have been added to LLVM. The <tt>Div</tt> instruction is now
+<tt>UDiv</tt>, <tt>SDiv</tt>, and <tt>FDiv</tt>. The <tt>Rem</tt> instruction
+is now <tt>URem</tt>, <tt>SRem</tt> and <tt>FRem</tt>. See the
+<a href="LangRef.html">Language Reference</a> for details on these new
+instructions.</p>
+<li><p><tt>ConstantBool::True</tt> and <tt>ConstantBool::False</tt> have been
+ renamed to <tt>ConstantBool::getTrue()</tt> and
+ <tt>ConstantBool::getFalse()</tt>.</p></li>
+<li>The 'analyze' tool has been merged into the 'opt' tool.</li>
+
+</ul>
</div>
+
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="portability">Portability and Supported Platforms</a>
<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 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.</li>
+<li>PowerPC and X86-based Mac OS X systems, running 10.2 and above in 32-bit and
+ 64-bit modes.</li>
<li>Alpha-based machines running Debian GNU/Linux.</li>
<li>Itanium-based machines running Linux and HP-UX.</li>
</ul>
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 llvmdev list.</p>
+components, please contact us on the <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev list</a>.</p>
<ul>
-<li>The following passes are incomplete or buggy, and may be removed in future
- releases: <tt>-cee, -pre</tt></li>
-<li>The <tt>llvm-db</tt> tool is in a very early stage of development, but can
- be used to step through programs and inspect the stack.</li>
-<li>The SparcV8 and IA64 code generators are experimental.</li>
+<li>The <tt>-cee</tt> pass is known to be buggy, and may be removed in in a
+ future release.</li>
+<li>The IA64 code generator is experimental.</li>
+<li>The ARM 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>
+</ul>
+
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+ <a name="x86-be">Known problems with the X86 back-end</a>
+</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>. See the <a
+ href="http://llvm.org/PR879">bug</a> for details on workarounds on
+ Linux.</li>
+</ul>
+
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+ <a name="ppc-be">Known problems with the PowerPC back-end</a>
+</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 64-bit PowerPC backend is not fully stable. If you desire PPC64 support,
+ please use mainline CVS LLVM, which has several important bug fixes.</li>
+</ul>
+
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+ <a name="sparc-be">Known problems with the SPARC back-end</a>
+</div>
+
+<div class="doc_text">
+
+<ul>
+<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>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+ <a name="c-be">Known problems with the C back-end</a>
+</div>
+
+<div class="doc_text">
+
+<ul>
+
+<li>The C back-end produces code that violates the ANSI C Type-Based Alias
+Analysis rules. As such, special options may be necessary to compile the code
+(for example, GCC requires the <tt>-fno-strict-aliasing</tt> option). This
+problem probably cannot be fixed.</li>
+
+<li><a href="http://llvm.org/PR56">Zero arg vararg functions are not
+supported</a>. This should not affect LLVM produced by the C or C++
+frontends.</li>
+
+<li>The C backend does not correctly implement the <a
+href="LangRef.html#i_stacksave"><tt>llvm.stacksave</tt></a> or
+<a href="LangRef.html#i_stackrestore"><tt>llvm.stackrestore</tt></a>
+intrinsics. This means that some code compiled by it can run out of stack
+space if they depend on these (e.g. C99 varargs).</li>
+
+<li><a href="http://llvm.org/PR802">The C backend does not support inline
+ assembly code</a>.</li>
+</ul>
+
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+ <a name="alpha-be">Known problems with the Alpha 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>
+
+</ul>
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+ <a name="ia64-be">Known problems with the IA64 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>
+
+</ul>
+
+</div>
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+ <a name="arm-be">Known problems with the ARM back-end</a>
+</div>
+
+<div class="doc_text">
+
+<ul>
+<li>The ARM backend is currently in early development stages, it is not
+ready for production use.</li>
</ul>
</div>
<div class="doc_subsubsection">Bugs</div>
<div class="doc_text">
-<ul>
-<li>C99 Variable sized arrays do not release stack memory when they go out of
- scope. Thus, the following program may run out of stack space:
-<pre>
- for (i = 0; i != 1000000; ++i) {
- int X[n];
- foo(X);
- }
-</pre></li>
-
-<li>Initialization of global union variables can only be done <a
-href="http://llvm.org/PR162">with the largest union member</a>.</li>
-</ul>
+<p>
+
+<p>llvm-gcc4 is far more stable and produces better code than llvm-gcc3, but
+does not currently support <a href="http://llvm.org/PR869">Link-Time
+Optimization</a> or <a href="http://llvm.org/PR870">C++ Exception Handling</a>,
+which llvm-gcc3 does.</p>
+
+<p>llvm-gcc4 does not support the <a href="http://llvm.org/PR947">GCC indirect
+goto extension</a>, but llvm-gcc3 does.</p>
+
</div>
<!-- _______________________________________________________________________ -->
<ul>
-<li>Inline assembly is not yet supported.</li>
-
<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>The following Unix system functionality has not been tested and may not
-work:
- <ol>
- <li><tt>sigsetjmp</tt>, <tt>siglongjmp</tt> - These are not turned into the
- appropriate <tt>invoke</tt>/<tt>unwind</tt> instructions. Note that
- <tt>setjmp</tt> and <tt>longjmp</tt> <em>are</em> compiled correctly.
- <li><tt>getcontext</tt>, <tt>setcontext</tt>, <tt>makecontext</tt>
- - These functions have not been tested.
- </ol></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/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/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>
Declaring that functions have no side effects or that they can never
return.<br>
- <b>Supported:</b> <tt>format</tt>, <tt>format_arg</tt>, <tt>non_null</tt>,
- <tt>noreturn</tt>, <tt>constructor</tt>, <tt>destructor</tt>,
- <tt>unused</tt>,
- <tt>deprecated</tt>, <tt>warn_unused_result</tt>, <tt>weak</tt><br>
+ <b>Supported:</b> <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>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> <tt>used</tt>, <tt>section</tt>, <tt>alias</tt>,
- <tt>visibility</tt>, <tt>regparm</tt>, <tt>stdcall</tt>,
- <tt>fastcall</tt>, all other target specific attributes</li>
+ <b>Unsupported:</b> <tt>alias</tt>, <tt>regparm</tt>, 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>cleanup</tt>, <tt>common</tt>, <tt>nocommon</tt>,
- <tt>deprecated</tt>, <tt>transparent_union</tt>,
- <tt>unused</tt>, <tt>weak</tt><br>
+ <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>section</tt>, <tt>shared</tt>, <tt>tls_model</tt>,
- <tt>vector_size</tt>, <tt>dllimport</tt>,
- <tt>dllexport</tt>, all target specific attributes.</li>
+ <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>,
<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>
</div>
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">Bugs</div>
-
-<div class="doc_text">
-
-<ul>
-<li>The C++ front-end inherits all problems afflicting the <a href="#c-fe">C
- front-end</a>.</li>
-
-</ul>
-
-</div>
-
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
Notes
</div>
<div class="doc_text">
-
<ul>
-
-<li>The C++ front-end is based on a pre-release of the GCC 3.4 C++ parser. This
-parser is significantly more standards compliant (and picky) than prior GCC
-versions. For more information, see the C++ section of the <a
-href="http://gcc.gnu.org/gcc-3.4/changes.html">GCC 3.4 release notes</a>.</li>
+<li>llvm-gcc4 does not support C++ exception handling at all yet.</li>
<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
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 is very
+ <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>
</div>
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="c-be">Known problems with the C back-end</a>
-</div>
-
-<div class="doc_text">
-
-<ul>
-
-<li>The C back-end produces code that violates the ANSI C Type-Based Alias
-Analysis rules. As such, special options may be necessary to compile the code
-(for example, GCC requires the <tt>-fno-strict-aliasing</tt> option). This
-problem probably cannot be fixed.</li>
-
-<li><a href="http://llvm.org/PR56">Zero arg vararg functions are not
-supported</a>. This should not affect LLVM produced by the C or C++
-frontends.</li>
-
-</ul>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="x86-be">Known problems with the X86 back-end</a>
-</div>
-
-<div class="doc_text">
-
-<ul>
-<li><a href="http://llvm.org/PR566">Memory Mapped I/O Intrinsics do not fence
-memory</a></li>
-</ul>
-
-</div>
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="ppc-be">Known problems with the PowerPC back-end</a>
-</div>
-
-<div class="doc_text">
-
-<ul>
-<li>None yet</li>
-</ul>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="sparcv9-be">Known problems with the SparcV9 back-end</a>
-</div>
-
-<div class="doc_text">
-
-<ul>
-<li><a href="http://llvm.org/PR60">[sparcv9] SparcV9 backend miscompiles
-several programs in the LLVM test suite</a></li>
-</ul>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="alpha-be">Known problems with the Alpha 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>
-
-</ul>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="ia64-be">Known problems with the IA64 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>
-
-</ul>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="sparcv8">Known problems with the SPARC-V8 back-end</a>
-</div>
-
-<div class="doc_text">
-
-<ul>
-<li>Many features are still missing (e.g. support for 64-bit integer
-arithmetic). This back-end is in pre-beta state.</li>
-</ul>
-</div>
<!-- *********************************************************************** -->
<div class="doc_section">
projects / oota-llvm.git / blobdiff