<li>The '<tt>-enable-eh</tt>' flag to llc has been removed. Now code should
encode whether it is safe to omit unwind information for a function by
tagging the Function object with the '<tt>nounwind</tt>' attribute.</li>
+<li>The ConstantFP::get method that uses APFloat now takes one argument
+ instead of two. The type argument has been removed, and the type is
+ now inferred from the size of the given APFloat value.</li>
</ul>
</div>
downloaded from:
</p>
-<p>
-<tt>svn co http://llvm.org/svn/llvm-project/vmkit/trunk vmkit</tt>
-</p>
+<div class="doc_code">
+<pre>svn co http://llvm.org/svn/llvm-project/vmkit/trunk vmkit</pre>
+</div>
</div>
transformations (such as refactoring) and other source-level tools for C and
Objective-C. Clang now also includes tools for turning C code into pretty HTML,
and includes a new <a href="http://clang.llvm.org/StaticAnalysis.html">static
-analysis tool</a> in development. This tool is automatically focused on finding
+analysis tool</a> in development. This tool focuses on automatically finding
bugs in C and Objective-C code.</p>
</div>
<tt>llvmc</tt> and to provide a superset of the features of the
'<tt>gcc</tt>' driver.</p>
-<p>The main features of <tt>llvmc2</tt> are:
+
<p>The main features of <tt>llvmc2</tt> are:
<ul>
<li>Extended handling of command line options and smart rules for
dispatching them to different tools.</li>
it's relatively easy to add new features.</li>
<li>The definition of driver is transformed into set of C++ classes, thus
no runtime interpretation is needed.</li>
- </ul></p>
- </li>
+ </ul>
+</li>
<li><p>LLVM 2.3 includes a completely rewritten interface for <a
href="LinkTimeOptimization.html">Link Time Optimization</a>. This interface
<li>llvm-gcc 4.2 includes numerous fixes to better support the Objective-C
front-end. Objective-C now works very well on Mac OS/X.</li>
-<li>Fortran EQUIVALENCEs are now supported by the gfortran front-end.</li>
+<li>Fortran <tt>EQUIVALENCE</tt>s are now supported by the gfortran
+front-end.</li>
<li>llvm-gcc 4.2 includes many other fixes which improve conformance with the
relevant parts of the GCC testsuite.</li>
-</ul></p>
+</ul>
</div>
<li>LLVM IR now directly represents "common" linkage, instead of representing it
as a form of weak linkage.</li>
-<li>LLVM IR now has support for atomic operations, and this functionality can
-be accessed through the llvm-gcc "__sync_synchronize",
-"__sync_val_compare_and_swap", and related builtins. Support for atomics are
-available in the Alpha, X86, X86-64, and PowerPC backends.</li>
+<li>LLVM IR now has support for atomic operations, and this functionality can be
+accessed through the llvm-gcc "<tt>__sync_synchronize</tt>",
+"<tt>__sync_val_compare_and_swap</tt>", and related builtins. Support for
+atomics are available in the Alpha, X86, X86-64, and PowerPC backends.</li>
<li>The C and Ocaml bindings have extended to cover pass managers, several
transformation passes, iteration over the LLVM IR, target data, and parameter
This transformation hoists conditions from loop bodies and reduces a loop's
iteration space to improve performance. For example,</p>
+<div class="doc_code">
<pre>
for (i = LB; i < UB; ++i)
if (i <= NV)
LOOP_BODY
</pre>
+</div>
<p>is transformed into:</p>
+<p><div class="doc_code">
<pre>
NUB = min(NV+1, UB)
for (i = LB; i < NUB; ++i)
LOOP_BODY
</pre>
+</div>
+</p>
</li>
<li>LLVM now includes a new <tt>memcpy</tt> optimization pass which removes
<li>The target-independent code generator infrastructure now uses LLVM's
<a href="http://llvm.org/doxygen/classllvm_1_1APInt.html">APInt</a>
class to handle integer values, which allows it to support integer types
- larger than 64 bits. Note that support for such types is also dependent on
- target-specific support. Use of APInt is also a step toward support for
- non-power-of-2 integer sizes.</li>
+ larger than 64 bits (for example i128). Note that support for such types is
+ also dependent on target-specific support. Use of APInt is also a step
+ toward support for non-power-of-2 integer sizes.</li>
<li>LLVM 2.3 includes several compile time speedups for code with large basic
blocks, particularly in the instruction selection phase, register
allocation, scheduling, and tail merging/jump threading.</li>
-<li>Several improvements which make llc's <tt>--view-sunit-dags</tt>
- visualization of scheduling dependency graphs easier to understand.</li>
+<li>LLVM 2.3 includes several improvements which make llc's
+ <tt>--view-sunit-dags</tt> visualization of scheduling dependency graphs
+ easier to understand.</li>
<li>The code generator allows targets to write patterns that generate subreg
references directly in .td files now.</li>
'i' form when possible instead of always loading the value in a register.
This saves an instruction and reduces register use.</li>
-<li>Added support for PIC/GOT style tail calls on x86/32 and initial support
- for tail calls on PowerPC 32 (it may also work on ppc64 but not
- thoroughly tested).</li>
+<li>Added support for PIC/GOT style <a
+ href="CodeGenerator.html#tailcallopt">tail calls</a> on X86/32 and initial
+ support for tail calls on PowerPC 32 (it may also work on PowerPC 64 but is
+ not thoroughly tested).</li>
</ul>
</div>
now interoperates very well on X86-64 systems with other compilers.</li>
<li>Support for Win64 was added. This includes code generation itself, JIT
- support and necessary changes to llvm-gcc.</li>
+ support, and necessary changes to llvm-gcc.</li>
<li>The LLVM X86 backend now supports the support SSE 4.1 instruction set, and
the llvm-gcc 4.2 front-end supports the SSE 4.1 compiler builtins. Various
<li>The X86 backend now does a number of optimizations that aim to avoid
converting numbers back and forth from SSE registers to the X87 floating
- point stack.</li>
+ point stack. This is important because most X86 ABIs require return values
+ to be on the X87 Floating Point stack, but most CPUs prefer computation in
+ the SSE units.</li>
<li>The X86 backend supports stack realignment, which is particularly useful for
- vector code on OS's without 16-byte aligned stacks.</li>
+ vector code on OS's without 16-byte aligned stacks, such as Linux and
+ Windows.</li>
<li>The X86 backend now supports the "sseregparm" options in GCC, which allow
functions to be tagged as passing floating point values in SSE
<li><tt>__builtin_prefetch</tt> is now compiled into the appropriate prefetch
instructions instead of being ignored.</li>
-<li>128-bit integers are now supported on X86-64 targets.</li>
+<li>128-bit integers are now supported on X86-64 targets. This can be used
+ through <tt>__attribute__((TImode))</tt> in llvm-gcc.</li>
-<li>The register allocator can now rematerialize PIC-base computations.</li>
+<li>The register allocator can now rematerialize PIC-base computations, which is
+ an important optimization for register use.</li>
<li>The "t" and "f" inline assembly constraints for the X87 floating point stack
now work. However, the "u" constraint is still not fully supported.</li>
<ul>
<li>The LLVM C backend now supports vector code.</li>
+<li>The Cell SPU backend includes a number of improvements. It generates better
+ code and its stability/completeness is improving.</li>
</ul>
</div>
expect small issues to happen. Also, llvm-gcc cannot build mingw64 runtime
currently due
to <a href="http://llvm.org/PR2255">several</a>
- <a href="http://llvm.org/PR2257">bugs</a> in FP stackifier
+ <a href="http://llvm.org/PR2257">bugs</a> due to lack of support for the
+ 'u' inline assembly constraint and X87 floating point inline assembly.</li>
<li>The X86-64 backend does not yet support position-independent code (PIC)
generation on Linux targets.</li>
<li>The X86-64 backend does not yet support the LLVM IR instruction
<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>The Itanium backend has bitrotted somewhat.</li>
+<li>The Itanium backend is highly experimental, and has a number of known
+ issues. We are looking for a maintainer for the Itanium backend. If you
+ are interested, please contact the llvmdev mailing list.</li>
</ul>
</div>
<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-gcc does not currently support <a href="http://llvm.org/PR869">Link-Time
projects / oota-llvm.git / blobdiff