Dmitri Gribenko | e17d858 | 2012-12-09 23:14:26 +0000 | [diff] [blame] | 1 | .. raw:: html |
| 2 | |
| 3 | <style> .red {color:red} </style> |
| 4 | |
| 5 | .. role:: red |
| 6 | |
| 7 | ====================== |
| 8 | LLVM 3.2 Release Notes |
| 9 | ====================== |
| 10 | |
| 11 | .. contents:: |
| 12 | :local: |
| 13 | |
| 14 | Written by the `LLVM Team <http://llvm.org/>`_ |
| 15 | |
| 16 | :red:`These are in-progress notes for the upcoming LLVM 3.2 release. You may |
| 17 | prefer the` `LLVM 3.1 Release Notes <http://llvm.org/releases/3.1/docs |
| 18 | /ReleaseNotes.html>`_. |
| 19 | |
| 20 | Introduction |
| 21 | ============ |
| 22 | |
| 23 | This document contains the release notes for the LLVM Compiler Infrastructure, |
| 24 | release 3.2. Here we describe the status of LLVM, including major improvements |
| 25 | from the previous release, improvements in various subprojects of LLVM, and |
| 26 | some of the current users of the code. All LLVM releases may be downloaded |
| 27 | from the `LLVM releases web site <http://llvm.org/releases/>`_. |
| 28 | |
| 29 | For more information about LLVM, including information about the latest |
| 30 | release, please check out the `main LLVM web site <http://llvm.org/>`_. If you |
| 31 | have questions or comments, the `LLVM Developer's Mailing List |
| 32 | <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>`_ is a good place to send |
| 33 | them. |
| 34 | |
| 35 | Note that if you are reading this file from a Subversion checkout or the main |
| 36 | LLVM web page, this document applies to the *next* release, not the current |
| 37 | one. To see the release notes for a specific release, please see the `releases |
| 38 | page <http://llvm.org/releases/>`_. |
| 39 | |
| 40 | Sub-project Status Update |
| 41 | ========================= |
| 42 | |
| 43 | The LLVM 3.2 distribution currently consists of code from the core LLVM |
| 44 | repository, which roughly includes the LLVM optimizers, code generators and |
| 45 | supporting tools, and the Clang repository. In addition to this code, the LLVM |
| 46 | Project includes other sub-projects that are in development. Here we include |
| 47 | updates on these subprojects. |
| 48 | |
| 49 | Clang: C/C++/Objective-C Frontend Toolkit |
| 50 | ----------------------------------------- |
| 51 | |
| 52 | `Clang <http://clang.llvm.org/>`_ is an LLVM front end for the C, C++, and |
| 53 | Objective-C languages. Clang aims to provide a better user experience through |
| 54 | expressive diagnostics, a high level of conformance to language standards, fast |
| 55 | compilation, and low memory use. Like LLVM, Clang provides a modular, |
| 56 | library-based architecture that makes it suitable for creating or integrating |
| 57 | with other development tools. Clang is considered a production-quality |
| 58 | compiler for C, Objective-C, C++ and Objective-C++ on x86 (32- and 64-bit), and |
| 59 | for Darwin/ARM targets. |
| 60 | |
| 61 | In the LLVM 3.2 time-frame, the Clang team has made many improvements. |
| 62 | Highlights include: |
| 63 | |
| 64 | #. ... |
| 65 | |
| 66 | For more details about the changes to Clang since the 3.1 release, see the |
| 67 | `Clang release notes. <http://clang.llvm.org/docs/ReleaseNotes.html>`_ |
| 68 | |
| 69 | If Clang rejects your code but another compiler accepts it, please take a look |
| 70 | at the `language compatibility <http://clang.llvm.org/compatibility.html>`_ |
| 71 | guide to make sure this is not intentional or a known issue. |
| 72 | |
| 73 | DragonEgg: GCC front-ends, LLVM back-end |
| 74 | ---------------------------------------- |
| 75 | |
| 76 | `DragonEgg <http://dragonegg.llvm.org/>`_ is a `gcc plugin |
| 77 | <http://gcc.gnu.org/wiki/plugins>`_ that replaces GCC's optimizers and code |
| 78 | generators with LLVM's. It works with gcc-4.5 and gcc-4.6 (and partially with |
| 79 | gcc-4.7), can target the x86-32/x86-64 and ARM processor families, and has been |
| 80 | successfully used on the Darwin, FreeBSD, KFreeBSD, Linux and OpenBSD |
| 81 | platforms. It fully supports Ada, C, C++ and Fortran. It has partial support |
| 82 | for Go, Java, Obj-C and Obj-C++. |
| 83 | |
| 84 | The 3.2 release has the following notable changes: |
| 85 | |
| 86 | #. ... |
| 87 | |
| 88 | compiler-rt: Compiler Runtime Library |
| 89 | ------------------------------------- |
| 90 | |
| 91 | The new LLVM `compiler-rt project <http://compiler-rt.llvm.org/>`_ is a simple |
| 92 | library that provides an implementation of the low-level target-specific hooks |
| 93 | required by code generation and other runtime components. For example, when |
| 94 | compiling for a 32-bit target, converting a double to a 64-bit unsigned integer |
| 95 | is compiled into a runtime call to the ``__fixunsdfdi`` function. The |
| 96 | ``compiler-rt`` library provides highly optimized implementations of this and |
| 97 | other low-level routines (some are 3x faster than the equivalent libgcc |
| 98 | routines). |
| 99 | |
| 100 | The 3.2 release has the following notable changes: |
| 101 | |
| 102 | #. ... |
| 103 | |
| 104 | LLDB: Low Level Debugger |
| 105 | ------------------------ |
| 106 | |
| 107 | `LLDB <http://lldb.llvm.org>`_ is a ground-up implementation of a command line |
| 108 | debugger, as well as a debugger API that can be used from other applications. |
| 109 | LLDB makes use of the Clang parser to provide high-fidelity expression parsing |
| 110 | (particularly for C++) and uses the LLVM JIT for target support. |
| 111 | |
| 112 | The 3.2 release has the following notable changes: |
| 113 | |
| 114 | #. ... |
| 115 | |
| 116 | libc++: C++ Standard Library |
| 117 | ---------------------------- |
| 118 | |
| 119 | Like compiler_rt, libc++ is now :ref:`dual licensed |
| 120 | <copyright-license-patents>` under the MIT and UIUC license, allowing it to be |
| 121 | used more permissively. |
| 122 | |
| 123 | Within the LLVM 3.2 time-frame there were the following highlights: |
| 124 | |
| 125 | #. ... |
| 126 | |
| 127 | VMKit |
| 128 | ----- |
| 129 | |
| 130 | The `VMKit project <http://vmkit.llvm.org/>`_ is an implementation of a Java |
| 131 | Virtual Machine (Java VM or JVM) that uses LLVM for static and just-in-time |
| 132 | compilation. |
| 133 | |
| 134 | The 3.2 release has the following notable changes: |
| 135 | |
| 136 | #. ... |
| 137 | |
| 138 | Polly: Polyhedral Optimizer |
| 139 | --------------------------- |
| 140 | |
| 141 | `Polly <http://polly.llvm.org/>`_ is an *experimental* optimizer for data |
| 142 | locality and parallelism. It provides high-level loop optimizations and |
| 143 | automatic parallelisation. |
| 144 | |
| 145 | Within the LLVM 3.2 time-frame there were the following highlights: |
| 146 | |
| 147 | #. isl, the integer set library used by Polly, was relicensed to the MIT license |
| 148 | #. isl based code generation |
| 149 | #. MIT licensed replacement for CLooG (LGPLv2) |
| 150 | #. Fine grained option handling (separation of core and border computations, |
| 151 | control overhead vs. code size) |
| 152 | #. Support for FORTRAN and dragonegg |
| 153 | #. OpenMP code generation fixes |
| 154 | |
| 155 | External Open Source Projects Using LLVM 3.2 |
| 156 | ============================================ |
| 157 | |
| 158 | An exciting aspect of LLVM is that it is used as an enabling technology for a |
| 159 | lot of other language and tools projects. This section lists some of the |
| 160 | projects that have already been updated to work with LLVM 3.2. |
| 161 | |
| 162 | Crack |
| 163 | ----- |
| 164 | |
| 165 | `Crack <http://code.google.com/p/crack-language/>`_ aims to provide the ease of |
| 166 | development of a scripting language with the performance of a compiled |
| 167 | language. The language derives concepts from C++, Java and Python, |
| 168 | incorporating object-oriented programming, operator overloading and strong |
| 169 | typing. |
| 170 | |
| 171 | FAUST |
| 172 | ----- |
| 173 | |
| 174 | `FAUST <http://faust.grame.fr/>`_ is a compiled language for real-time audio |
| 175 | signal processing. The name FAUST stands for Functional AUdio STream. Its |
| 176 | programming model combines two approaches: functional programming and block |
| 177 | diagram composition. In addition with the C, C++, Java, JavaScript output |
| 178 | formats, the Faust compiler can generate LLVM bitcode, and works with LLVM |
| 179 | 2.7-3.1. |
| 180 | |
| 181 | Glasgow Haskell Compiler (GHC) |
| 182 | ------------------------------ |
| 183 | |
| 184 | `GHC <http://www.haskell.org/ghc/>`_ is an open source compiler and programming |
| 185 | suite for Haskell, a lazy functional programming language. It includes an |
| 186 | optimizing static compiler generating good code for a variety of platforms, |
| 187 | together with an interactive system for convenient, quick development. |
| 188 | |
| 189 | GHC 7.0 and onwards include an LLVM code generator, supporting LLVM 2.8 and |
| 190 | later. |
| 191 | |
| 192 | Julia |
| 193 | ----- |
| 194 | |
| 195 | `Julia <https://github.com/JuliaLang/julia>`_ is a high-level, high-performance |
| 196 | dynamic language for technical computing. It provides a sophisticated |
| 197 | compiler, distributed parallel execution, numerical accuracy, and an extensive |
| 198 | mathematical function library. The compiler uses type inference to generate |
| 199 | fast code without any type declarations, and uses LLVM's optimization passes |
| 200 | and JIT compiler. The `Julia Language <http://julialang.org/>`_ is designed |
| 201 | around multiple dispatch, giving programs a large degree of flexibility. It is |
| 202 | ready for use on many kinds of problems. |
| 203 | |
| 204 | LLVM D Compiler |
| 205 | --------------- |
| 206 | |
| 207 | `LLVM D Compiler <https://github.com/ldc-developers/ldc>`_ (LDC) is a compiler |
| 208 | for the D programming Language. It is based on the DMD frontend and uses LLVM |
| 209 | as backend. |
| 210 | |
| 211 | Open Shading Language |
| 212 | --------------------- |
| 213 | |
| 214 | `Open Shading Language (OSL) |
| 215 | <https://github.com/imageworks/OpenShadingLanguage/>`_ is a small but rich |
| 216 | language for programmable shading in advanced global illumination renderers and |
| 217 | other applications, ideal for describing materials, lights, displacement, and |
| 218 | pattern generation. It uses LLVM to JIT complex shader networks to x86 code at |
| 219 | runtime. |
| 220 | |
| 221 | OSL was developed by Sony Pictures Imageworks for use in its in-house renderer |
| 222 | used for feature film animation and visual effects, and is distributed as open |
| 223 | source software with the "New BSD" license. |
| 224 | |
| 225 | Portable OpenCL (pocl) |
| 226 | ---------------------- |
| 227 | |
| 228 | In addition to producing an easily portable open source OpenCL implementation, |
| 229 | another major goal of `pocl <http://pocl.sourceforge.net/>`_ is improving |
| 230 | performance portability of OpenCL programs with compiler optimizations, |
| 231 | reducing the need for target-dependent manual optimizations. An important part |
| 232 | of pocl is a set of LLVM passes used to statically parallelize multiple |
| 233 | work-items with the kernel compiler, even in the presence of work-group |
| 234 | barriers. This enables static parallelization of the fine-grained static |
| 235 | concurrency in the work groups in multiple ways (SIMD, VLIW, superscalar, ...). |
| 236 | |
| 237 | Pure |
| 238 | ---- |
| 239 | |
| 240 | `Pure <http://pure-lang.googlecode.com/>`_ is an algebraic/functional |
| 241 | programming language based on term rewriting. Programs are collections of |
| 242 | equations which are used to evaluate expressions in a symbolic fashion. The |
| 243 | interpreter uses LLVM as a backend to JIT-compile Pure programs to fast native |
| 244 | code. Pure offers dynamic typing, eager and lazy evaluation, lexical closures, |
| 245 | a hygienic macro system (also based on term rewriting), built-in list and |
| 246 | matrix support (including list and matrix comprehensions) and an easy-to-use |
| 247 | interface to C and other programming languages (including the ability to load |
| 248 | LLVM bitcode modules, and inline C, C++, Fortran and Faust code in Pure |
| 249 | programs if the corresponding LLVM-enabled compilers are installed). |
| 250 | |
| 251 | Pure version 0.54 has been tested and is known to work with LLVM 3.1 (and |
| 252 | continues to work with older LLVM releases >= 2.5). |
| 253 | |
| 254 | TTA-based Co-design Environment (TCE) |
| 255 | ------------------------------------- |
| 256 | |
| 257 | `TCE <http://tce.cs.tut.fi/>`_ is a toolset for designing application-specific |
| 258 | processors (ASP) based on the Transport triggered architecture (TTA). The |
| 259 | toolset provides a complete co-design flow from C/C++ programs down to |
| 260 | synthesizable VHDL/Verilog and parallel program binaries. Processor |
| 261 | customization points include the register files, function units, supported |
| 262 | operations, and the interconnection network. |
| 263 | |
| 264 | TCE uses Clang and LLVM for C/C++ language support, target independent |
| 265 | optimizations and also for parts of code generation. It generates new |
| 266 | LLVM-based code generators "on the fly" for the designed TTA processors and |
| 267 | loads them in to the compiler backend as runtime libraries to avoid per-target |
| 268 | recompilation of larger parts of the compiler chain. |
| 269 | |
| 270 | Installation Instructions |
| 271 | ========================= |
| 272 | |
| 273 | See :doc:`GettingStarted`. |
| 274 | |
| 275 | What's New in LLVM 3.2? |
| 276 | ======================= |
| 277 | |
| 278 | This release includes a huge number of bug fixes, performance tweaks and minor |
| 279 | improvements. Some of the major improvements and new features are listed in |
| 280 | this section. |
| 281 | |
| 282 | Major New Features |
| 283 | ------------------ |
| 284 | |
| 285 | .. |
| 286 | |
| 287 | Features that need text if they're finished for 3.2: |
| 288 | ARM EHABI |
| 289 | combiner-aa? |
| 290 | strong phi elim |
| 291 | loop dependence analysis |
| 292 | CorrelatedValuePropagation |
| 293 | lib/Transforms/IPO/MergeFunctions.cpp => consider for 3.2. |
| 294 | Integrated assembler on by default for arm/thumb? |
| 295 | |
| 296 | Near dead: |
| 297 | Analysis/RegionInfo.h + Dom Frontiers |
| 298 | SparseBitVector: used in LiveVar. |
| 299 | llvm/lib/Archive - replace with lib object? |
| 300 | |
| 301 | |
| 302 | LLVM 3.2 includes several major changes and big features: |
| 303 | |
| 304 | #. New NVPTX back-end (replacing existing PTX back-end) based on NVIDIA sources |
| 305 | #. ... |
| 306 | |
| 307 | LLVM IR and Core Improvements |
| 308 | ----------------------------- |
| 309 | |
| 310 | LLVM IR has several new features for better support of new targets and that |
| 311 | expose new optimization opportunities: |
| 312 | |
| 313 | #. Thread local variables may have a specified TLS model. See the :ref:`Language |
| 314 | Reference Manual <globalvars>`. |
| 315 | #. ... |
| 316 | |
| 317 | Optimizer Improvements |
| 318 | ---------------------- |
| 319 | |
| 320 | In addition to many minor performance tweaks and bug fixes, this release |
| 321 | includes a few major enhancements and additions to the optimizers: |
| 322 | |
| 323 | Loop Vectorizer - We've added a loop vectorizer and we are now able to |
| 324 | vectorize small loops. The loop vectorizer is disabled by default and can be |
| 325 | enabled using the ``-mllvm -vectorize-loops`` flag. The SIMD vector width can |
| 326 | be specified using the flag ``-mllvm -force-vector-width=4``. The default |
| 327 | value is ``0`` which means auto-select. |
| 328 | |
| 329 | We can now vectorize this function: |
| 330 | |
| 331 | .. code-block:: c++ |
| 332 | |
| 333 | unsigned sum_arrays(int *A, int *B, int start, int end) { |
| 334 | unsigned sum = 0; |
| 335 | for (int i = start; i < end; ++i) |
| 336 | sum += A[i] + B[i] + i; |
| 337 | return sum; |
| 338 | } |
| 339 | |
| 340 | We vectorize under the following loops: |
| 341 | |
| 342 | #. The inner most loops must have a single basic block. |
| 343 | #. The number of iterations are known before the loop starts to execute. |
| 344 | #. The loop counter needs to be incremented by one. |
| 345 | #. The loop trip count **can** be a variable. |
| 346 | #. Loops do **not** need to start at zero. |
| 347 | #. The induction variable can be used inside the loop. |
| 348 | #. Loop reductions are supported. |
| 349 | #. Arrays with affine access pattern do **not** need to be marked as |
| 350 | '``noalias``' and are checked at runtime. |
| 351 | #. ... |
| 352 | |
| 353 | SROA - We've re-written SROA to be significantly more powerful. |
| 354 | |
| 355 | #. Branch weight metadata is preseved through more of the optimizer. |
| 356 | #. ... |
| 357 | |
| 358 | MC Level Improvements |
| 359 | --------------------- |
| 360 | |
| 361 | The LLVM Machine Code (aka MC) subsystem was created to solve a number of |
| 362 | problems in the realm of assembly, disassembly, object file format handling, |
| 363 | and a number of other related areas that CPU instruction-set level tools work |
| 364 | in. For more information, please see the `Intro to the LLVM MC Project Blog |
| 365 | Post <http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html>`_. |
| 366 | |
| 367 | #. ... |
| 368 | |
| 369 | .. _codegen: |
| 370 | |
| 371 | Target Independent Code Generator Improvements |
| 372 | ---------------------------------------------- |
| 373 | |
| 374 | Stack Coloring - We have implemented a new optimization pass to merge stack |
| 375 | objects which are used in disjoin areas of the code. This optimization reduces |
| 376 | the required stack space significantly, in cases where it is clear to the |
| 377 | optimizer that the stack slot is not shared. We use the lifetime markers to |
| 378 | tell the codegen that a certain alloca is used within a region. |
| 379 | |
| 380 | We now merge consecutive loads and stores. |
| 381 | |
| 382 | We have put a significant amount of work into the code generator |
| 383 | infrastructure, which allows us to implement more aggressive algorithms and |
| 384 | make it run faster: |
| 385 | |
| 386 | #. ... |
| 387 | |
| 388 | We added new TableGen infrastructure to support bundling for Very Long |
| 389 | Instruction Word (VLIW) architectures. TableGen can now automatically generate |
| 390 | a deterministic finite automaton from a VLIW target's schedule description |
| 391 | which can be queried to determine legal groupings of instructions in a bundle. |
| 392 | |
| 393 | We have added a new target independent VLIW packetizer based on the DFA |
| 394 | infrastructure to group machine instructions into bundles. |
| 395 | |
| 396 | Basic Block Placement |
| 397 | ^^^^^^^^^^^^^^^^^^^^^ |
| 398 | |
| 399 | A probability based block placement and code layout algorithm was added to |
| 400 | LLVM's code generator. This layout pass supports probabilities derived from |
| 401 | static heuristics as well as source code annotations such as |
| 402 | ``__builtin_expect``. |
| 403 | |
| 404 | X86-32 and X86-64 Target Improvements |
| 405 | ------------------------------------- |
| 406 | |
| 407 | New features and major changes in the X86 target include: |
| 408 | |
| 409 | #. ... |
| 410 | |
| 411 | .. _ARM: |
| 412 | |
| 413 | ARM Target Improvements |
| 414 | ----------------------- |
| 415 | |
| 416 | New features of the ARM target include: |
| 417 | |
| 418 | #. ... |
| 419 | |
| 420 | .. _armintegratedassembler: |
| 421 | |
| 422 | ARM Integrated Assembler |
| 423 | ^^^^^^^^^^^^^^^^^^^^^^^^ |
| 424 | |
| 425 | The ARM target now includes a full featured macro assembler, including |
| 426 | direct-to-object module support for clang. The assembler is currently enabled |
| 427 | by default for Darwin only pending testing and any additional necessary |
| 428 | platform specific support for Linux. |
| 429 | |
| 430 | Full support is included for Thumb1, Thumb2 and ARM modes, along with subtarget |
| 431 | and CPU specific extensions for VFP2, VFP3 and NEON. |
| 432 | |
| 433 | The assembler is Unified Syntax only (see ARM Architecural Reference Manual for |
| 434 | details). While there is some, and growing, support for pre-unfied (divided) |
| 435 | syntax, there are still significant gaps in that support. |
| 436 | |
| 437 | MIPS Target Improvements |
| 438 | ------------------------ |
| 439 | |
| 440 | New features and major changes in the MIPS target include: |
| 441 | |
| 442 | #. ... |
| 443 | |
| 444 | PowerPC Target Improvements |
| 445 | --------------------------- |
| 446 | |
| 447 | Many fixes and changes across LLVM (and Clang) for better compliance with the |
| 448 | 64-bit PowerPC ELF Application Binary Interface, interoperability with GCC, and |
| 449 | overall 64-bit PowerPC support. Some highlights include: |
| 450 | |
| 451 | #. MCJIT support added. |
| 452 | #. PPC64 relocation support and (small code model) TOC handling added. |
| 453 | #. Parameter passing and return value fixes (alignment issues, padding, varargs |
| 454 | support, proper register usage, odd-sized structure support, float support, |
| 455 | extension of return values for i32 return values). |
| 456 | #. Fixes in spill and reload code for vector registers. |
| 457 | #. C++ exception handling enabled. |
| 458 | #. Changes to remediate double-rounding compatibility issues with respect to |
| 459 | GCC behavior. |
| 460 | #. Refactoring to disentangle ``ppc64-elf-linux`` ABI from Darwin ppc64 ABI |
| 461 | support. |
| 462 | #. Assorted new test cases and test case fixes (endian and word size issues). |
| 463 | #. Fixes for big-endian codegen bugs, instruction encodings, and instruction |
| 464 | constraints. |
| 465 | #. Implemented ``-integrated-as`` support. |
| 466 | #. Additional support for Altivec compare operations. |
| 467 | #. IBM long double support. |
| 468 | |
| 469 | There have also been code generation improvements for both 32- and 64-bit code. |
| 470 | Instruction scheduling support for the Freescale e500mc and e5500 cores has |
| 471 | been added. |
| 472 | |
| 473 | PTX/NVPTX Target Improvements |
| 474 | ----------------------------- |
| 475 | |
| 476 | The PTX back-end has been replaced by the NVPTX back-end, which is based on the |
| 477 | LLVM back-end used by NVIDIA in their CUDA (nvcc) and OpenCL compiler. Some |
| 478 | highlights include: |
| 479 | |
| 480 | #. Compatibility with PTX 3.1 and SM 3.5. |
| 481 | #. Support for NVVM intrinsics as defined in the NVIDIA Compiler SDK. |
| 482 | #. Full compatibility with old PTX back-end, with much greater coverage of LLVM |
| 483 | SIR. |
| 484 | |
| 485 | Please submit any back-end bugs to the LLVM Bugzilla site. |
| 486 | |
| 487 | Other Target Specific Improvements |
| 488 | ---------------------------------- |
| 489 | |
| 490 | #. ... |
| 491 | |
| 492 | Major Changes and Removed Features |
| 493 | ---------------------------------- |
| 494 | |
| 495 | If you're already an LLVM user or developer with out-of-tree changes based on |
| 496 | LLVM 3.2, this section lists some "gotchas" that you may run into upgrading |
| 497 | from the previous release. |
| 498 | |
| 499 | #. The CellSPU port has been removed. It can still be found in older versions. |
| 500 | #. ... |
| 501 | |
| 502 | Internal API Changes |
| 503 | -------------------- |
| 504 | |
| 505 | In addition, many APIs have changed in this release. Some of the major LLVM |
| 506 | API changes are: |
| 507 | |
| 508 | We've added a new interface for allowing IR-level passes to access |
| 509 | target-specific information. A new IR-level pass, called |
| 510 | ``TargetTransformInfo`` provides a number of low-level interfaces. LSR and |
| 511 | LowerInvoke already use the new interface. |
| 512 | |
| 513 | The ``TargetData`` structure has been renamed to ``DataLayout`` and moved to |
| 514 | ``VMCore`` to remove a dependency on ``Target``. |
| 515 | |
| 516 | #. ... |
| 517 | |
| 518 | Tools Changes |
| 519 | ------------- |
| 520 | |
| 521 | In addition, some tools have changed in this release. Some of the changes are: |
| 522 | |
| 523 | #. ... |
| 524 | |
| 525 | Python Bindings |
| 526 | --------------- |
| 527 | |
| 528 | Officially supported Python bindings have been added! Feature support is far |
| 529 | from complete. The current bindings support interfaces to: |
| 530 | |
| 531 | #. ... |
| 532 | |
| 533 | Known Problems |
| 534 | ============== |
| 535 | |
| 536 | LLVM is generally a production quality compiler, and is used by a broad range |
| 537 | of applications and shipping in many products. That said, not every subsystem |
| 538 | is as mature as the aggregate, particularly the more obscure1 targets. If you |
| 539 | run into a problem, please check the `LLVM bug database |
| 540 | <http://llvm.org/bugs/>`_ and submit a bug if there isn't already one or ask on |
| 541 | the `LLVMdev list <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>`_. |
| 542 | |
| 543 | Known problem areas include: |
| 544 | |
| 545 | #. The CellSPU, MSP430, and XCore backends are experimental. |
| 546 | |
| 547 | #. The integrated assembler, disassembler, and JIT is not supported by several |
| 548 | targets. If an integrated assembler is not supported, then a system |
| 549 | assembler is required. For more details, see the |
| 550 | :ref:`target-feature-matrix`. |
| 551 | |
| 552 | Additional Information |
| 553 | ====================== |
| 554 | |
| 555 | A wide variety of additional information is available on the `LLVM web page |
| 556 | <http://llvm.org/>`_, in particular in the `documentation |
| 557 | <http://llvm.org/docs/>`_ section. The web page also contains versions of the |
| 558 | API documentation which is up-to-date with the Subversion version of the source |
| 559 | code. You can access versions of these documents specific to this release by |
| 560 | going into the ``llvm/docs/`` directory in the LLVM tree. |
| 561 | |
| 562 | If you have any questions or comments about LLVM, please feel free to contact |
| 563 | us via the `mailing lists <http://llvm.org/docs/#maillist>`_. |
| 564 | |