| blob | bdaba71b7430d341e663a0b1df71528fd743ff45 |
3 <html>
4 <head>
8 </head>
9 <body>
13 <ol>
22 </ol>
26 </div>
28 <!-- *********************************************************************** -->
31 </div>
32 <!-- *********************************************************************** -->
36 <p>This document contains the release notes for the LLVM Compiler
37 Infrastructure, release 2.5. Here we describe the status of LLVM, including
38 major improvements from the previous release and significant known problems.
39 All LLVM releases may be downloaded from the <a
42 <p>For more information about LLVM, including information about the latest
48 <p>Note that if you are reading this file from a Subversion checkout or the
50 current one. To see the release notes for a specific release, please see the
53 </div>
55 <!-- Unfinished features in 2.5:
56 Machine LICM
57 Machine Sinking
58 target-specific intrinsics
59 gold lto plugin
60 pre-alloc splitter, strong phi elim
61 <tt>llc -enable-value-prop</tt>, propagation of value info
62 (sign/zero ext info) from one MBB to another
63 debug info for optimized code
64 interpreter + libffi
65 postalloc scheduler: anti dependence breaking, hazard recognizer?
67 initial support for debug line numbers when optimization enabled, not useful in
68 2.5 but will be for 2.6.
70 -->
72 <!-- for announcement email:
73 -->
75 <!-- *********************************************************************** -->
78 </div>
79 <!-- *********************************************************************** -->
82 <p>
83 The LLVM 2.5 distribution currently consists of code from the core LLVM
84 repository —which roughly includes the LLVM optimizers, code generators
85 and supporting tools — and the llvm-gcc repository. In addition to this
86 code, the LLVM Project includes other sub-projects that are in development. The
89 </p>
91 </div>
94 <!--=========================================================================-->
97 </div>
102 a set of new 'LLVM native' front-end technologies for the LLVM optimizer and
103 code generator. While Clang is not included in the LLVM 2.5 release, it is
104 continuing to make major strides forward in all areas. Its C and Objective-C
105 parsing and code generation support is now very solid. For example, it is
106 capable of successfully building many real-world applications for X86-32
107 and X86-64,
111 and work on templates has recently started. If you are
112 interested in fast compiles and good diagnostics, we encourage you to try it out
114 and reporting any issues you hit to the <a
120 <ul>
121 <li>Clang now has a new driver, which is focused on providing a GCC-compatible
122 interface.</li>
127 many features, such as Objective-C Garbage Collection.</li>
130 <li>Clang now includes all major compiler headers, including a
133 </ul>
134 </div>
136 <!--=========================================================================-->
139 </div>
143 <p>Previously announced in the last LLVM release, the Clang project also
144 includes an early stage static source code analysis tool for <a
146 in C and Objective-C programs. The tool performs a growing set of checks to find
147 bugs that occur on a specific path within a program.</p>
150 the analyzer's core path simulation engine and machinery for generating
151 path-based bug reports to end-users. Particularly noteworthy improvements
152 include experimental support for full field-sensitivity and reasoning about heap
153 objects as well as an improved value-constraints subengine that does a much
155 between variables and constants.
157 <p>The set of checks performed by the static analyzer continues to expand, and
158 future plans for the tool include full source-level inter-procedural analysis
159 and deeper checks such as buffer overrun detection. There are many opportunities
160 to extend and enhance the static analyzer, and anyone interested in working on
161 this project is encouraged to get involved!</p>
163 </div>
165 <!--=========================================================================-->
168 </div>
171 <p>
173 a JVM and a CLI Virtual Machines (Microsoft .NET is an
174 implementation of the CLI) using the Just-In-Time compiler of LLVM.</p>
178 bug fixes, cleanup and new features. The major changes are:</p>
180 <ul>
182 <li>Ahead of Time compiler: compiles .class files to llvm .bc. VMKit uses this
183 functionality to native compile the standard classes (e.g. java.lang.String).
184 Users can compile AoT .class files into dynamic libraries and run them with the
185 help of VMKit.</li>
187 <li>New exception model: the dwarf exception model is very slow for
188 exception-intensive applications, so the JVM has had a new implementation of
189 exceptions which check at each function call if an exception happened. There is
190 a low performance penalty on applications without exceptions, but it is a big
191 gain for exception-intensive applications. For example the jack benchmark in
194 <li>User-level management of thread stacks, so that thread local data access
195 at runtime is fast and portable. </li>
197 <li>Implementation of biased locking for faster object synchronizations at
198 runtime.</li>
202 </ul>
203 </div>
205 <!-- *********************************************************************** -->
208 </div>
209 <!-- *********************************************************************** -->
211 <!--=========================================================================-->
214 </div>
217 <p>
219 is an algebraic/functional programming language based on term rewriting.
220 Programs are collections of equations which are used to evaluate expressions in
221 a symbolic fashion. Pure offers dynamic typing, eager and lazy evaluation,
222 lexical closures, a hygienic macro system (also based on term rewriting),
223 built-in list and matrix support (including list and matrix comprehensions) and
224 an easy-to-use C interface. The interpreter uses LLVM as a backend to
225 JIT-compile Pure programs to fast native code.</p>
227 <p>In addition to the usual algebraic data structures, Pure also has
228 MATLAB-style matrices in order to support numeric computations and signal
229 processing in an efficient way. Pure is mainly aimed at mathematical
230 applications right now, but it has been designed as a general purpose language.
231 The dynamic interpreter environment and the C interface make it possible to use
232 it as a kind of functional scripting language for many application areas.
233 </p>
234 </div>
237 <!--=========================================================================-->
240 </div>
243 <p>
245 the D Programming Language using the LLVM optimizer and code generator.
246 The LDC project works great with the LLVM 2.5 release. General improvements in
247 this
248 cycle have included new inline asm constraint handling, better debug info
249 support, general bugfixes, and better x86-64 support. This has allowed
250 some major improvements in LDC, getting us much closer to being as
251 fully featured as the original DMD compiler from DigitalMars.
252 </p>
253 </div>
255 <!--=========================================================================-->
258 </div>
262 source implementation of the PHP programming
263 language that uses LLVM for its optimizer, JIT, and static compiler. This is a
264 reimplementation of an earlier project that is now based on LLVM.</p>
265 </div>
268 <!-- *********************************************************************** -->
271 </div>
272 <!-- *********************************************************************** -->
276 <p>This release includes a huge number of bug fixes, performance tweaks, and
277 minor improvements. Some of the major improvements and new features are listed
278 in this section.
279 </p>
280 </div>
282 <!--=========================================================================-->
285 </div>
291 <ul>
295 <li>llvm-gcc now generally supports the GFortran front-end, and the precompiled
296 release binaries now support Fortran, even on Mac OS/X.</li>
299 on Windows</a>. It automatically generates Visual Studio project files (and
300 more) from a set of simple text files. This makes it much easier to
301 maintain. In time, we'd like to standardize on CMake for everything.</li>
305 <li>The LLVM native code generator now supports arbitrary precision integers.
307 only supported by the interpreter. Note that the C backend still does not
308 support these.</li>
311 </ul>
313 </div>
316 <!--=========================================================================-->
319 </div>
324 front-ends and driver with the LLVM optimizer and code generator. It currently
325 includes support for the C, C++, Objective-C, Ada, and Fortran front-ends.</p>
327 <ul>
328 <li>In this release, the GCC inliner is completely disabled. Previously the GCC
329 inliner was used to handle always-inline functions and other cases. This caused
330 problems with code size growth, and it is completely disabled in this
331 release.</li>
333 <li>llvm-gcc (and LLVM in general) now support code generation for stack
334 canaries, which is an effective form of <a
337 command line option (just like GCC). In LLVM IR, you can request code
338 generation for stack canaries with function attributes.
339 </li>
340 </ul>
342 </div>
345 <!--=========================================================================-->
348 </div>
351 <p>LLVM IR has several new features that are used by our existing front-ends and
352 can be useful if you are writing a front-end for LLVM:</p>
354 <ul>
356 has been generalized to allow different shuffle mask width than its input
357 vectors. This allows you to use shufflevector to combine two
362 efficient code generation for languages that must trap or throw an exception on
363 overflow. While these intrinsics work on all targets, they only generate
364 efficient code on X86 so far.</li>
367 linkage</a> type to produce labels that are stripped by the assembler before it
368 produces a .o file (thus they are invisible to the linker).</li>
372 return value of a function to indicate that it returns new memory (e.g.
373 'malloc', 'calloc', etc).
375 on pointer arguments to indicate that the function does not return the pointer,
376 store it in an object that outlives the call, or let the value of the pointer
377 escape from the function in any other way.
378 Note that it is the pointer itself that must not escape, not the value it
379 points to: loading a value out of the pointer is perfectly fine.
380 Many standard library functions (e.g. 'strlen', 'memcpy') have this property.
381 <!-- The simplifylibcalls pass applies these attributes to standard libc functions. -->
382 </li>
385 recursive descent parser. This parser produces better error messages (including
386 caret diagnostics), is less fragile (less likely to crash on strange things),
387 does not leak memory, is more efficient, and eliminates LLVM's last use of the
388 'bison' tool.</li>
390 <li>Debug information representation and manipulation internals have been
391 consolidated to use a new set of classes in
393 efficient, robust, and extensible and replace the older mechanisms.
394 llvm-gcc, clang, and the code generator now use them to create and process
395 debug information.</li>
397 </ul>
399 </div>
401 <!--=========================================================================-->
404 </div>
408 <p>In addition to a large array of bug fixes and minor performance tweaks, this
409 release includes a few major enhancements and additions to the optimizers:</p>
411 <ul>
413 <li>The loop optimizer now improves floating point induction variables in
414 several ways, including adding shadow induction variables to avoid
420 and handles threading based on values with fully and partially redundant
421 loads.</li>
424 both faster and more aggressive.</li>
427 about promoting unions to registers.</li>
429 </ul>
431 </div>
433 <!--=========================================================================-->
436 </div>
440 <p>We have put a significant amount of work into the code generator
441 infrastructure, which allows us to implement more aggressive algorithms and make
442 it run faster:</p>
444 <ul>
446 Backend</a> document has been greatly expanded and is substantially more
447 complete.</li>
449 <li>The SelectionDAG type legalization logic has been completely rewritten, is
450 now more powerful (it supports arbitrary precision integer types for example),
451 and is more correct in several corner cases. The type legalizer converts
452 operations on types that are not natively supported by the target machine into
453 equivalent code sequences that only use natively supported types. The old type
454 legalizer is still available (for now) and will be used if
456 </li>
458 <li>The code generator now supports widening illegal vectors to larger legal
461 applications.</li>
463 <li>The assembly printers for each target are now split out into their own
464 libraries that are separate from the main code generation logic. This reduces
465 the code size of JIT compilers by not requiring them to be linked in.</li>
467 <li>The 'fast' instruction selection path (used at -O0 and for fast JIT
468 compilers) now supports accelerating codegen for code that uses exception
469 handling constructs.</li>
472 </ul>
473 </div>
475 <!--=========================================================================-->
478 </div>
481 <p>New features of the X86 target include:
482 </p>
484 <ul>
487 supports non-zero stack depths on X86.</li>
489 <li>The X86 backend now supports code generation of vector shift operations
490 using SSE instructions.</li>
496 performing memory references off the GS segment register. This allows a
497 front-end to take advantage of very low-level programming techniques when
499 example.</li>
502 prevent use of MMX even on chips that support it. This is important for cases
504 intrinsics.</li>
509 auto-configures itself appropriately for the features of these chips.</li>
516 </ul>
518 </div>
520 <!--=========================================================================-->
523 </div>
526 <p>New features of the PIC16 target include:
527 </p>
529 <ul>
531 <li>Logical, bitwise and conditional operations now work for integer data
532 types.</li>
535 <li>The compiler can now emit libcalls for operations not supported by m/c
536 instructions.</li>
538 </ul>
542 <ul>
549 </ul>
551 </div>
554 <!--=========================================================================-->
557 </div>
562 <ul>
566 <li>The Clang plugin was substantially improved and is now enabled
571 common errors like multiple default edges, mismatched output/input language
572 names and cycles. In general, these checks can't be done at compile-time
573 because of the need to support plugins.</li>
575 <li>Plugins are now more flexible and can refer to compilation graph nodes and
576 options defined in other plugins. To manage dependencies, a priority-sorting
577 mechanism was introduced. This change affects the TableGen file syntax. See the
578 documentation for details.</li>
583 <li>A new option type: multi-valued option, for options that take more than one
592 <li>Documentation now looks more consistent to the rest of the LLVM
593 docs. There is also a man page now.</li>
595 </ul>
597 </div>
600 <!--=========================================================================-->
603 </div>
607 <p>If you're already an LLVM user or developer with out-of-tree changes based
609 from the previous release.</p>
611 <ul>
615 </ul>
618 <p>In addition, many APIs have changed in this release. Some of the major LLVM
619 API changes are:</p>
621 <ul>
624 </ul>
626 </div>
630 <!-- *********************************************************************** -->
633 </div>
634 <!-- *********************************************************************** -->
640 <ul>
642 Linux, Fedora Core and FreeBSD (and probably other unix-like systems).</li>
646 <li>Intel and AMD machines running on Win32 with the Cygwin libraries (limited
647 support is available for native builds with Visual C++).</li>
651 </ul>
653 <p>The core LLVM infrastructure uses GNU autoconf to adapt itself
654 to the machine and operating system on which it is built. However, minor
655 porting may be required to get LLVM to work on new platforms. We welcome your
656 portability patches and reports of successful builds or error messages.</p>
658 </div>
660 <!-- *********************************************************************** -->
663 </div>
664 <!-- *********************************************************************** -->
668 <p>This section contains significant known problems with the LLVM system,
669 listed by component. If you run into a problem, please check the <a
671 there isn't already one.</p>
673 </div>
675 <!-- ======================================================================= -->
678 </div>
682 <p>The following components of this LLVM release are either untested, known to
683 be broken or unreliable, or are in early development. These components should
684 not be relied on, and bugs should not be filed against them, but they may be
685 useful to some people. In particular, if you would like to work on one of these
686 components, please contact us on the <a
689 <ul>
692 supported value for this option.</li>
693 </ul>
695 </div>
697 <!-- ======================================================================= -->
700 </div>
704 <ul>
705 <li>The X86 backend does not yet support
707 floating point stack</a>. It supports the 'f' and 't' constraints, but not
708 'u'.</li>
709 <li>The X86 backend generates inefficient floating point code when configured
710 to generate code for systems that don't have SSE2.</li>
711 <li>Win64 code generation wasn't widely tested. Everything should work, but we
712 expect small issues to happen. Also, llvm-gcc cannot build the mingw64
713 runtime currently due
716 the
717 'u' inline assembly constraint and for X87 floating point inline assembly.</li>
721 </ul>
723 </div>
725 <!-- ======================================================================= -->
728 </div>
732 <ul>
733 <li>The Linux PPC32/ABI support needs testing for the interpreter and static
734 compilation, and lacks support for debug information.</li>
735 </ul>
737 </div>
739 <!-- ======================================================================= -->
742 </div>
746 <ul>
747 <li>Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6
748 processors, thumb programs can crash or produce wrong
750 <li>Compilation for ARM Linux OABI (old ABI) is supported but not fully tested.
751 </li>
753 execute
754 programs compiled with LLVM. Please use more recent versions of QEMU.</li>
755 </ul>
757 </div>
759 <!-- ======================================================================= -->
762 </div>
766 <ul>
769 </ul>
771 </div>
773 <!-- ======================================================================= -->
776 </div>
780 <ul>
783 </ul>
785 </div>
787 <!-- ======================================================================= -->
790 </div>
794 <ul>
797 appropriate nops inserted to ensure restartability.</li>
799 </ul>
800 </div>
802 <!-- ======================================================================= -->
805 </div>
809 <ul>
810 <li>The Itanium backend is highly experimental and has a number of known
811 issues. We are looking for a maintainer for the Itanium backend. If you
812 are interested, please contact the LLVMdev mailing list.</li>
813 </ul>
815 </div>
817 <!-- ======================================================================= -->
820 </div>
824 <ul>
828 C++ programs</a>, preventing intermixing between C++ compiled by the CBE and
832 </ul>
834 </div>
837 <!-- ======================================================================= -->
840 </div>
846 LLVMdev mailing list if you are interested.</p>
848 <p>The only major language feature of GCC not supported by llvm-gcc is
850 are only supported on some targets. For example, trampolines are only
851 supported on some targets (these are used when you take the address of a
852 nested function).</p>
854 <p>If you run into GCC extensions which are not supported, please let us know.
855 </p>
857 </div>
859 <!-- ======================================================================= -->
862 </div>
866 <p>The C++ front-end is considered to be fully
867 tested and works for a number of non-trivial programs, including LLVM
868 itself, Qt, Mozilla, etc.</p>
870 <ul>
871 <li>Exception handling works well on the X86 and PowerPC targets. Currently
873 </ul>
875 </div>
877 <!-- ======================================================================= -->
880 </div>
883 <ul>
884 <li>Fortran support generally works, but there are still several unresolved bugs
885 in Bugzilla. Please see the tools/gfortran component for details.</li>
886 </ul>
887 </div>
889 <!-- ======================================================================= -->
892 </div>
895 The llvm-gcc 4.2 Ada compiler works fairly well; however, this is not a mature
896 technology, and problems should be expected.
897 <ul>
899 to lack of trampoline support (pointers to nested functions) on other platforms.
901 which does support trampolines.</li>
904 exception handling, which is used internally by the compiler.
905 Workaround: configure with --disable-bootstrap.</li>
908 (c380004 also fails with gcc-4.2 mainline).
910 causes the compiler to go into an infinite loop, using up all system memory.</li>
912 <li>The -E binder option (exception backtraces)
914 crashing if an exception is raised. Workaround: do not use -E.</li>
916 or finish at a non-byte offset</a> in a record. Workaround: do not pack records
917 or use representation clauses that result in a field of a non-discrete type
918 starting or finishing in the middle of a byte.</li>
920 'main' as generated by the Ada binder to be invalid</a>.
925 </ul>
926 </div>
928 <!-- *********************************************************************** -->
931 </div>
932 <!-- *********************************************************************** -->
939 contains versions of the API documentation which is up-to-date with the
940 Subversion version of the source code.
941 You can access versions of these documents specific to this release by going
944 <p>If you have any questions or comments about LLVM, please feel free to contact
948 </div>
950 <!-- *********************************************************************** -->
952 <hr>
953 <address>
960 Last modified: $Date$
961 </address>
963 </body>
964 </html>