llvm.org GIT mirror llvm / 1b76955
Merge in release notes. git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_26@84933 91177308-0d34-0410-b5e6-96231b3b80d8 Tanya Lattner 9 years ago
1 changed file(s) with 807 addition(s) and 416 deletion(s). Raw diff Collapse all Expand all
33
44
55
6 LLVM 2.<del>5</del> Release Notes
6 LLVM 2.<ins>6</ins> Release Notes
77
88
99
10
LLVM 2.5 Release Notes
10
LLVM 2.6 Release Notes
1111
1212
1313
  • Introduction
  • 1414
  • Sub-project Status Update
  • 15
  • External Projects Using LLVM 2.5
  • 16
  • What's New in LLVM 2.5?
  • 15
  • External Projects Using LLVM 2.6
  • 16
  • What's New in LLVM 2.6?
  • 1717
  • Installation Instructions
  • 1818
  • Portability and Supported Platforms
  • 1919
  • Known Problems
  • 3333
    3434
    3535

    This document contains the release notes for the LLVM Compiler

    36 Infrastructure, release 2.5. Here we describe the status of LLVM, including
    36 Infrastructure, release 2.6. Here we describe the status of LLVM, including
    3737 major improvements from the previous release and significant known problems.
    3838 All LLVM releases may be downloaded from the
    3939 href="http://llvm.org/releases/">LLVM releases web site.

    5050 releases page.

    5151
    5252
    53
    54
    61
    62
    63
    7075
    7176
    7385
    7486
    7991
    8092
    8193

    82 The LLVM 2.5 distribution currently consists of code from the core LLVM
    83 repository —which roughly includes the LLVM optimizers, code generators
    84 and supporting tools — and the llvm-gcc repository. In addition to this
    85 code, the LLVM Project includes other sub-projects that are in development. The
    86 two which are the most actively developed are the Clang
    87 Project and the VMKit Project.
    94 The LLVM 2.6 distribution currently consists of code from the core LLVM
    95 repository (which roughly includes the LLVM optimizers, code generators
    96 and supporting tools), the Clang repository and the llvm-gcc repository. In
    97 addition to this code, the LLVM Project includes other sub-projects that are in
    98 development. Here we include updates on these subprojects.
    8899

    89100
    90101
    98109
    99110
    100111

    The Clang project is an effort to build

    101 a set of new 'LLVM native' front-end technologies for the LLVM optimizer and
    102 code generator. While Clang is not included in the LLVM 2.5 release, it is
    103 continuing to make major strides forward in all areas. Its C and Objective-C
    104 parsing and code generation support is now very solid. For example, it is
    105 capable of successfully building many real-world applications for X86-32
    106 and X86-64,
    107 including the FreeBSD
    108 kernel and gcc 4.2. C++ is also
    109 making incredible progress,
    110 and work on templates has recently started. If you are
    111 interested in fast compiles and good diagnostics, we encourage you to try it out
    112 by building from mainline
    113 and reporting any issues you hit to the
    112 a set of new 'LLVM native' front-end technologies for the C family of languages.
    113 LLVM 2.6 is the first release to officially include Clang, and it provides a
    114 production quality C and Objective-C compiler. If you are interested in
    115 href="http://clang.llvm.org/performance.html">fast compiles and
    116 good diagnostics, we
    117 encourage you to try it out. Clang currently compiles typical Objective-C code
    118 3x faster than GCC and compiles C code about 30% faster than GCC at -O0 -g
    119 (which is when the most pressure is on the frontend).

    120
    121

    In addition to supporting these languages, C++ support is also

    122 href="http://clang.llvm.org/cxx_status.html">well under way, and mainline
    123 Clang is able to parse the libstdc++ 4.2 headers and even codegen simple apps.
    124 If you are interested in Clang C++ support or any other Clang feature, we
    125 strongly encourage you to get involved on the
    114126 href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">Clang front-end mailing
    115127 list.

    116128
    117

    In the LLVM 2.5 time-frame, the Clang team has made many improvements:

    118
    119
    120
  • Clang now has a new driver, which is focused on providing a GCC-compatible
  • 121 interface.
    122
  • The X86-64 ABI is now supported, including support for the Apple
  • 123 64-bit Objective-C runtime and zero cost exception handling.
    124
  • Precompiled header support is now implemented.
  • 125
  • Objective-C support is significantly improved beyond LLVM 2.4, supporting
  • 126 many features, such as Objective-C Garbage Collection.
    127
  • Variable length arrays are now fully supported.
  • 128
  • C99 designated initializers are now fully supported.
  • 129
  • Clang now includes all major compiler headers, including a
  • 130 redesigned tgmath.h and several more intrinsic headers.
    131 <li>Many many bugs are fixed and many features have been added.>
    129 <p>In the LLVM 2.6 time-frame, the Clang team has made many improvements:>
    130
    131
    132
  • C and Objective-C support are now considered production quality.
  • 133
  • AuroraUX, FreeBSD and OpenBSD are now supported.
  • 134
  • Most of Objective-C 2.0 is now supported with the GNU runtime.
  • 135
  • Many many bugs are fixed and lots of features have been added.
  • 132136
    133137
    134138
    139143
    140144
    141145
    142

    Previously announced in the last LLVM release, the Clang project also

    146

    Previously announced in the 2.4 and 2.5 LLVM releases, the Clang project also

    143147 includes an early stage static source code analysis tool for
    144148 href="http://clang.llvm.org/StaticAnalysis.html">automatically finding bugs
    145 in C and Objective-C programs. The tool performs a growing set of checks to find
    149 in C and Objective-C programs. The tool performs checks to find
    146150 bugs that occur on a specific path within a program.

    147151
    148

    In the LLVM 2.5 time-frame there have been many significant improvements to

    149 the analyzer's core path simulation engine and machinery for generating
    150 path-based bug reports to end-users. Particularly noteworthy improvements
    151 include experimental support for full field-sensitivity and reasoning about heap
    152 objects as well as an improved value-constraints subengine that does a much
    153 better job of reasoning about inequality relationships (e.g., x > 2)
    154 between variables and constants.
    152

    In the LLVM 2.6 time-frame, the analyzer core has undergone several important

    153 improvements and cleanups and now includes a new Checker interface that
    154 is intended to eventually serve as a basis for domain-specific checks. Further,
    155 in addition to generating HTML files for reporting analysis results, the
    156 analyzer can now also emit bug reports in a structured XML format that is
    157 intended to be easily readable by other programs.

    155158
    156159

    The set of checks performed by the static analyzer continues to expand, and

    157160 future plans for the tool include full source-level inter-procedural analysis
    169172
    170173

    171174 The VMKit project is an implementation of
    172 a JVM and a CLI Virtual Machines (Microsoft .NET is an
    173 implementation of the CLI) using the Just-In-Time compiler of LLVM.

    174
    175

    Following LLVM 2.5, VMKit has its second release that you can find on its

    176 webpage. The release includes
    175 a JVM and a CLI Virtual Machine (Microsoft .NET is an
    176 implementation of the CLI) using LLVM for static and just-in-time
    177 compilation.

    178
    179

    180 VMKit version 0.26 builds with LLVM 2.6 and you can find it on its
    181 web page. The release includes
    177182 bug fixes, cleanup and new features. The major changes are:

    178183
    179184
    180185
    181
  • Ahead of Time compiler: compiles .class files to llvm .bc. VMKit uses this
  • 182 functionality to native compile the standard classes (e.g. java.lang.String).
    183 Users can compile AoT .class files into dynamic libraries and run them with the
    184 help of VMKit.
    185
    186
  • New exception model: the dwarf exception model is very slow for
  • 187 exception-intensive applications, so the JVM has had a new implementation of
    188 exceptions which check at each function call if an exception happened. There is
    189 a low performance penalty on applications without exceptions, but it is a big
    190 gain for exception-intensive applications. For example the jack benchmark in
    191 Spec JVM98 is 6x faster (performance gain of 83%).
    192
    193
  • User-level management of thread stacks, so that thread local data access
  • 194 at runtime is fast and portable.
    195
    196
  • Implementation of biased locking for faster object synchronizations at
  • 197 runtime.
    198
    199
  • New support for OSX/X64, Linux/X64 (with the Boehm GC) and Linux/ppc32.
  • 200
    201
    202 </div>
    186 <li>A new llcj tool to generate shared libraries or executables of Java
    187 files.
    188
  • Cooperative garbage collection.
  • 189
  • Fast subtype checking (paper from Click et al [JGI'02]).
  • 190
  • Implementation of a two-word header for Java objects instead of the original
  • 191 three-word header.
    192
  • Better Java specification-compliance: division by zero checks, stack
  • 193 overflow checks, finalization and references support.
    194
    195
    196
    197
    198
    199
    200
    201 compiler-rt: Compiler Runtime Library
    202
    203
    204
    205

    206 The new LLVM compiler-rt project
    207 is a simple library that provides an implementation of the low-level
    208 target-specific hooks required by code generation and other runtime components.
    209 For example, when compiling for a 32-bit target, converting a double to a 64-bit
    210 unsigned integer is compiled into a runtime call to the "__fixunsdfdi"
    211 function. The compiler-rt library provides highly optimized implementations of
    212 this and other low-level routines (some are 3x faster than the equivalent
    213 libgcc routines).

    214
    215

    216 All of the code in the compiler-rt project is available under the standard LLVM
    217 License, a "BSD-style" license.

    218
    219
    220
    221
    222
    223 KLEE: Symbolic Execution and Automatic Test Case Generator
    224
    225
    226
    227

    228 The new LLVM KLEE project is a symbolic
    229 execution framework for programs in LLVM bitcode form. KLEE tries to
    230 symbolically evaluate "all" paths through the application and records state
    231 transitions that lead to fault states. This allows it to construct testcases
    232 that lead to faults and can even be used to verify algorithms. For more
    233 details, please see the
    234 href="http://llvm.org/pubs/2008-12-OSDI-KLEE.html">OSDI 2008 paper about
    235 KLEE.

    236
    237
    238
    239
    240
    241 DragonEgg: GCC-4.5 as an LLVM frontend
    242
    243
    244
    245

    246 The goal of DragonEgg is to make
    247 gcc-4.5 act like llvm-gcc without requiring any gcc modifications whatsoever.
    248 DragonEgg is a shared library (dragonegg.so)
    249 that is loaded by gcc at runtime. It uses the new gcc plugin architecture to
    250 disable the GCC optimizers and code generators, and schedule the LLVM optimizers
    251 and code generators (or direct output of LLVM IR) instead. Currently only Linux
    252 and Darwin are supported, and only on x86-32 and x86-64. It should be easy to
    253 add additional unix-like architectures and other processor families. In theory
    254 it should be possible to use DragonEgg
    255 with any language supported by gcc, however only C and Fortran work well for the
    256 moment. Ada and C++ work to some extent, while Java, Obj-C and Obj-C++ are so
    257 far entirely untested. Since gcc-4.5 has not yet been released, neither has
    258 DragonEgg. To build
    259 DragonEgg you will need to check out the
    260 development versions of gcc,
    261 llvm and
    262 DragonEgg from their respective
    263 subversion repositories, and follow the instructions in the
    264 DragonEgg README.
    265

    266
    267
    268
    269
    270
    271
    272 llvm-mc: Machine Code Toolkit
    273
    274
    275
    276

    277 The LLVM Machine Code (MC) Toolkit project is a (very early) effort to build
    278 better tools for dealing with machine code, object file formats, etc. The idea
    279 is to be able to generate most of the target specific details of assemblers and
    280 disassemblers from existing LLVM target .td files (with suitable enhancements),
    281 and to build infrastructure for reading and writing common object file formats.
    282 One of the first deliverables is to build a full assembler and integrate it into
    283 the compiler, which is predicted to substantially reduce compile time in some
    284 scenarios.
    285

    286
    287

    In the LLVM 2.6 timeframe, the MC framework has grown to the point where it

    288 can reliably parse and pretty print (with some encoding information) a
    289 darwin/x86 .s file successfully, and has the very early phases of a Mach-O
    290 assembler in progress. Beyond the MC framework itself, major refactoring of the
    291 LLVM code generator has started. The idea is to make the code generator reason
    292 about the code it is producing in a much more semantic way, rather than a
    293 textual way. For example, the code generator now uses MCSection objects to
    294 represent section assignments, instead of text strings that print to .section
    295 directives.

    296
    297

    MC is an early and ongoing project that will hopefully continue to lead to

    298 many improvements in the code generator and build infrastructure useful for many
    299 other situations.
    300

    301
    302
    303
    203304
    204305
    205306
    206 External Projects Using LLVM 2.5
    207
    208
    310
    311
    312
    313

    An exciting aspect of LLVM is that it is used as an enabling technology for

    314 a lot of other language and tools projects. This section lists some of the
    315 projects that have already been updated to work with LLVM 2.6.

    316
    317
    318
    319
    320
    321 Rubinius
    322
    323
    324
    325

    Rubinius is an environment

    326 for running Ruby code which strives to write as much of the core class
    327 implementation in Ruby as possible. Combined with a bytecode interpreting VM, it
    328 uses LLVM to optimize and compile ruby code down to machine code. Techniques
    329 such as type feedback, method inlining, and uncommon traps are all used to
    330 remove dynamism from ruby execution and increase performance.

    331
    332

    Since LLVM 2.5, Rubinius has made several major leaps forward, implementing

    333 a counter based JIT, type feedback and speculative method inlining.
    334

    335
    336
    337
    338
    339
    340 MacRuby
    341
    342
    343
    344
    345

    346 MacRuby is an implementation of Ruby on top of
    347 core Mac OS X technologies, such as the Objective-C common runtime and garbage
    348 collector and the CoreFoundation framework. It is principally developed by
    349 Apple and aims at enabling the creation of full-fledged Mac OS X applications.
    350

    351
    352

    353 MacRuby uses LLVM for optimization passes, JIT and AOT compilation of Ruby
    354 expressions. It also uses zero-cost DWARF exceptions to implement Ruby exception
    355 handling.

    356
    357
    358
    209359
    210360
    211361
    223373 an easy-to-use C interface. The interpreter uses LLVM as a backend to
    224374 JIT-compile Pure programs to fast native code.

    225375
    226

    In addition to the usual algebraic data structures, Pure also has

    227 MATLAB-style matrices in order to support numeric computations and signal
    228 processing in an efficient way. Pure is mainly aimed at mathematical
    229 applications right now, but it has been designed as a general purpose language.
    230 The dynamic interpreter environment and the C interface make it possible to use
    231 it as a kind of functional scripting language for many application areas.
    376

    Pure versions 0.31 and later have been tested and are known to work with

    377 LLVM 2.6 (and continue to work with older LLVM releases >= 2.3 as well).
    232378

    233379
    234380
    242388

    243389 LDC is an implementation of
    244390 the D Programming Language using the LLVM optimizer and code generator.
    245 The LDC project works great with the LLVM 2.5 release. General improvements in
    391 The LDC project works great with the LLVM 2.6 release. General improvements in
    246392 this
    247393 cycle have included new inline asm constraint handling, better debug info
    248 support, general bugfixes, and better x86-64 support. This has allowed
    249 some major improvements in LDC, getting us much closer to being as
    394 support, general bug fixes and better x86-64 support. This has allowed
    395 some major improvements in LDC, getting it much closer to being as
    250396 fully featured as the original DMD compiler from DigitalMars.
    251397

    252398
    257403
    258404
    259405
    260

    Roadsend PHP (rphp) is an open

    406

    407 Roadsend PHP (rphp) is an open
    261408 source implementation of the PHP programming
    262 language that uses LLVM for its optimizer, JIT, and static compiler. This is a
    409 language that uses LLVM for its optimizer, JIT and static compiler. This is a
    263410 reimplementation of an earlier project that is now based on LLVM.

    264411
    265412
    413
    414
    415 Unladen Swallow
    416
    417
    418
    419

    420 Unladen Swallow is a
    421 branch of Python intended to be fully
    422 compatible and significantly faster. It uses LLVM's optimization passes and JIT
    423 compiler.

    424
    425
    426
    427
    428 llvm-lua
    429
    430
    431
    432

    433 LLVM-Lua uses LLVM to add JIT
    434 and static compiling support to the Lua VM. Lua bytecode is analyzed to
    435 remove type checks, then LLVM is used to compile the bytecode down to machine
    436 code.

    437
    438
    439
    440
    441 IcedTea Java Virtual Machine Implementation
    442
    443
    444
    445

    446 IcedTea provides a
    447 harness to build OpenJDK using only free software build tools and to provide
    448 replacements for the not-yet free parts of OpenJDK. One of the extensions that
    449 IcedTea provides is a new JIT compiler named
    450 href="http://icedtea.classpath.org/wiki/ZeroSharkFaq">Shark which uses LLVM
    451 to provide native code generation without introducing processor-dependent
    452 code.
    453

    454
    455
    456
    266457
    267458
    268459
    269 What's New in LLVM 2.5?
    270
    271
    272
    273
    274
    275

    This release includes a huge number of bug fixes, performance tweaks, and

    460 What's New in LLVM 2.6?
    461
    462
    463
    464
    465
    466

    This release includes a huge number of bug fixes, performance tweaks and

    276467 minor improvements. Some of the major improvements and new features are listed
    277468 in this section.
    278469

    470
    279471
    280472
    281473
    285477
    286478
    287479
    288

    LLVM 2.5 includes several major new capabilities:

    289
    290
    291
  • LLVM 2.5 includes a brand new
  • 292 href="http://en.wikipedia.org/wiki/XCore">XCore backend.
    293
    294
  • llvm-gcc now generally supports the GFortran front-end, and the precompiled
  • 295 release binaries now support Fortran, even on Mac OS/X.
    296
    297
  • CMake is now used by the LLVM build process
  • 298 on Windows. It automatically generates Visual Studio project files (and
    299 more) from a set of simple text files. This makes it much easier to
    300 maintain. In time, we'd like to standardize on CMake for everything.
    301
    302
  • LLVM 2.5 now uses (and includes) Google Test for unit testing.
  • 303
    304
  • The LLVM native code generator now supports arbitrary precision integers.
  • 305 Types like i33 have long been valid in the LLVM IR, but were previously
    306 only supported by the interpreter. Note that the C backend still does not
    307 support these.
    308
    309
  • LLVM 2.5 no longer uses 'bison,' so it is easier to build on Windows.
  • 310
    311
    312
    313
    314
    315
    316
    317 llvm-gcc 4.2 Improvements
    318
    319
    320
    321
    322

    LLVM fully supports the llvm-gcc 4.2 front-end, which marries the GCC

    323 front-ends and driver with the LLVM optimizer and code generator. It currently
    324 includes support for the C, C++, Objective-C, Ada, and Fortran front-ends.

    325
    326
    327
  • In this release, the GCC inliner is completely disabled. Previously the GCC
  • 328 inliner was used to handle always-inline functions and other cases. This caused
    329 problems with code size growth, and it is completely disabled in this
    330 release.
    331
    332
  • llvm-gcc (and LLVM in general) now support code generation for stack
  • 333 canaries, which is an effective form of
    334 href="http://en.wikipedia.org/wiki/Stack-smashing_protection">buffer overflow
    335 protection. llvm-gcc supports this with the -fstack-protector
    336 command line option (just like GCC). In LLVM IR, you can request code
    337 generation for stack canaries with function attributes.
    338
    339
    340
    341
    342
    480

    LLVM 2.6 includes several major new capabilities:

    481
    482
    483
  • New compiler-rt, KLEE
  • 484 and machine code toolkit sub-projects.
    485
  • Debug information now includes line numbers when optimizations are enabled.
  • 486 This allows statistical sampling tools like OProfile and Shark to map
    487 samples back to source lines.
    488
  • LLVM now includes new experimental backends to support the MSP430, SystemZ
  • 489 and BlackFin architectures.
    490
  • LLVM supports a new Gold Linker Plugin which
  • 491 enables support for transparent
    492 link-time optimization on ELF targets when used with the Gold binutils
    493 linker.
    494
  • LLVM now supports doing optimization and code generation on multiple
  • 495 threads. Please see the LLVM
    496 Programmer's Manual for more information.
    497
  • LLVM now has experimental support for
  • 498 href="http://nondot.org/~sabre/LLVMNotes/EmbeddedMetadata.txt">embedded
    499 metadata in LLVM IR, though the implementation is not guaranteed to be
    500 final and the .bc file format may change in future releases. Debug info
    501 does not yet use this format in LLVM 2.6.
    502
    503
    504
    343505
    344506
    345507
    347509
    348510
    349511
    350

    LLVM IR has several new features that are used by our existing front-ends and

    351 can be useful if you are writing a front-end for LLVM:

    352
    353
    354
  • The shufflevector instruction
  • 355 has been generalized to allow different shuffle mask width than its input
    356 vectors. This allows you to use shufflevector to combine two
    357 "<4 x float>" vectors into a "<8 x float>" for example.
    358
    359
  • LLVM IR now supports new intrinsics for computing and acting on
  • 360 href="LangRef.html#int_overflow">overflow of integer operations. This allows
    361 efficient code generation for languages that must trap or throw an exception on
    362 overflow. While these intrinsics work on all targets, they only generate
    363 efficient code on X86 so far.
    364
    365
  • LLVM IR now supports a new private
  • 366 linkage type to produce labels that are stripped by the assembler before it
    367 produces a .o file (thus they are invisible to the linker).
    368
    369
  • LLVM IR supports two new attributes for better alias analysis. The
  • 370 href="LangRef.html#paramattrs">noalias attribute can now be used on the
    371 return value of a function to indicate that it returns new memory (e.g.
    372 'malloc', 'calloc', etc).
    373 The new nocapture attribute can be used
    374 on pointer arguments to indicate that the function does not return the pointer,
    375 store it in an object that outlives the call, or let the value of the pointer
    376 escape from the function in any other way.
    377 Note that it is the pointer itself that must not escape, not the value it
    378 points to: loading a value out of the pointer is perfectly fine.
    379 Many standard library functions (e.g. 'strlen', 'memcpy') have this property.
    380
    381
    382
    383
  • The parser for ".ll" files in lib/AsmParser is now completely rewritten as a
  • 384 recursive descent parser. This parser produces better error messages (including
    385 caret diagnostics), is less fragile (less likely to crash on strange things),
    386 does not leak memory, is more efficient, and eliminates LLVM's last use of the
    387 'bison' tool.
    388
    389
  • Debug information representation and manipulation internals have been
  • 390 consolidated to use a new set of classes in
    391 llvm/Analysis/DebugInfo.h. These routines are more
    392 efficient, robust, and extensible and replace the older mechanisms.
    393 llvm-gcc, clang, and the code generator now use them to create and process
    394 debug information.
    395
    512

    LLVM IR has several new features for better support of new targets and that

    513 expose new optimization opportunities:

    514
    515
    516
  • The add,
  • 517 href="LangRef.html#i_sub">sub and mul
    518 instructions have been split into integer and floating point versions (like
    519 divide and remainder), introducing new
    520 href="LangRef.html#i_fadd">fadd, fsub,
    521 and fmul instructions.
    522
  • The add,
  • 523 href="LangRef.html#i_sub">sub and mul
    524 instructions now support optional "nsw" and "nuw" bits which indicate that
    525 the operation is guaranteed to not overflow (in the signed or
    526 unsigned case, respectively). This gives the optimizer more information and
    527 can be used for things like C signed integer values, which are undefined on
    528 overflow.
    529
  • The sdiv instruction now supports an
  • 530 optional "exact" flag which indicates that the result of the division is
    531 guaranteed to have a remainder of zero. This is useful for optimizing pointer
    532 subtraction in C.
    533
  • The getelementptr instruction now
  • 534 supports arbitrary integer index values for array/pointer indices. This
    535 allows for better code generation on 16-bit pointer targets like PIC16.
    536
  • The getelementptr instruction now
  • 537 supports an "inbounds" optimization hint that tells the optimizer that the
    538 pointer is guaranteed to be within its allocated object.
    539
  • LLVM now support a series of new linkage types for global values which allow
  • 540 for better optimization and new capabilities:
    541
    542
  • linkonce_odr and
  • 543 weak_odr have the same linkage
    544 semantics as the non-"odr" linkage types. The difference is that these
    545 linkage types indicate that all definitions of the specified function
    546 are guaranteed to have the same semantics. This allows inlining
    547 templates functions in C++ but not inlining weak functions in C,
    548 which previously both got the same linkage type.
    549
  • available_externally
  • 550 is a new linkage type that gives the optimizer visibility into the
    551 definition of a function (allowing inlining and side effect analysis)
    552 but that does not cause code to be generated. This allows better
    553 optimization of "GNU inline" functions, extern templates, etc.
    554
  • linker_private is a
  • 555 new linkage type (which is only useful on Mac OS X) that is used for
    556 some metadata generation and other obscure things.
    557
    558
  • Finally, target-specific intrinsics can now return multiple values, which
  • 559 is useful for modeling target operations with multiple results.
    396560
    397561
    398562
    404568
    405569
    406570
    407

    In addition to a large array of bug fixes and minor performance tweaks, this

    571

    In addition to a large array of minor performance tweaks and bug fixes, this

    408572 release includes a few major enhancements and additions to the optimizers:

    409573
    410574
    411575
    412
  • The loop optimizer now improves floating point induction variables in
  • 413 several ways, including adding shadow induction variables to avoid
    414 "integer <-> floating point" conversions in loops when safe.
    415
    416
  • The "-mem2reg" pass is now much faster on code with large basic blocks.
  • 417
    418
  • The "-jump-threading" pass is more powerful: it is iterative
  • 419 and handles threading based on values with fully and partially redundant
    420 loads.
    421
    422
  • The "-memdep" memory dependence analysis pass (used by GVN and memcpyopt) is
  • 423 both faster and more aggressive.
    424
    425
  • The "-scalarrepl" scalar replacement of aggregates pass is more aggressive
  • 426 about promoting unions to registers.
    427
    576
  • The Scalar Replacement of Aggregates
  • 577 pass has many improvements that allow it to better promote vector unions,
    578 variables which are memset, and much more strange code that can happen to
    579 do bitfield accesses to register operations. An interesting change is that
    580 it now produces "unusual" integer sizes (like i1704) in some cases and lets
    581 other optimizers clean things up.
    582
  • The Loop Strength Reduction pass now
  • 583 promotes small integer induction variables to 64-bit on 64-bit targets,
    584 which provides a major performance boost for much numerical code. It also
    585 promotes shorts to int on 32-bit hosts, etc. LSR now also analyzes pointer
    586 expressions (e.g. getelementptrs), as well as integers.
    587
  • The GVN pass now eliminates partial
  • 588 redundancies of loads in simple cases.
    589
  • The Inliner now reuses stack space when
  • 590 inlining similar arrays from multiple callees into one caller.
    591
  • LLVM includes a new experimental Static Single Information (SSI)
  • 592 construction pass.
    593
    594
    595
    596
    597
    598
    599
    600
    601 Interpreter and JIT Improvements
    602
    603
    604
    605
    606
    607
  • LLVM has a new "EngineBuilder" class which makes it more obvious how to
  • 608 set up and configure an ExecutionEngine (a JIT or interpreter).
    609
  • The JIT now supports generating more than 16M of code.
  • 610
  • When configured with --with-oprofile, the JIT can now inform
  • 611 OProfile about JIT'd code, allowing OProfile to get line number and function
    612 name information for JIT'd functions.
    613
  • When "libffi" is available, the LLVM interpreter now uses it, which supports
  • 614 calling almost arbitrary external (natively compiled) functions.
    615
  • Clients of the JIT can now register a 'JITEventListener' object to receive
  • 616 callbacks when the JIT emits or frees machine code. The OProfile support
    617 uses this mechanism.
    428618
    429619
    430620
    441631 it run faster:

    442632
    443633
    444
  • The Writing an LLVM Compiler
  • 445 Backend document has been greatly expanded and is substantially more
    446 complete.
    447
    448
  • The SelectionDAG type legalization logic has been completely rewritten, is
  • 449 now more powerful (it supports arbitrary precision integer types for example),
    450 and is more correct in several corner cases. The type legalizer converts
    451 operations on types that are not natively supported by the target machine into
    452 equivalent code sequences that only use natively supported types. The old type
    453 legalizer is still available (for now) and will be used if
    454 -disable-legalize-types is passed to the code generator.
    634
    635
  • The llc -asm-verbose option (exposed from llvm-gcc as -dA
  • 636 and clang as -fverbose-asm or -dA) now adds a lot of
    637 useful information in comments to
    638 the generated .s file. This information includes location information (if
    639 built with -g) and loop nest information.
    640
  • The code generator now supports a new MachineVerifier pass which is useful
  • 641 for finding bugs in targets and codegen passes.
    642
  • The Machine LICM is now enabled by default. It hoists instructions out of
  • 643 loops (such as constant pool loads, loads from read-only stubs, vector
    644 constant synthesization code, etc.) and is currently configured to only do
    645 so when the hoisted operation can be rematerialized.
    646
  • The Machine Sinking pass is now enabled by default. This pass moves
  • 647 side-effect free operations down the CFG so that they are executed on fewer
    648 paths through a function.
    649
  • The code generator now performs "stack slot coloring" of register spills,
  • 650 which allows spill slots to be reused. This leads to smaller stack frames
    651 in cases where there are lots of register spills.
    652
  • The register allocator has many improvements to take better advantage of
  • 653 commutable operations, various spiller peephole optimizations, and can now
    654 coalesce cross-register-class copies.
    655
  • Tblgen now supports multiclass inheritance and a number of new string and
  • 656 list operations like !(subst), !(foreach), !car,
    657 !cdr, !null, !if, !cast.
    658 These make the .td files more expressive and allow more aggressive factoring
    659 of duplication across instruction patterns.
    660
  • Target-specific intrinsics can now be added without having to hack VMCore to
  • 661 add them. This makes it easier to maintain out-of-tree targets.
    662
  • The instruction selector is better at propagating information about values
  • 663 (such as whether they are sign/zero extended etc.) across basic block
    664 boundaries.
    665
  • The SelectionDAG datastructure has new nodes for representing buildvector
  • 666 and vector shuffle operations. This
    667 makes operations and pattern matching more efficient and easier to get
    668 right.
    669
  • The Prolog/Epilog Insertion Pass now has experimental support for performing
  • 670 the "shrink wrapping" optimization, which moves spills and reloads around in
    671 the CFG to avoid doing saves on paths that don't need them.
    672
  • LLVM includes new experimental support for writing ELF .o files directly
  • 673 from the compiler. It works well for many simple C testcases, but doesn't
    674 support exception handling, debug info, inline assembly, etc.
    675
  • Targets can now specify register allocation hints through
  • 676 MachineRegisterInfo::setRegAllocationHint. A regalloc hint consists
    677 of hint type and physical register number. A hint type of zero specifies a
    678 register allocation preference. Other hint type values are target specific
    679 which are resolved by TargetRegisterInfo::ResolveRegAllocHint. An
    680 example is the ARM target which uses register hints to request that the
    681 register allocator provide an even / odd register pair to two virtual
    682 registers.
    683
    684
    685
    686
    687
    688 X86-32 and X86-64 Target Improvements
    689
    690
    691
    692

    New features of the X86 target include:

    693

    694
    695
    696
    697
  • SSE 4.2 builtins are now supported.
  • 698
  • GCC-compatible soft float modes are now supported, which are typically used
  • 699 by OS kernels.
    700
  • X86-64 now models implicit zero extensions better, which allows the code
  • 701 generator to remove a lot of redundant zexts. It also models the 8-bit "H"
    702 registers as subregs, which allows them to be used in some tricky
    703 situations.
    704
  • X86-64 now supports the "local exec" and "initial exec" thread local storage
  • 705 model.
    706
  • The vector forms of the icmp and
  • 707 href="LangRef.html#i_fcmp">fcmp instructions now select to efficient
    708 SSE operations.
    709
  • Support for the win64 calling conventions have improved. The primary
  • 710 missing feature is support for varargs function definitions. It seems to
    711 work well for many win64 JIT purposes.
    712
  • The X86 backend has preliminary support for
  • 713 href="CodeGenerator.html#x86_memory">mapping address spaces to segment
    714 register references. This allows you to write GS or FS relative memory
    715 accesses directly in LLVM IR for cases where you know exactly what you're
    716 doing (such as in an OS kernel). There are some known problems with this
    717 support, but it works in simple cases.
    718
  • The X86 code generator has been refactored to move all global variable
  • 719 reference logic to one place
    720 (X86Subtarget::ClassifyGlobalReference) which
    721 makes it easier to reason about.
    722
    723
    724
    725
    726
    727
    728
    729 PIC16 Target Improvements
    730
    731
    732
    733

    New features of the PIC16 target include:

    734

    735
    736
    737
  • Support for floating-point, indirect function calls, and
  • 738 passing/returning aggregate types to functions.
    739
  • The code generator is able to generate debug info into output COFF files.
  • 740
  • Support for placing an object into a specific section or at a specific
  • 741 address in memory.
    742
    743
    744

    Things not yet supported:

    745
    746
    747
  • Variable arguments.
  • 748
  • Interrupts/programs.
  • 749
    750
    751
    752
    753
    754
    755 ARM Target Improvements
    756
    757
    758
    759

    New features of the ARM target include:

    760

    761
    762
    763
    764
  • Preliminary support for processors, such as the Cortex-A8 and Cortex-A9,
  • 765 that implement version v7-A of the ARM architecture. The ARM backend now
    766 supports both the Thumb2 and Advanced SIMD (Neon) instruction sets.
    767
    768
  • The AAPCS-VFP "hard float" calling conventions are also supported with the
  • 769 -float-abi=hard flag.
    770
    771
  • The ARM calling convention code is now tblgen generated instead of resorting
  • 772 to C++ code.
    773
    774
    775

    These features are still somewhat experimental

    776 and subject to change. The Neon intrinsics, in particular, may change in future
    777 releases of LLVM. ARMv7 support has progressed a lot on top of tree since 2.6
    778 branched.

    779
    780
    781
    782
    783
    784
    785 Other Target Specific Improvements
    786
    787
    788
    789

    New features of other targets include:

    790

    791
    792
    793
  • Mips now supports O32 Calling Convention.
  • 794
  • Many improvements to the 32-bit PowerPC SVR4 ABI (used on powerpc-linux)
  • 795 support, lots of bugs fixed.
    796
  • Added support for the 64-bit PowerPC SVR4 ABI (used on powerpc64-linux).
  • 797 Needs more testing.
    798
    799
    800
    801
    802
    803
    804 New Useful APIs
    805
    806
    807
    808
    809

    This release includes a number of new APIs that are used internally, which

    810 may also be useful for external clients.
    811

    812
    813
    814
  • New
  • 815 PrettyStackTrace class allows crashes of llvm tools (and applications
    816 that integrate them) to provide more detailed indication of what the
    817 compiler was doing at the time of the crash (e.g. running a pass).
    818 At the top level for each LLVM tool, it includes the command line arguments.
    819
    820
  • New StringRef
  • 821 and Twine classes
    822 make operations on character ranges and
    823 string concatenation to be more efficient. StringRef is just a const
    824 char* with a length, Twine is a light-weight rope.
    825
  • LLVM has new WeakVH, AssertingVH and CallbackVH
  • 826 classes, which make it easier to write LLVM IR transformations. WeakVH
    827 is automatically drops to null when the referenced Value is deleted,
    828 and is updated across a replaceAllUsesWith operation.
    829 AssertingVH aborts the program if the
    830 referenced value is destroyed while it is being referenced. CallbackVH
    831 is a customizable class for handling value references. See
    832 href="http://llvm.org/doxygen/ValueHandle_8h-source.html">ValueHandle.h
    833 for more information.
    834
  • The new 'Triple
  • 835 ' class centralizes a lot of logic that reasons about target
    836 triples.
    837
  • The new '
  • 838 llvm_report_error()' set of APIs allows tools to embed the LLVM
    839 optimizer and backend and recover from previously unrecoverable errors.
    840
  • LLVM has new abstractions for
  • 841 href="http://llvm.org/doxygen/Atomic_8h-source.html">atomic operations
    842 and reader/writer
    843 locks.
    844
  • LLVM has new
  • 845 SourceMgr and SMLoc classes which implement caret
    846 diagnostics and basic include stack processing for simple parsers. It is
    847 used by tablegen, llvm-mc, the .ll parser and FileCheck.
    848
    849
    850
    851
    852
    853
    854
    855 Other Improvements and New Features
    856
    857
    858
    859

    Other miscellaneous features include:

    860
    861
    862
  • LLVM now includes a new internal '
  • 863 href="http://llvm.org/cmds/FileCheck.html">FileCheck' tool which allows
    864 writing much more accurate regression tests that run faster. Please see the
    865 FileCheck section of the Testing
    866 Guide for more information.
    867
  • LLVM profile information support has been significantly improved to produce
  • 868 correct use counts, and has support for edge profiling with reduced runtime
    869 overhead. Combined, the generated profile information is both more correct and
    870 imposes about half as much overhead (2.6. from 12% to 6% overhead on SPEC
    871 CPU2000).
    872
  • The C bindings (in the llvm/include/llvm-c directory) include many newly
  • 873 supported APIs.
    874
  • LLVM 2.6 includes a brand new experimental LLVM bindings to the Ada2005
  • 875 programming language.
    876
    877
  • The LLVMC driver has several new features:
  • 878
    879
  • Dynamic plugins now work on Windows.
  • 880
  • New option property: init. Makes possible to provide default values for
  • 881 options defined in plugins (interface to cl::init).
    882
  • New example: Skeleton, shows how to create a standalone LLVMC-based
  • 883 driver.
    884
  • New example: mcc16, a driver for the PIC16 toolchain.
  • 885
    455886
    456887
    457
  • The code generator now supports widening illegal vectors to larger legal
  • 458 ones (for example, converting operations on <3 x float> to work on
    459 <4 x float>) which is very important for common graphics
    460 applications.
    461
    462
  • The assembly printers for each target are now split out into their own
  • 463 libraries that are separate from the main code generation logic. This reduces
    464 the code size of JIT compilers by not requiring them to be linked in.
    465
    466
  • The 'fast' instruction selection path (used at -O0 and for fast JIT
  • 467 compilers) now supports accelerating codegen for code that uses exception
    468 handling constructs.
    469
    470
  • The optional PBQP register allocator now supports register coalescing.
  • 471
    472
    473
    474
    475
    476 X86-32 and X86-64 Target Improvements
    477
    478
    479
    480

    New features of the X86 target include:

    481

    482
    483
    484
  • The llvm.returnaddress
  • 485 intrinsic (which is used to implement __builtin_return_address) now
    486 supports non-zero stack depths on X86.
    487
    488
  • The X86 backend now supports code generation of vector shift operations
  • 489 using SSE instructions.
    490
    491
  • X86-64 code generation now takes advantage of red zone, unless the
  • 492 -mno-red-zone option is specified.
    493
    494
  • The X86 backend now supports using address space #256 in LLVM IR as a way of
  • 495 performing memory references off the GS segment register. This allows a
    496 front-end to take advantage of very low-level programming techniques when
    497 targeting X86 CPUs. See test/CodeGen/X86/movgs.ll for a simple
    498 example.
    499
    500
  • The X86 backend now supports a -disable-mmx command line option to
  • 501 prevent use of MMX even on chips that support it. This is important for cases
    502 where code does not contain the proper llvm.x86.mmx.emms
    503 intrinsics.
    504
    505
  • The X86 JIT now detects the new Intel
  • 506 href="http://en.wikipedia.org/wiki/Intel_Core_i7">Core i7 and
    507 href="http://en.wikipedia.org/wiki/Intel_Atom">Atom chips and
    508 auto-configures itself appropriately for the features of these chips.
    509
    510
  • The JIT now supports exception handling constructs on Linux/X86-64 and
  • 511 Darwin/x86-64.
    512
    513
  • The JIT supports Thread Local Storage (TLS) on Linux/X86-32 but not yet on
  • 514 X86-64.
    515
    516
    517
    518
    519
    520
    521 PIC16 Target Improvements
    522
    523
    524
    525

    New features of the PIC16 target include:

    526

    527
    528
    529
  • Both direct and indirect load/stores work now.
  • 530
  • Logical, bitwise and conditional operations now work for integer data
  • 531 types.
    532
  • Function calls involving basic types work now.
  • 533
  • Support for integer arrays.
  • 534
  • The compiler can now emit libcalls for operations not supported by m/c
  • 535 instructions.
    536
  • Support for both data and ROM address spaces.
  • 537
    538
    539

    Things not yet supported:

    540
    541
    542
  • Floating point.
  • 543
  • Passing/returning aggregate types to and from functions.
  • 544
  • Variable arguments.
  • 545
  • Indirect function calls.
  • 546
  • Interrupts/programs.
  • 547
  • Debug info.
  • 548
    549
    550
    551
    552
    553
    554
    555 Improvements in LLVMC
    556
    557
    558
    559

    New features include:

    560
    561
    562
  • Beginning with LLVM 2.5, llvmc2 is known as
  • 563 just llvmc. The old llvmc driver was removed.
    564
    565
  • The Clang plugin was substantially improved and is now enabled
  • 566 by default. The command llvmc --clang can be now used as a
    567 synonym to ccc.
    568
    569
  • There is now a --check-graph option, which is supposed to catch
  • 570 common errors like multiple default edges, mismatched output/input language
    571 names and cycles. In general, these checks can't be done at compile-time
    572 because of the need to support plugins.
    573
    574
  • Plugins are now more flexible and can refer to compilation graph nodes and
  • 575 options defined in other plugins. To manage dependencies, a priority-sorting
    576 mechanism was introduced. This change affects the TableGen file syntax. See the
    577 documentation for details.
    578
    579
  • Hooks can now be provided with arguments. The syntax is "$CALL(MyHook,
  • 580 'Arg1', 'Arg2', 'Arg3')".
    581
    582
  • A new option type: multi-valued option, for options that take more than one
  • 583 argument (for example, "-foo a b c").
    584
    585
  • New option properties: 'one_or_more', 'zero_or_more',
  • 586 'hidden' and 'really_hidden'.
    587
    588
  • The 'case' expression gained an 'error' action and
  • 589 an 'empty' test (equivalent to "(not (not_empty ...))").
    590
    591
  • Documentation now looks more consistent to the rest of the LLVM
  • 592 docs. There is also a man page now.
    593
    594888
    595889
    596890
    604898
    605899
    606900

    If you're already an LLVM user or developer with out-of-tree changes based

    607 on LLVM 2.4, this section lists some "gotchas" that you may run into upgrading
    901 on LLVM 2.5, this section lists some "gotchas" that you may run into upgrading
    608902 from the previous release.

    609903
    610904
    611
    612
  • llvm-gcc defaults to -fno-math-errno on all X86 targets.
  • 613
    905
  • The Itanium (IA64) backend has been removed. It was not actively supported
  • 906 and had bitrotted.
    907
  • The BigBlock register allocator has been removed, it had also bitrotted.
  • 908
  • The C Backend (-march=c) is no longer considered part of the LLVM release
  • 909 criteria. We still want it to work, but no one is maintaining it and it lacks
    910 support for arbitrary precision integers and other important IR features.
    911
    912
  • All LLVM tools now default to overwriting their output file, behaving more
  • 913 like standard unix tools. Previously, this only happened with the '-f'
    914 option.
    915
  • LLVM build now builds all libraries as .a files instead of some
  • 916 libraries as relinked .o files. This requires some APIs like
    917 InitializeAllTargets.h.
    918
    614919
    615920
    616921
    618923 API changes are:

    619924
    620925
    621
  • Some deprecated interfaces to create Instruction subclasses, that
  • 622 were spelled with lower case "create," have been removed.
    926
  • All uses of hash_set and hash_map have been removed from
  • 927 the LLVM tree and the wrapper headers have been removed.
    928
  • The llvm/Streams.h and DOUT member of Debug.h have been removed. The
  • 929 llvm::Ostream class has been completely removed and replaced with
    930 uses of raw_ostream.
    931
  • LLVM's global uniquing tables for Types and Constants have
  • 932 been privatized into members of an LLVMContext. A number of APIs
    933 now take an LLVMContext as a parameter. To smooth the transition
    934 for clients that will only ever use a single context, the new
    935 getGlobalContext() API can be used to access a default global
    936 context which can be passed in any and all cases where a context is
    937 required.
    938
  • The getABITypeSize methods are now called getAllocSize.
  • 939
  • The Add, Sub and Mul operators are no longer
  • 940 overloaded for floating-point types. Floating-point addition, subtraction
    941 and multiplication are now represented with new operators FAdd,
    942 FSub and FMul. In the IRBuilder API,
    943 CreateAdd, CreateSub, CreateMul and
    944 CreateNeg should only be used for integer arithmetic now;
    945 CreateFAdd, CreateFSub, CreateFMul and
    946 CreateFNeg should now be used for floating-point arithmetic.
    947
  • The DynamicLibrary class can no longer be constructed, its functionality has
  • 948 moved to static member functions.
    949
  • raw_fd_ostream's constructor for opening a given filename now
  • 950 takes an extra Force argument. If Force is set to
    951 false, an error will be reported if a file with the given name
    952 already exists. If Force is set to true, the file will
    953 be silently truncated (which is the behavior before this flag was
    954 added).
    955
  • SCEVHandle no longer exists, because reference counting is no
  • 956 longer done for SCEV* objects, instead const SCEV*
    957 should be used.
    958
    959
  • Many APIs, notably llvm::Value, now use the StringRef
  • 960 and Twine classes instead of passing const char*
    961 or std::string, as described in
    962 the Programmer's Manual. Most
    963 clients should be unaffected by this transition, unless they are used to
    964 Value::getName() returning a string. Here are some tips on updating to
    965 2.6:
    966
    967
  • getNameStr() is still available, and matches the old
  • 968 behavior. Replacing getName() calls with this is an safe option,
    969 although more efficient alternatives are now possible.
    970
    971
  • If you were just relying on getName() being able to be sent to
  • 972 a std::ostream, consider migrating
    973 to llvm::raw_ostream.
    974
    975
  • If you were using getName().c_str() to get a const
  • 976 char* pointer to the name, you can use getName().data().
    977 Note that this string (as before), may not be the entire name if the
    978 name contains embedded null characters.
    979
    980
  • If you were using operator + on the result of getName() and
  • 981 treating the result as an std::string, you can either
    982 use Twine::str to get the result as an std::string, or
    983 could move to a Twine based design.
    984
    985
  • isName() should be replaced with comparison
  • 986 against getName() (this is now efficient).
    987
    988
    989
    990
  • The registration interfaces for backend Targets has changed (what was
  • 991 previously TargetMachineRegistry). For backend authors, see the
    992 href="WritingAnLLVMBackend.html#TargetRegistration">Writing An LLVM Backend
    993 guide. For clients, the notable API changes are:
    994
    995
  • TargetMachineRegistry has been renamed
  • 996 to TargetRegistry.
    997
    998
  • Clients should move to using the TargetRegistry::lookupTarget()
  • 999 function to find targets.
    1000
    1001
    6231002
    6241003
    6251004
    6381017
    6391018
    6401019
  • Intel and AMD machines (IA32, X86-64, AMD64, EMT-64) running Red Hat
  • 641 Linux, Fedora Core and FreeBSD (and probably other unix-like systems).
    1020 Linux, Fedora Core, FreeBSD and AuroraUX (and probably other unix-like
    1021 systems).
    6421022
  • PowerPC and X86-based Mac OS X systems, running 10.3 and above in 32-bit
  • 643 and 64-bit modes.
    1023 and 64-bit modes.
    6441024
  • Intel and AMD machines running on Win32 using MinGW libraries (native).
  • 6451025
  • Intel and AMD machines running on Win32 with the Cygwin libraries (limited
  • 6461026 support is available for native builds with Visual C++).
    647
  • Sun UltraSPARC workstations running Solaris 10.
  • 1027
  • Sun x86 and AMD64 machines running Solaris 10, OpenSolaris 0906.
  • 6481028
  • Alpha-based machines running Debian GNU/Linux.
  • 649
  • Itanium-based (IA64) machines running Linux and HP-UX.
  • 6501029
    6511030
    6521031

    The core LLVM infrastructure uses GNU autoconf to adapt itself

    6681047 listed by component. If you run into a problem, please check the
    6691048 href="http://llvm.org/bugs/">LLVM bug database and submit a bug if
    6701049 there isn't already one.

    1050
    1051
    1052
  • The llvm-gcc bootstrap will fail with some versions of binutils (e.g. 2.15)
  • 1053 with a message of "Error: can not do 8
    1054 byte pc-relative relocation" when building C++ code. We intend to
    1055 fix this on mainline, but a workaround for 2.6 is to upgrade to binutils
    1056 2.17 or later.
    1057
    1058
  • LLVM will not correctly compile on Solaris and/or OpenSolaris
  • 1059 using the stock GCC 3.x.x series 'out the box',
    1060 See: Broken versions of GCC and other tools.
    1061 However, A Modern GCC Build
    1062 for x86/x86-64 has been made available from the third party AuroraUX Project
    1063 that has been meticulously tested for bootstrapping LLVM & Clang.
    1064
    6711065
    6721066
    6731067
    6861080 href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev list.

    6871081
    6881082
    689
  • The MSIL, IA64, Alpha, SPU, MIPS, and PIC16 backends are experimental.
  • 1083
  • The MSIL, Alpha, SPU, MIPS, PIC16, Blackfin, MSP430 and SystemZ backends are
  • 1084 experimental.
    6901085
  • The llc "-filetype=asm" (the default) is the only
  • 691 supported value for this option.
    1086 supported value for this option. The ELF writer is experimental.
    1087
  • The implementation of Andersen's Alias Analysis has many known bugs.
  • 6921088
    6931089
    6941090
    7431139
    7441140
    7451141
    1142
  • Support for the Advanced SIMD (Neon) instruction set is still incomplete
  • 1143 and not well tested. Some features may not work at all, and the code quality
    1144 may be poor in some cases.
    7461145
  • Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6
  • 7471146 processors, thumb programs can crash or produce wrong
    7481147 results (PR1388).
    7491148
  • Compilation for ARM Linux OABI (old ABI) is supported but not fully tested.
  • 7501149
    751
  • There is a bug in QEMU-ARM (<= 0.9.0) which causes it to incorrectly
  • 752 execute
    753 programs compiled with LLVM. Please use more recent versions of QEMU.
    7541150
    7551151
    7561152
    7771173
    7781174
    7791175
    780
  • The O32 ABI is not fully supported.
  • 7811176
  • 64-bit MIPS targets are not supported yet.
  • 7821177
    7831178
    7961191 appropriate nops inserted to ensure restartability.
    7971192
    7981193
    799
    800
    801
    802
    803 Known problems with the IA64 back-end
    804
    805
    806
    807
    808
    809
  • The Itanium backend is highly experimental and has a number of known
  • 810 issues. We are looking for a maintainer for the Itanium backend. If you
    811 are interested, please contact the LLVMdev mailing list.
    812
    813
    8141194
    8151195
    8161196
    8401220
    8411221
    8421222
    843

    llvm-gcc does not currently support Link-Time

    844 Optimization on most platforms "out-of-the-box". Please inquire on the
    845 LLVMdev mailing list if you are interested.

    846
    8471223

    The only major language feature of GCC not supported by llvm-gcc is

    8481224 the __builtin_apply family of builtins. However, some extensions
    8491225 are only supported on some targets. For example, trampolines are only
    8811257
    8821258
    8831259
  • Fortran support generally works, but there are still several unresolved bugs
  • 884 in Bugzilla. Please see the tools/gfortran component for details.
    1260 in Bugzilla. Please see the
    1261 tools/gfortran component for details.
    8851262
    8861263
    8871264
    9011278
  • The Ada front-end fails to bootstrap.
  • 9021279 This is due to lack of LLVM support for setjmp/longjmp style
    9031280 exception handling, which is used internally by the compiler.
    904 Workaround: configure with --disable-bootstrap.
    1281 Workaround: configure with --disable-bootstrap.
    9051282
  • The c380004, c393010
  • 9061283 and cxg2021 ACATS tests fail
    9071284 (c380004 also fails with gcc-4.2 mainline).
    9081285 If the compiler is built with checks disabled then c393010
    9091286 causes the compiler to go into an infinite loop, using up all system memory.
    9101287
  • Some GCC specific Ada tests continue to crash the compiler.
  • 911
  • The -E binder option (exception backtraces)
  • 1288
  • The -E binder option (exception backtraces)
  • 9121289 does not work and will result in programs
    913 crashing if an exception is raised. Workaround: do not use -E.
    1290 crashing if an exception is raised. Workaround: do not use -E.
    9141291
  • Only discrete types are allowed to start
  • 9151292 or finish at a non-byte offset in a record. Workaround: do not pack records
    9161293 or use representation clauses that result in a field of a non-discrete type
    9241301
    9251302
    9261303
    1304
    1305
    1306 Known problems with the O'Caml bindings
    1307
    1308
    1309
    1310
    1311

    The Llvm.Linkage module is broken, and has incorrect values. Only

    1312 Llvm.Linkage.External, Llvm.Linkage.Available_externally, and
    1313 Llvm.Linkage.Link_once will be correct. If you need any of the other linkage
    1314 modes, you'll have to write an external C library in order to expose the
    1315 functionality. This has been fixed in the trunk.

    1316
    1317
    9271318
    9281319
    9291320 Additional Information