ReleaseNotes.html - OpenGrok cross reference for /external/swiftshader/third_party/LLVM/docs/ReleaseNotes.html

1<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
2                      "http://www.w3.org/TR/html4/strict.dtd">
3<html>
4<head>
5  <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
6  <link rel="stylesheet" href="llvm.css" type="text/css">
7  <title>LLVM 3.0 Release Notes</title>
8</head>
9<body>
10
11<h1>LLVM 3.0 Release Notes</h1>
12
13<img align=right src="http://llvm.org/img/DragonSmall.png"
14    width="136" height="136" alt="LLVM Dragon Logo">
15
16<ol>
17  <li><a href="#intro">Introduction</a></li>
18  <li><a href="#subproj">Sub-project Status Update</a></li>
19  <li><a href="#externalproj">External Projects Using LLVM 3.0</a></li>
20  <li><a href="#whatsnew">What's New in LLVM 3.0?</a></li>
21  <li><a href="GettingStarted.html">Installation Instructions</a></li>
22  <li><a href="#knownproblems">Known Problems</a></li>
23  <li><a href="#additionalinfo">Additional Information</a></li>
24</ol>
25
26<div class="doc_author">
27  <p>Written by the <a href="http://llvm.org/">LLVM Team</a></p>
28</div>
29
30
37
38
39<h2>
40  <a name="intro">Introduction</a>
41</h2>
42
43
44<div>
45
46<p>This document contains the release notes for the LLVM Compiler
47   Infrastructure, release 3.0.  Here we describe the status of LLVM, including
48   major improvements from the previous release and significant known problems.
49   All LLVM releases may be downloaded from
50   the <a href="http://llvm.org/releases/">LLVM releases web site</a>.</p>
51
52<p>For more information about LLVM, including information about the latest
53   release, please check out the <a href="http://llvm.org/">main LLVM web
54   site</a>.  If you have questions or comments,
55   the <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVM
56   Developer's Mailing List</a> is a good place to send them.</p>
57
58<p>Note that if you are reading this file from a Subversion checkout or the main
59   LLVM web page, this document applies to the <i>next</i> release, not the
60   current one.  To see the release notes for a specific release, please see the
61   <a href="http://llvm.org/releases/">releases page</a>.</p>
62
63</div>
64
65
73
74
75<h2>
76  <a name="subproj">Sub-project Status Update</a>
77</h2>
78
79
80<div>
81
82<p>The LLVM 3.0 distribution currently consists of code from the core LLVM
83   repository (which roughly includes the LLVM optimizers, code generators and
84   supporting tools), the Clang repository and the llvm-gcc repository.  In
85   addition to this code, the LLVM Project includes other sub-projects that are
86   in development.  Here we include updates on these subprojects.</p>
87
88
89<h3>
90<a name="clang">Clang: C/C++/Objective-C Frontend Toolkit</a>
91</h3>
92
93<div>
94
95<p><a href="http://clang.llvm.org/">Clang</a> is an LLVM front end for the C,
96   C++, and Objective-C languages. Clang aims to provide a better user
97   experience through expressive diagnostics, a high level of conformance to
98   language standards, fast compilation, and low memory use. Like LLVM, Clang
99   provides a modular, library-based architecture that makes it suitable for
100   creating or integrating with other development tools. Clang is considered a
101   production-quality compiler for C, Objective-C, C++ and Objective-C++ on x86
102   (32- and 64-bit), and for darwin/arm targets.</p>
103
104<p>In the LLVM 3.0 time-frame, the Clang team has made many improvements:</p>
105
106<ul>
107  <li>Greatly improved support for building C++ applications, with greater
108      stability and better diagnostics.</li>
109
110  <li><a href="http://clang.llvm.org/cxx_status.html">Improved support</a> for
111      the <a href="http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50372">C++
112      2011</a> standard, including implementations of non-static data member
113      initializers, alias templates, delegating constructors, the range-based
114      for loop, and implicitly-generated move constructors and move assignment
115      operators, among others.</li>
116
117  <li>Implemented support for some features of the upcoming C1x standard,
118      including static assertions and generic selections.</li>
119
120  <li>Better detection of include and linking paths for system headers and
121      libraries, especially for Linux distributions.</li>
122
123  <li>Implemented support
124      for <a href="http://clang.llvm.org/docs/AutomaticReferenceCounting.html">Automatic
125      Reference Counting</a> for Objective-C.</li>
126
127  <li>Implemented a number of optimizations in <tt>libclang</tt>, the Clang C
128      interface, to improve the performance of code completion and the mapping
129      from source locations to abstract syntax tree nodes.</li>
130</ul>
131
132
133<p>If Clang rejects your code but another compiler accepts it, please take a
134   look at the <a href="http://clang.llvm.org/compatibility.html">language
135   compatibility</a> guide to make sure this is not intentional or a known
136   issue.</p>
137
138</div>
139
140
141<h3>
142<a name="dragonegg">DragonEgg: GCC front-ends, LLVM back-end</a>
143</h3>
144
145<div>
146<p><a href="http://dragonegg.llvm.org/">DragonEgg</a> is a
147   <a href="http://gcc.gnu.org/wiki/plugins">gcc plugin</a> that replaces GCC's
148   optimizers and code generators with LLVM's. Currently it requires a patched
149   version of gcc-4.5.  The plugin can target the x86-32 and x86-64 processor
150   families and has been used successfully on the Darwin, FreeBSD and Linux
151   platforms.  The Ada, C, C++ and Fortran languages work well.  The plugin is
152   capable of compiling plenty of Obj-C, Obj-C++ and Java but it is not known
153   whether the compiled code actually works or not!</p>
154
155<p>The 3.0 release has the following notable changes:</p>
156
157<ul>
158
161</ul>
162
163</div>
164
165
166<h3>
167<a name="compiler-rt">compiler-rt: Compiler Runtime Library</a>
168</h3>
169
170<div>
171
172<p>The new LLVM <a href="http://compiler-rt.llvm.org/">compiler-rt project</a>
173   is a simple library that provides an implementation of the low-level
174   target-specific hooks required by code generation and other runtime
175   components.  For example, when compiling for a 32-bit target, converting a
176   double to a 64-bit unsigned integer is compiled into a runtime call to the
177   "__fixunsdfdi" function. The compiler-rt library provides highly optimized
178   implementations of this and other low-level routines (some are 3x faster than
179   the equivalent libgcc routines).</p>
180
181<p>In the LLVM 3.0 timeframe,</p>
182
183</div>
184
185
186<h3>
187<a name="lldb">LLDB: Low Level Debugger</a>
188</h3>
189
190<div>
191
192<p>LLDB has advanced by leaps and bounds in the 3.0 timeframe.  It is
193   dramatically more stable and useful, and includes both a
194   new <a href="http://lldb.llvm.org/tutorial.html">tutorial</a> and
195   a <a href="http://lldb.llvm.org/lldb-gdb.html">side-by-side comparison with
196   GDB</a>.</p>
197
198</div>
199
200
201<h3>
202<a name="libc++">libc++: C++ Standard Library</a>
203</h3>
204
205<div>
206
207<p>Like compiler_rt, libc++ is now <a href="DeveloperPolicy.html#license">dual
208   licensed</a> under the MIT and UIUC license, allowing it to be used more
209   permissively.</p>
210
211</div>
212
213
214
215<h3>
216<a name="LLBrowse">LLBrowse: IR Browser</a>
217</h3>
218
219<div>
220
221<p><a href="http://llvm.org/svn/llvm-project/llbrowse/trunk/doc/LLBrowse.html">
222   LLBrowse</a> is an interactive viewer for LLVM modules. It can load any LLVM
223   module and displays its contents as an expandable tree view, facilitating an
224   easy way to inspect types, functions, global variables, or metadata nodes. It
225   is fully cross-platform, being based on the popular wxWidgets GUI
226   toolkit.</p>
227
228</div>
229
230
231<h3>
232<a name="vmkit">VMKit</a>
233</h3>
234
235<div>
236
237<p>The <a href="http://vmkit.llvm.org/">VMKit project</a> is an implementation
238   of a Java Virtual Machine (Java VM or JVM) that uses LLVM for static and
239   just-in-time compilation. As of LLVM 3.0, VMKit now supports generational
240   garbage collectors. The garbage collectors are provided by the MMTk
241   framework, and VMKit can be configured to use one of the numerous implemented
242   collectors of MMTk.</p>
243
244</div>
245
246
247
248
264
265</div>
266
267
268<h2>
269  <a name="externalproj">External Open Source Projects Using LLVM 3.0</a>
270</h2>
271
272
273<div>
274
275<p>An exciting aspect of LLVM is that it is used as an enabling technology for
276   a lot of other language and tools projects.  This section lists some of the
277   projects that have already been updated to work with LLVM 3.0.</p>
278
279
280<h3>AddressSanitizer</h3>
281
282<div>
283
284<p><a href="http://code.google.com/p/address-sanitizer/">AddressSanitizer</a>
285   uses compiler instrumentation and a specialized malloc library to find C/C++
286   bugs such as use-after-free and out-of-bound accesses to heap, stack, and
287   globals. The key feature of the tool is speed: the average slowdown
288   introduced by AddressSanitizer is less than 2x.</p>
289
290</div>
291
292
293<h3>ClamAV</h3>
294
295<div>
296
297<p><a href="http://www.clamav.net">Clam AntiVirus</a> is an open source (GPL)
298   anti-virus toolkit for UNIX, designed especially for e-mail scanning on mail
299   gateways.</p>
300
301<p>Since version 0.96 it
302   has <a href="http://vrt-sourcefire.blogspot.com/2010/09/introduction-to-clamavs-low-level.html">bytecode
303   signatures</a> that allow writing detections for complex malware.</p>
304
305<p>It uses LLVM's JIT to speed up the execution of bytecode on X86, X86-64,
306   PPC32/64, falling back to its own interpreter otherwise.  The git version was
307   updated to work with LLVM 3.0.</p>
308
309</div>
310
311
312<h3>clReflect</h3>
313
314<div>
315
316<p><a href="https://bitbucket.org/dwilliamson/clreflect">clReflect</a> is a C++
317   parser that uses clang/LLVM to derive a light-weight reflection database
318   suitable for use in game development. It comes with a very simple runtime
319   library for loading and querying the database, requiring no external
320   dependencies (including CRT), and an additional utility library for object
321   management and serialisation.</p>
322
323</div>
324
325
326<h3>Cling C++ Interpreter</h3>
327
328<div>
329
330<p><a href="http://cern.ch/cling">Cling</a> is an interactive compiler interface
331   (aka C++ interpreter). It uses LLVM's JIT and clang; it currently supports
332   C++ and C. It has a prompt interface, runs source files, calls into shared
333   libraries, prints the value of expressions, even does runtime lookup of
334   identifiers (dynamic scopes). And it just behaves like one would expect from
335   an interpreter.</p>
336
337</div>
338
339
340
351
352
353<h3>Glasgow Haskell Compiler (GHC)</h3>
354
355<div>
356
357<p>GHC is an open source, state-of-the-art programming suite for Haskell, a
358   standard lazy functional programming language. It includes an optimizing
359   static compiler generating good code for a variety of platforms, together
360   with an interactive system for convenient, quick development.</p>
361
362<p>GHC 7.0 and onwards include an LLVM code generator, supporting LLVM 2.8 and
363   later. Since LLVM 2.9, GHC now includes experimental support for the ARM
364   platform with LLVM 3.0.</p>
365
366</div>
367
368
369<h3>gwXscript</h3>
370
371<div>
372
373<p><a href="http://botwars.tk/gwscript/">gwXscript</a> is an object oriented,
374   aspect oriented programming language which can create both executables (ELF,
375   EXE) and shared libraries (DLL, SO, DYNLIB). The compiler is implemented in
376   its own language and translates scripts into LLVM-IR which can be optimized
377   and translated into native code by the LLVM framework. Source code in
378   gwScript contains definitions that expand the namespaces. So you can build
379   your project and simply 'plug out' features by removing a file. The remaining
380   project does not leave scars since you directly separate concerns by the
381   'template' feature of gwX. It is also possible to add new features to a
382   project by just adding files and without editing the original project. This
383   language is used for example to create games or content management systems
384   that should be extendable.</p>
385
386<p>gwXscript is strongly typed and offers comfort with its native types string,
387   hash and array. You can easily write new libraries in gwXscript or native
388   code. gwXscript is type safe and users should not be able to crash your
389   program or execute malicious code except code that is eating CPU time.</p>
390
391</div>
392
393
394<h3>include-what-you-use</h3>
395
396<div>
397
398<p><a href="http://code.google.com/p/include-what-you-use">include-what-you-use</a>
399   is a tool to ensure that a file directly <code>#include</code>s
400   all <code>.h</code> files that provide a symbol that the file uses. It also
401   removes superfluous <code>#include</code>s from source files.</p>
402
403</div>
404
405
406<h3>LanguageKit and Pragmatic Smalltalk</h3>
407
408<div>
409
410<p><a href="http://etoileos.com/etoile/features/languagekit/">LanguageKit</a> is
411   a framework for implementing dynamic languages sharing an object model with
412   Objective-C. It provides static and JIT compilation using LLVM along with
413   its own interpreter. Pragmatic Smalltalk is a dialect of Smalltalk, built on
414   top of LanguageKit, that interfaces directly with Objective-C, sharing the
415   same object representation and message sending behaviour. These projects are
416   developed as part of the &Eacute;toi&eacute; desktop environment.</p>
417
418</div>
419
420
421<h3>LuaAV</h3>
422
423<div>
424
425<p><a href="http://lua-av.mat.ucsb.edu/blog/">LuaAV</a> is a real-time
426   audiovisual scripting environment based around the Lua language and a
427   collection of libraries for sound, graphics, and other media protocols. LuaAV
428   uses LLVM and Clang to JIT compile efficient user-defined audio synthesis
429   routines specified in a declarative syntax.</p>
430
431</div>
432
433
434<h3>Mono</h3>
435
436<div>
437
438<p>An open source, cross-platform implementation of C# and the CLR that is
439   binary compatible with Microsoft.NET. Has an optional, dynamically-loaded
440   LLVM code generation backend in Mini, the JIT compiler.</p>
441
442<p>Note that we use a Git mirror of LLVM with some patches. See:
443   https://github.com/mono/llvm</p>
444
445</div>
446
447
448<h3>Portable OpenCL (pocl)</h3>
449
450<div>
451
452<p>Portable OpenCL is an open source implementation of the OpenCL standard which
453   can be easily adapted for new targets. One of the goals of the project is
454   improving performance portability of OpenCL programs, avoiding the need for
455   target-dependent manual optimizations. A "native" target is included, which
456   allows running OpenCL kernels on the host (CPU).</p>
457
458</div>
459
460
461<h3>Pure</h3>
462
463<div>
464<p><a href="http://pure-lang.googlecode.com/">Pure</a> is an
465  algebraic/functional programming language based on term rewriting. Programs
466  are collections of equations which are used to evaluate expressions in a
467  symbolic fashion. The interpreter uses LLVM as a backend to JIT-compile Pure
468  programs to fast native code. Pure offers dynamic typing, eager and lazy
469  evaluation, lexical closures, a hygienic macro system (also based on term
470  rewriting), built-in list and matrix support (including list and matrix
471  comprehensions) and an easy-to-use interface to C and other programming
472  languages (including the ability to load LLVM bitcode modules, and inline C,
473  C++, Fortran and Faust code in Pure programs if the corresponding LLVM-enabled
474  compilers are installed).</p>
475
476<p>Pure version 0.48 has been tested and is known to work with LLVM 3.0
477  (and continues to work with older LLVM releases &gt;= 2.5).</p>
478
479</div>
480
481
482<h3>Renderscript</h3>
483
484<div>
485
486<p><a href="http://developer.android.com/guide/topics/renderscript/index.html">Renderscript</a>
487   is Android's advanced 3D graphics rendering and compute API. It provides a
488   portable C99-based language with extensions to facilitate common use cases
489   for enhancing graphics and thread level parallelism. The Renderscript
490   compiler frontend is based on Clang/LLVM. It emits a portable bitcode format
491   for the actual compiled script code, as well as reflects a Java interface for
492   developers to control the execution of the compiled bitcode. Executable
493   machine code is then generated from this bitcode by an LLVM backend on the
494   device. Renderscript is thus able to provide a mechanism by which Android
495   developers can improve performance of their applications while retaining
496   portability.</p>
497
498</div>
499
500
501<h3>SAFECode</h3>
502
503<div>
504
505<p><a href="http://safecode.cs.illinois.edu">SAFECode</a> is a memory safe C/C++
506   compiler built using LLVM.  It takes standard, unannotated C/C++ code,
507   analyzes the code to ensure that memory accesses and array indexing
508   operations are safe, and instruments the code with run-time checks when
509   safety cannot be proven statically.  SAFECode can be used as a debugging aid
510   (like Valgrind) to find and repair memory safety bugs.  It can also be used
511   to protect code from security attacks at run-time.</p>
512
513</div>
514
515
516<h3>The Stupid D Compiler (SDC)</h3>
517
518<div>
519
520<p><a href="https://github.com/bhelyer/SDC">The Stupid D Compiler</a> is a
521   project seeking to write a self-hosting compiler for the D programming
522   language without using the frontend of the reference compiler (DMD).</p>
523
524</div>
525
526
527<h3>TTA-based Co-design Environment (TCE)</h3>
528
529<div>
530
531<p>TCE is a toolset for designing application-specific processors (ASP) based on
532   the Transport triggered architecture (TTA). The toolset provides a complete
533   co-design flow from C/C++ programs down to synthesizable VHDL and parallel
534   program binaries. Processor customization points include the register files,
535   function units, supported operations, and the interconnection network.</p>
536
537<p>TCE uses Clang and LLVM for C/C++ language support, target independent
538   optimizations and also for parts of code generation. It generates new
539   LLVM-based code generators "on the fly" for the designed TTA processors and
540   loads them in to the compiler backend as runtime libraries to avoid
541   per-target recompilation of larger parts of the compiler chain.</p>
542
543</div>
544
545
546<h3>Tart Programming Language</h3>
547
548<div>
549
550<p><a href="http://code.google.com/p/tart/">Tart</a> is a general-purpose,
551   strongly typed programming language designed for application
552   developers. Strongly inspired by Python and C#, Tart focuses on practical
553   solutions for the professional software developer, while avoiding the clutter
554   and boilerplate of legacy languages like Java and C++. Although Tart is still
555   in development, the current implementation supports many features expected of
556   a modern programming language, such as garbage collection, powerful
557   bidirectional type inference, a greatly simplified syntax for template
558   metaprogramming, closures and function literals, reflection, operator
559   overloading, explicit mutability and immutability, and much more. Tart is
560   flexible enough to accommodate a broad range of programming styles and
561   philosophies, while maintaining a strong commitment to simplicity, minimalism
562   and elegance in design.</p>
563
564</div>
565
566
567<h3>ThreadSanitizer</h3>
568
569<div>
570
571<p><a href="http://code.google.com/p/data-race-test/">ThreadSanitizer</a> is a
572   data race detector for (mostly) C and C++ code, available for Linux, Mac OS
573   and Windows. On different systems, we use binary instrumentation frameworks
574   (Valgrind and Pin) as frontends that generate the program events for the race
575   detection algorithm. On Linux, there's an option of using LLVM-based
576   compile-time instrumentation.</p>
577
578</div>
579
580
581<h3>The ZooLib C++ Cross-Platform Application Framework</h3>
582
583<div>
584
585<p><a href="http://www.zoolib.org/">ZooLib</a> is Open Source under the MIT
586   License. It provides GUI, filesystem access, TCP networking, thread-safe
587   memory management, threading and locking for Mac OS X, Classic Mac OS,
588   Microsoft Windows, POSIX operating systems with X11, BeOS, Haiku, Apple's iOS
589   and Research in Motion's BlackBerry.</p>
590
591<p>My current work is to use CLang's static analyzer to improve ZooLib's code
592   quality.  I also plan to set up LLVM compiles of the demo programs and test
593   programs using CLang and LLVM on all the platforms that CLang, LLVM and
594   ZooLib all support.</p>
595
596</div>
597
598
599
610
611
612
613
632
633
634
649
650
651
663
664
665
680
681</div>
682
683
684<h2>
685  <a name="whatsnew">What's New in LLVM 3.0?</a>
686</h2>
687
688
689<div>
690
691<p>This release includes a huge number of bug fixes, performance tweaks and
692   minor improvements.  Some of the major improvements and new features are
693   listed in this section.</p>
694
695
696<h3>
697<a name="majorfeatures">Major New Features</a>
698</h3>
699
700<div>
701
702<p>LLVM 3.0 includes several major new capabilities:</p>
703
704<ul>
705
706
709
710</ul>
711
712</div>
713
714
715<h3>
716<a name="coreimprovements">LLVM IR and Core Improvements</a>
717</h3>
718
719<div>
720
721<p>LLVM IR has several new features for better support of new targets and that
722   expose new optimization opportunities:</p>
723
724<p>One of the biggest changes is that 3.0 has a new exception handling
725   system. The old system used LLVM intrinsics to convey the exception handling
726   information to the code generator. It worked in most cases, but not
727   all. Inlining was especially difficult to get right. Also, the intrinsics
728   could be moved away from the <code>invoke</code> instruction, making it hard
729   to recover that information.</p>
730
731<p>The new EH system makes exception handling a first-class member of the IR. It
732   adds two new instructions:</p>
733
734<ul>
735  <li><a href="LangRef.html#i_landingpad"><code>landingpad</code></a> &mdash;
736      this instruction defines a landing pad basic block. It contains all of the
737      information that's needed by the code generator. It's also required to be
738      the first non-PHI instruction in the landing pad. In addition, a landing
739      pad may be jumped to only by the unwind edge of an <code>invoke</code>
740      instruction.</li>
741
742  <li><a href="LangRef.html#i_resume"><code>resume</code></a> &mdash; this
743      instruction causes the current exception to resume traveling up the
744      stack. It replaces the <code>@llvm.eh.resume</code> intrinsic.</li>
745</ul>
746
747<p>Converting from the old EH API to the new EH API is rather simple, because a
748   lot of complexity has been removed. The two intrinsics,
749   <code>@llvm.eh.exception</code> and <code>@llvm.eh.selector</code> have been
750   superceded by the <code>landingpad</code> instruction. Instead of generating
751   a call to <code>@llvm.eh.exception</code> and <code>@llvm.eh.selector</code>:
752
753<div class="doc_code">
754<pre>
755Function *ExcIntr = Intrinsic::getDeclaration(TheModule,
756                                              Intrinsic::eh_exception);
757Function *SlctrIntr = Intrinsic::getDeclaration(TheModule,
758                                                Intrinsic::eh_selector);
759
760// The exception pointer.
761Value *ExnPtr = Builder.CreateCall(ExcIntr, "exc_ptr");
762
763std::vector&lt;Value*&gt; Args;
764Args.push_back(ExnPtr);
765Args.push_back(Builder.CreateBitCast(Personality,
766                                     Type::getInt8PtrTy(Context)));
767
768<i>// Add selector clauses to Args.</i>
769
770// The selector call.
771Builder.CreateCall(SlctrIntr, Args, "exc_sel");
772</pre>
773</div>
774
775<p>You should instead generate a <code>landingpad</code> instruction, that
776   returns an exception object and selector value:</p>
777
778<div class="doc_code">
779<pre>
780LandingPadInst *LPadInst =
781  Builder.CreateLandingPad(StructType::get(Int8PtrTy, Int32Ty, NULL),
782                           Personality, 0);
783
784Value *LPadExn = Builder.CreateExtractValue(LPadInst, 0);
785Builder.CreateStore(LPadExn, getExceptionSlot());
786
787Value *LPadSel = Builder.CreateExtractValue(LPadInst, 1);
788Builder.CreateStore(LPadSel, getEHSelectorSlot());
789</pre>
790</div>
791
792<p>It's now trivial to add the individual clauses to the <code>landingpad</code>
793   instruction.</p>
794
795<div class="doc_code">
796<pre>
797<i><b>// Adding a catch clause</b></i>
798Constant *TypeInfo = getTypeInfo();
799LPadInst-&gt;addClause(TypeInfo);
800
801<i><b>// Adding a C++ catch-all</b></i>
802LPadInst-&gt;addClause(Constant::getNullValue(Builder.getInt8PtrTy()));
803
804<i><b>// Adding a cleanup</b></i>
805LPadInst-&gt;setCleanup(true);
806
807<i><b>// Adding a filter clause</b></i>
808std::vector&lt;Constant*&gt; TypeInfos;
809Constant *TypeInfo = getFilterTypeInfo();
810TypeInfos.push_back(Builder.CreateBitCast(TypeInfo, Builder.getInt8PtrTy()));
811
812ArrayType *FilterTy = ArrayType::get(Int8PtrTy, TypeInfos.size());
813LPadInst-&gt;addClause(ConstantArray::get(FilterTy, TypeInfos));
814</pre>
815</div>
816
817<p>Converting from using the <code>@llvm.eh.resume</code> intrinsic to
818   the <code>resume</code> instruction is trivial. It takes the exception
819   pointer and exception selector values returned by
820   the <code>landingpad</code> instruction:</p>
821
822<div class="doc_code">
823<pre>
824Type *UnwindDataTy = StructType::get(Builder.getInt8PtrTy(),
825                                     Builder.getInt32Ty(), NULL);
826Value *UnwindData = UndefValue::get(UnwindDataTy);
827Value *ExcPtr = Builder.CreateLoad(getExceptionObjSlot());
828Value *ExcSel = Builder.CreateLoad(getExceptionSelSlot());
829UnwindData = Builder.CreateInsertValue(UnwindData, ExcPtr, 0, "exc_ptr");
830UnwindData = Builder.CreateInsertValue(UnwindData, ExcSel, 1, "exc_sel");
831Builder.CreateResume(UnwindData);
832</pre>
833</div>
834
835</div>
836
837
838<h3>
839<a name="optimizer">Optimizer Improvements</a>
840</h3>
841
842<div>
843
844<p>In addition to a large array of minor performance tweaks and bug fixes, this
845   release includes a few major enhancements and additions to the
846   optimizers:</p>
847
848<ul>
849
852</li>
853
854</ul>
855
856</div>
857
858
859<h3>
860<a name="mc">MC Level Improvements</a>
861</h3>
862
863<div>
864
865<p>The LLVM Machine Code (aka MC) subsystem was created to solve a number of
866   problems in the realm of assembly, disassembly, object file format handling,
867   and a number of other related areas that CPU instruction-set level tools work
868   in.</p>
869
870<ul>
871
874</ul>
875
876<p>For more information, please see
877   the <a href="http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html">Intro
878   to the LLVM MC Project Blog Post</a>.</p>
879
880</div>
881
882
883<h3>
884<a name="codegen">Target Independent Code Generator Improvements</a>
885</h3>
886
887<div>
888
889<p>We have put a significant amount of work into the code generator
890   infrastructure, which allows us to implement more aggressive algorithms and
891   make it run faster:</p>
892
893<ul>
894
897</ul>
898</div>
899
900
901<h3>
902<a name="x86">X86-32 and X86-64 Target Improvements</a>
903</h3>
904
905<div>
906
907<p>New features and major changes in the X86 target include:</p>
908
909<ul>
910
911  <li>The CRC32 intrinsics have been renamed.  The intrinsics were previously
912      <code>@llvm.x86.sse42.crc32.[8|16|32]</code>
913      and <code>@llvm.x86.sse42.crc64.[8|64]</code>. They have been renamed to
914      <code>@llvm.x86.sse42.crc32.32.[8|16|32]</code> and
915      <code>@llvm.x86.sse42.crc32.64.[8|64]</code>.</li>
916
917</ul>
918
919</div>
920
921
922<h3>
923<a name="ARM">ARM Target Improvements</a>
924</h3>
925
926<div>
927
928<p>New features of the ARM target include:</p>
929
930<ul>
931
934</ul>
935</div>
936
937
938<h3>
939<a name="OtherTS">Other Target Specific Improvements</a>
940</h3>
941
942<p>PPC32/ELF va_arg was implemented.</p>
943<p>PPC32 initial support for .o file writing was implemented.</p>
944
945<div>
946
947<ul>
948
951</ul>
952
953</div>
954
955
956<h3>
957<a name="changes">Major Changes and Removed Features</a>
958</h3>
959
960<div>
961
962<p>If you're already an LLVM user or developer with out-of-tree changes based on
963   LLVM 2.9, this section lists some "gotchas" that you may run into upgrading
964   from the previous release.</p>
965
966<ul>
967  <li>The <code>LLVMC</code> front end code was removed while separating
968      out language independence.</li>
969  <li>The <code>LowerSetJmp</code> pass wasn't used effectively by any
970      target and has been removed.</li>
971  <li>The old <code>TailDup</code> pass was not used in the standard pipeline
972      and was unable to update ssa form, so it has been removed.
973  <li>The syntax of volatile loads and stores in IR has been changed to
974      "<code>load volatile</code>"/"<code>store volatile</code>".  The old
975      syntax ("<code>volatile load</code>"/"<code>volatile store</code>")
976      is still accepted, but is now considered deprecated.</li>
977  <li>The old atomic intrinscs (<code>llvm.memory.barrier</code> and
978      <code>llvm.atomic.*</code>) are now gone.  Please use the new atomic
979      instructions, described in the <a href="Atomics.html">atomics guide</a>.
980</ul>
981
982<h4>Windows (32-bit)</h4>
983<div>
984
985<ul>
986  <li>On Win32(MinGW32 and MSVC), Windows 2000 will not be supported.
987      Windows XP or higher is required.</li>
988</ul>
989
990</div>
991
992</div>
993
994
995<h3>
996<a name="api_changes">Internal API Changes</a>
997</h3>
998
999<div>
1000
1001<p>In addition, many APIs have changed in this release.  Some of the major
1002   LLVM API changes are:</p>
1003
1004<ul>
1005  <li>The biggest and most pervasive change is that llvm::Type's are no longer
1006      returned or accepted as 'const' values.  Instead, just pass around
1007      non-const Type's.</li>
1008
1009  <li><code>PHINode::reserveOperandSpace</code> has been removed. Instead, you
1010      must specify how many operands to reserve space for when you create the
1011      PHINode, by passing an extra argument
1012      into <code>PHINode::Create</code>.</li>
1013
1014  <li>PHINodes no longer store their incoming BasicBlocks as operands. Instead,
1015      the list of incoming BasicBlocks is stored separately, and can be accessed
1016      with new functions <code>PHINode::block_begin</code>
1017      and <code>PHINode::block_end</code>.</li>
1018
1019  <li>Various functions now take an <code>ArrayRef</code> instead of either a
1020      pair of pointers (or iterators) to the beginning and end of a range, or a
1021      pointer and a length. Others now return an <code>ArrayRef</code> instead
1022      of a reference to a <code>SmallVector</code>
1023      or <code>std::vector</code>. These include:
1024<ul>
1025
1026<li><code>CallInst::Create</code></li>
1027<li><code>ComputeLinearIndex</code> (in <code>llvm/CodeGen/Analysis.h</code>)</li>
1028<li><code>ConstantArray::get</code></li>
1029<li><code>ConstantExpr::getExtractElement</code></li>
1030<li><code>ConstantExpr::getGetElementPtr</code></li>
1031<li><code>ConstantExpr::getInBoundsGetElementPtr</code></li>
1032<li><code>ConstantExpr::getIndices</code></li>
1033<li><code>ConstantExpr::getInsertElement</code></li>
1034<li><code>ConstantExpr::getWithOperands</code></li>
1035<li><code>ConstantFoldCall</code> (in <code>llvm/Analysis/ConstantFolding.h</code>)</li>
1036<li><code>ConstantFoldInstOperands</code> (in <code>llvm/Analysis/ConstantFolding.h</code>)</li>
1037<li><code>ConstantVector::get</code></li>
1038<li><code>DIBuilder::createComplexVariable</code></li>
1039<li><code>DIBuilder::getOrCreateArray</code></li>
1040<li><code>ExtractValueInst::Create</code></li>
1041<li><code>ExtractValueInst::getIndexedType</code></li>
1042<li><code>ExtractValueInst::getIndices</code></li>
1043<li><code>FindInsertedValue</code> (in <code>llvm/Analysis/ValueTracking.h</code>)</li>
1044<li><code>gep_type_begin</code> (in <code>llvm/Support/GetElementPtrTypeIterator.h</code>)</li>
1045<li><code>gep_type_end</code> (in <code>llvm/Support/GetElementPtrTypeIterator.h</code>)</li>
1046<li><code>GetElementPtrInst::Create</code></li>
1047<li><code>GetElementPtrInst::CreateInBounds</code></li>
1048<li><code>GetElementPtrInst::getIndexedType</code></li>
1049<li><code>InsertValueInst::Create</code></li>
1050<li><code>InsertValueInst::getIndices</code></li>
1051<li><code>InvokeInst::Create</code></li>
1052<li><code>IRBuilder::CreateCall</code></li>
1053<li><code>IRBuilder::CreateExtractValue</code></li>
1054<li><code>IRBuilder::CreateGEP</code></li>
1055<li><code>IRBuilder::CreateInBoundsGEP</code></li>
1056<li><code>IRBuilder::CreateInsertValue</code></li>
1057<li><code>IRBuilder::CreateInvoke</code></li>
1058<li><code>MDNode::get</code></li>
1059<li><code>MDNode::getIfExists</code></li>
1060<li><code>MDNode::getTemporary</code></li>
1061<li><code>MDNode::getWhenValsUnresolved</code></li>
1062<li><code>SimplifyGEPInst</code> (in <code>llvm/Analysis/InstructionSimplify.h</code>)</li>
1063<li><code>TargetData::getIndexedOffset</code></li>
1064</ul></li>
1065
1066  <li>All forms of <code>StringMap::getOrCreateValue</code> have been remove
1067      except for the one which takes a <code>StringRef</code>.</li>
1068
1069  <li>The <code>LLVMBuildUnwind</code> function from the C API was removed. The
1070      LLVM <code>unwind</code> instruction has been deprecated for a long time
1071      and isn't used by the current front-ends. So this was removed during the
1072      exception handling rewrite.</li>
1073
1074  <li>The <code>LLVMAddLowerSetJmpPass</code> function from the C API was
1075      removed because the <code>LowerSetJmp</code> pass was removed.</li>
1076
1077  <li>The <code>DIBuilder</code> interface used by front ends to encode
1078      debugging information in the LLVM IR now expects clients to
1079      use <code>DIBuilder::finalize()</code> at the end of translation unit to
1080      complete debugging information encoding.</li>
1081
1082  <li>The way the type system works has been
1083      rewritten: <code>PATypeHolder</code> and <code>OpaqueType</code> are gone,
1084      and all APIs deal with <code>Type*</code> instead of <code>const
1085      Type*</code>.  If you need to create recursive structures, then create a
1086      named structure, and use <code>setBody()</code> when all its elements are
1087      built.  Type merging and refining is gone too: named structures are not
1088      merged with other structures, even if their layout is identical.  (of
1089      course anonymous structures are still uniqued by layout).</li>
1090
1091  <li>TargetSelect.h moved to Support/ from Target/</li>
1092
1093  <li>UpgradeIntrinsicCall no longer upgrades pre-2.9 intrinsic calls (for
1094      example <code>llvm.memset.i32</code>).</li>
1095
1096  <li>It is mandatory to initialize all out-of-tree passes too and their dependencies now with
1097      <code>INITIALIZE_PASS{BEGIN,END,}</code>
1098      and <code>INITIALIZE_{PASS,AG}_DEPENDENCY</code>.</li>
1099
1100  <li>The interface for MemDepResult in MemoryDependenceAnalysis has been
1101      enhanced with new return types Unknown and NonFuncLocal, in addition to
1102      the existing types Clobber, Def, and NonLocal.</li>
1103</ul>
1104
1105</div>
1106
1107</div>
1108
1109
1110<h2>
1111  <a name="knownproblems">Known Problems</a>
1112</h2>
1113
1114
1115<div>
1116
1117<p>This section contains significant known problems with the LLVM system, listed
1118   by component.  If you run into a problem, please check
1119   the <a href="http://llvm.org/bugs/">LLVM bug database</a> and submit a bug if
1120   there isn't already one.</p>
1121
1122
1123<h3>
1124  <a name="experimental">Experimental features included with this release</a>
1125</h3>
1126
1127<div>
1128
1129<p>The following components of this LLVM release are either untested, known to
1130   be broken or unreliable, or are in early development.  These components
1131   should not be relied on, and bugs should not be filed against them, but they
1132   may be useful to some people.  In particular, if you would like to work on
1133   one of these components, please contact us on
1134   the <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev
1135   list</a>.</p>
1136
1137<ul>
1138  <li>The Alpha, Blackfin, CellSPU, MicroBlaze, MSP430, MIPS, PTX, SystemZ and
1139      XCore backends are experimental.</li>
1140
1141  <li><tt>llc</tt> "<tt>-filetype=obj</tt>" is experimental on all targets other
1142      than darwin and ELF X86 systems.</li>
1143</ul>
1144
1145</div>
1146
1147
1148<h3>
1149  <a name="x86-be">Known problems with the X86 back-end</a>
1150</h3>
1151
1152<div>
1153
1154<ul>
1155  <li>The X86 backend does not yet support
1156      all <a href="http://llvm.org/PR879">inline assembly that uses the X86
1157      floating point stack</a>.  It supports the 'f' and 't' constraints, but
1158      not 'u'.</li>
1159
1160  <li>The X86-64 backend does not yet support the LLVM IR instruction
1161      <tt>va_arg</tt>. Currently, front-ends support variadic argument
1162      constructs on X86-64 by lowering them manually.</li>
1163
1164  <li>Windows x64 (aka Win64) code generator has a few issues.
1165    <ul>
1166      <li>llvm-gcc cannot build the mingw-w64 runtime currently due to lack of
1167          support for the 'u' inline assembly constraint and for X87 floating
1168          point inline assembly.</li>
1169
1170      <li>On mingw-w64, you will see unresolved symbol <tt>__chkstk</tt> due
1171          to <a href="http://llvm.org/bugs/show_bug.cgi?id=8919">Bug 8919</a>.
1172          It is fixed
1173          in <a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110321/118499.html">r128206</a>.</li>
1174
1175      <li>Miss-aligned MOVDQA might crash your program. It is due to
1176          <a href="http://llvm.org/bugs/show_bug.cgi?id=9483">Bug 9483</a>, lack
1177          of handling aligned internal globals.</li>
1178      </ul>
1179  </li>
1180
1181</ul>
1182
1183</div>
1184
1185
1186<h3>
1187  <a name="ppc-be">Known problems with the PowerPC back-end</a>
1188</h3>
1189
1190<div>
1191
1192<ul>
1193  <li>The PPC32/ELF support lacks PIC support.</li>
1194</ul>
1195
1196</div>
1197
1198
1199<h3>
1200  <a name="arm-be">Known problems with the ARM back-end</a>
1201</h3>
1202
1203<div>
1204
1205<ul>
1206  <li>Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6
1207      processors, thumb programs can crash or produce wrong results
1208      (<a href="http://llvm.org/PR1388">PR1388</a>).</li>
1209
1210  <li>Compilation for ARM Linux OABI (old ABI) is supported but not fully
1211      tested.</li>
1212</ul>
1213
1214</div>
1215
1216
1217<h3>
1218  <a name="sparc-be">Known problems with the SPARC back-end</a>
1219</h3>
1220
1221<div>
1222
1223<ul>
1224  <li>The SPARC backend only supports the 32-bit SPARC ABI (-m32); it does not
1225      support the 64-bit SPARC ABI (-m64).</li>
1226</ul>
1227
1228</div>
1229
1230
1231<h3>
1232  <a name="mips-be">Known problems with the MIPS back-end</a>
1233</h3>
1234
1235<div>
1236
1237<ul>
1238  <li>64-bit MIPS targets are not supported yet.</li>
1239</ul>
1240
1241</div>
1242
1243
1244<h3>
1245  <a name="alpha-be">Known problems with the Alpha back-end</a>
1246</h3>
1247
1248<div>
1249
1250<ul>
1251  <li>On 21164s, some rare FP arithmetic sequences which may trap do not have
1252      the appropriate nops inserted to ensure restartability.</li>
1253</ul>
1254
1255</div>
1256
1257
1258<h3>
1259  <a name="c-be">Known problems with the C back-end</a>
1260</h3>
1261
1262<div>
1263
1264<p>The C backend has numerous problems and is not being actively maintained.
1265   Depending on it for anything serious is not advised.</p>
1266
1267<ul>
1268  <li><a href="http://llvm.org/PR802">The C backend has only basic support for
1269      inline assembly code</a>.</li>
1270
1271  <li><a href="http://llvm.org/PR1658">The C backend violates the ABI of common
1272      C++ programs</a>, preventing intermixing between C++ compiled by the CBE
1273      and C++ code compiled with <tt>llc</tt> or native compilers.</li>
1274
1275  <li>The C backend does not support all exception handling constructs.</li>
1276
1277  <li>The C backend does not support arbitrary precision integers.</li>
1278</ul>
1279
1280</div>
1281
1282
1283
1284<h3>
1285  <a name="llvm-gcc">Known problems with the llvm-gcc front-end</a>
1286</h3>
1287
1288<div>
1289
1290<p><b>LLVM 2.9 was the last release of llvm-gcc.</b></p>
1291
1292<p>llvm-gcc is generally very stable for the C family of languages.  The only
1293   major language feature of GCC not supported by llvm-gcc is the
1294   <tt>__builtin_apply</tt> family of builtins.   However, some extensions
1295   are only supported on some targets.  For example, trampolines are only
1296   supported on some targets (these are used when you take the address of a
1297   nested function).</p>
1298
1299<p>Fortran support generally works, but there are still several unresolved bugs
1300   in <a href="http://llvm.org/bugs/">Bugzilla</a>.  Please see the
1301   tools/gfortran component for details.  Note that llvm-gcc is missing major
1302   Fortran performance work in the frontend and library that went into GCC after
1303   4.2.  If you are interested in Fortran, we recommend that you consider using
1304   <a href="#dragonegg">dragonegg</a> instead.</p>
1305
1306<p>The llvm-gcc 4.2 Ada compiler has basic functionality, but is no longer being
1307   actively maintained.  If you are interested in Ada, we recommend that you
1308   consider using <a href="#dragonegg">dragonegg</a> instead.</p>
1309
1310</div>
1311
1312</div>
1313
1314
1315<h2>
1316  <a name="additionalinfo">Additional Information</a>
1317</h2>
1318
1319
1320<div>
1321
1322<p>A wide variety of additional information is available on
1323   the <a href="http://llvm.org/">LLVM web page</a>, in particular in
1324   the <a href="http://llvm.org/docs/">documentation</a> section.  The web page
1325   also contains versions of the API documentation which is up-to-date with the
1326   Subversion version of the source code.  You can access versions of these
1327   documents specific to this release by going into the "<tt>llvm/doc/</tt>"
1328   directory in the LLVM tree.</p>
1329
1330<p>If you have any questions or comments about LLVM, please feel free to contact
1331   us via the <a href="http://llvm.org/docs/#maillist"> mailing lists</a>.</p>
1332
1333</div>
1334
1335
1336
1337<hr>
1338<address>
1339  <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
1340  src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
1341  <a href="http://validator.w3.org/check/referer"><img
1342  src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
1343
1344  <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br>
1345  Last modified: $Date: 2011-11-01 00:51:35 -0400 (Tue, 01 Nov 2011) $
1346</address>
1347
1348</body>
1349</html>
1350