llvm.org GIT mirror llvm / 5b6bd31
2.5 release notes. git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_25@65923 91177308-0d34-0410-b5e6-96231b3b80d8 Tanya Lattner 11 years ago
1 changed file(s) with 482 addition(s) and 421 deletion(s). Raw diff Collapse all Expand all
33
44
55
6 LLVM 2.<del>4</del> Release Notes
6 LLVM 2.<ins>5</ins> Release Notes
77
88
99
10
LLVM 2.4 Release Notes
10
LLVM 2.5 Release Notes
1111
1212
1313
  • Introduction
  • 1414
  • Sub-project Status Update
  • 15
  • What's New in LLVM?
  • 15
  • External Projects Using LLVM 2.5
  • 16
  • What's New in LLVM 2.5?
  • 1617
  • Installation Instructions
  • 1718
  • Portability and Supported Platforms
  • 1819
  • Known Problems
  • 3233
    3334
    3435

    This document contains the release notes for the LLVM Compiler

    35 Infrastructure, release 2.4. Here we describe the status of LLVM, including
    36 Infrastructure, release 2.5. Here we describe the status of LLVM, including
    3637 major improvements from the previous release and significant known problems.
    37 All LLVM releases may be downloaded from the
    38 All LLVM releases may be downloaded from the
    3839 href="http://llvm.org/releases/">LLVM releases web site.

    3940
    4041

    For more information about LLVM, including information about the latest

    5051
    5152
    5253
    53
    6070
    6171
    72 -->
    6573
    6674
    6775
    7179
    7280
    7381

    74 The LLVM 2.4 distribution currently consists of code from the core LLVM
    75 repository (which roughly includes the LLVM optimizers, code generators and
    76 supporting tools) and the llvm-gcc repository. In addition to this code, the
    77 LLVM Project includes other sub-projects that are in development. The two which
    78 are the most actively developed are the Clang Project and
    79 the VMKit Project.
    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.
    8088

    8189
    8290
    9098
    9199
    92100

    The Clang project is an effort to build

    93 a set of new 'LLVM native' front-end technologies for the LLVM optimizer
    94 and code generator. Clang is continuing to make major strides forward in all
    95 areas. Its C and Objective-C parsing support is very solid, and the code
    96 generation support is far enough along to build many C applications. While not
    97 yet production quality, it is progressing very nicely. In addition, C++
    98 front-end work has started to make significant progress.

    99
    100

    Clang, in conjunction with the ccc driver, is now usable as a

    101 replacement for gcc for building some small- to medium-sized C applications.
    102 Additionally, Clang now has code generation support for Objective-C on Mac OS X
    103 platform. Major highlights include:

    104
    105
    106
  • Clang/ccc pass almost all of the LLVM test suite on Mac OS X and Linux
  • 107 on the 32-bit x86 architecture. This includes significant C
    108 applications such as sqlite3,
    109 lua, and
    110 Clam AntiVirus.
    111
    112
  • Clang can build the majority of Objective-C examples shipped with the
  • 113 Mac OS X Developer Tools.
    114
    115
    116

    Clang code generation still needs considerable testing and development,

    117 however. Some areas under active development include:

    118
    119
    120
  • Improved support for C and Objective-C features, for example
  • 121 variable-length arrays, va_arg, exception handling (Obj-C), and garbage
    122 collection (Obj-C).
    123
  • ABI compatibility, especially for platforms other than 32-bit
  • 124 x86.
    125
    126
    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
    114 href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">Clang front-end mailing
    115 list.

    116
    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
  • Many many bugs are fixed and many features have been added.
  • 132
    127133
    128134
    129135
    133139
    134140
    135141
    136

    The Clang project also includes an early stage static source code analysis

    137 tool for automatically
    138 finding bugs in C and Objective-C programs. The tool performs a growing set
    139 of checks to find bugs that occur on a specific path within a program. Examples
    140 of bugs the tool finds include logic errors such as null dereferences,
    141 violations of various API rules, dead code, and potential memory leaks in
    142 Objective-C programs. Since its inception, public feedback on the tool has been
    143 extremely positive, and conservative estimates put the number of real bugs it
    144 has found in industrial-quality software on the order of thousands.

    145
    146

    The tool also provides a simple web GUI to inspect potential bugs found by

    147 the tool. While still early in development, the GUI illustrates some of the key
    148 features of Clang: accurate source location information, which is used by the
    149 GUI to highlight specific code expressions that relate to a bug (including those
    150 that span multiple lines); and built-in knowledge of macros, which is used to
    151 perform inline expansion of macros within the GUI itself.

    152
    153

    The set of checks performed by the static analyzer is gradually expanding,

    154 and future plans for the tool include full source-level inter-procedural
    155 analysis and deeper checks such as buffer overrun detection. There are many
    156 opportunities to extend and enhance the static analyzer, and anyone interested
    157 in working on this project is encouraged to get involved!

    142

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

    143 includes an early stage static source code analysis tool for
    144 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
    146 bugs that occur on a specific path within a program.

    147
    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.
    155
    156

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

    157 future plans for the tool include full source-level inter-procedural analysis
    158 and deeper checks such as buffer overrun detection. There are many opportunities
    159 to extend and enhance the static analyzer, and anyone interested in working on
    160 this project is encouraged to get involved!

    158161
    159162
    160163
    169172 a JVM and a CLI Virtual Machines (Microsoft .NET is an
    170173 implementation of the CLI) using the Just-In-Time compiler of LLVM.

    171174
    172

    Following LLVM 2.4, VMKit has its first release 0.24 that you can find on its

    175

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

    173176 webpage. The release includes
    174177 bug fixes, cleanup and new features. The major changes are:

    175178
    176179
    177180
    178
  • Support for generics in the .Net virtual machine.
  • 179
  • Initial support for the Mono class libraries.
  • 180
  • Support for MacOSX/x86, following LLVM's support for exceptions in
  • 181 JIT on MacOSX/x86.
    182
  • A new vmkit driver: a program to run java or .net applications. The driver
  • 183 supports llvm command line arguments including the new "-fast" option.
    184
  • A new memory allocation scheme in the JVM that makes unloading a
  • 185 class loader very fast.
    186
  • VMKit now follows the LLVM Makefile machinery.
  • 187
    188
    189
    190
    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
    191203
    192204
    193205
    194 What's New in LLVM?
    206 External Projects Using LLVM 2.5
    207
    208
    209
    210
    211
    212 Pure
    213
    214
    215
    216

    217 Pure
    218 is an algebraic/functional programming language based on term rewriting.
    219 Programs are collections of equations which are used to evaluate expressions in
    220 a symbolic fashion. Pure offers dynamic typing, eager and lazy evaluation,
    221 lexical closures, a hygienic macro system (also based on term rewriting),
    222 built-in list and matrix support (including list and matrix comprehensions) and
    223 an easy-to-use C interface. The interpreter uses LLVM as a backend to
    224 JIT-compile Pure programs to fast native code.

    225
    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.
    232

    233
    234
    235
    236
    237
    238 LLVM D Compiler
    239
    240
    241
    242

    243 LDC is an implementation of
    244 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
    246 this
    247 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
    250 fully featured as the original DMD compiler from DigitalMars.
    251

    252
    253
    254
    255
    256 Roadsend PHP
    257
    258
    259
    260

    Roadsend PHP (rphp) is an open

    261 source implementation of the PHP programming
    262 language that uses LLVM for its optimizer, JIT, and static compiler. This is a
    263 reimplementation of an earlier project that is now based on LLVM.

    264
    265
    266
    267
    268
    269 What's New in LLVM 2.5?
    195270
    196271
    197272
    210285
    211286
    212287
    213

    LLVM 2.4 includes several major new capabilities:

    214
    215
    216
  • The most visible end-user change in LLVM 2.4 is that it includes many

  • 217 optimizations and changes to make -O0 compile times much faster. You should see
    218 improvements in speed on the order of 30% (or more) than in LLVM 2.3. There are
    219 many pieces to this change described in more detail below. The speedups and new
    220 components can also be used for JIT compilers that want fast
    221 compilation.

    222
    223
  • The biggest change to the LLVM IR is that Multiple Return Values (which

  • 224 were introduced in LLVM 2.3) have been generalized to full support for "First
    225 Class Aggregate" values in LLVM 2.4. This means that LLVM IR supports using
    226 structs and arrays as values in a function. This capability is mostly useful
    227 for front-end authors, who prefer to treat things like complex numbers, simple
    228 tuples, dope vectors, etc., as Value*'s instead of as a tuple of Value*'s or as
    229 memory values. Bitcode files from LLVM 2.3 will automatically migrate to the
    230 general representation.

    231
    232
  • LLVM 2.4 also includes an initial port for the PIC16 microprocessor. This

  • 233 target only has support for 8 bit registers, and a number of other crazy
    234 constraints. While the port is still in early development stages, it shows some
    235 interesting things you can do with LLVM.

    236
    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.
  • 237310
    238311
    239312
    251324 includes support for the C, C++, Objective-C, Ada, and Fortran front-ends.

    252325
    253326
    254
  • LLVM 2.4 supports the full set of atomic __sync_* builtins. LLVM
  • 255 2.3 only supported those used by OpenMP, but 2.4 supports them all. Note that
    256 while llvm-gcc supports all of these builtins, not all targets do. X86 support
    257 them all in both 32-bit and 64-bit mode and PowerPC supports them all except for
    258 the 64-bit operations when in 32-bit mode.
    259
    260
  • llvm-gcc now supports an -flimited-precision option, which tells
  • 261 the compiler that it is okay to use low-precision approximations of certain libm
    262 functions (like exp, log, etc). This allows you to get high
    263 performance if you only need (say) 12-bits of precision.
    264
    265
  • llvm-gcc now supports a C language extension known as "
  • 266 href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-August/002670.html">Blocks".
    267 This feature is similar to nested functions and closures, but does not
    268 require stack trampolines (with most ABIs), and supports returning closures
    269 from functions that define them. Note that actually using Blocks
    270 requires a small runtime that is not included with llvm-gcc.
    271
    272
  • llvm-gcc now supports a new -flto option. On systems that support
  • 273 transparent Link Time Optimization (currently Darwin systems with Xcode 3.1 and
    274 later) this allows the use of LTO with other optimization levels like -Os.
    275 Previously, LTO could only be used with -O4, which implied optimizations in
    276 -O3 that can increase code size.
    277
    278
    279
    280
    281
    282
    283
    284 <a name="coreimprovements">LLVM Core Improvements
    327 <li>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
    343
    344
    345
    346 LLVM IR and Core Improvements
    347
    348
    349
    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
    396
    397
    398
    399
    400
    401
    402 Optimizer Improvements
    403
    404
    405
    406
    407

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

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

    409
    410
    411
    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
    428
    429
    430
    431
    432
    433
    434 Target Independent Code Generator Improvements
    435
    436
    437
    438
    439

    We have put a significant amount of work into the code generator

    440 infrastructure, which allows us to implement more aggressive algorithms and make
    441 it run faster:

    442
    443
    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.
    455
    456
    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
    285556
    286557
    287558
    288559

    New features include:

    289560
    290561
    291
  • A major change to the Use class landed, which shrank it by 25%. Since
  • 292 this is a pervasive part of the LLVM, it ended up reducing the memory use of
    293 LLVM IR in general by 15% for most programs.
    294
    295
  • Values with no names are now pretty printed by llvm-dis more
  • 296 nicely. They now print as "%3 = add i32 %A, 4" instead of
    297 "add i32 %A, 4 ; <i32>:3", which makes it much easier to read.
    298
    299
    300
  • LLVM 2.4 includes some changes for better vector support. First, the shift
  • 301 operations (shl, ashr, and lshr) now all support
    302 vectors and do an element-by-element shift (shifts of the whole vector can be
    303 accomplished by bitcasting the vector to <1 x i128>, for example). Second,
    304 there is initial support in development for vector comparisons with the
    305 fcmp/icmp
    306 instructions. These instructions compare two vectors and return a vector of
    307 i1's for each result. Note that there is very little codegen support
    308 available for any of these IR features though.
    309
    310
  • A new DebugInfoBuilder class is available, which makes it much
  • 311 easier for front-ends to create debug info descriptors, similar to the way that
    312 IRBuilder makes it easier to create LLVM IR.
    313
    314
  • The IRBuilder class is now parameterized by a class responsible
  • 315 for constant folding. The default ConstantFolder class does target independent
    316 constant folding. The NoFolder class does no constant folding at all, which is
    317 useful when learning how LLVM works. The TargetFolder class folds the most,
    318 doing target dependent constant folding.
    319
    320
  • LLVM now supports "function attributes", which allow us to separate return
  • 321 value attributes from function attributes. LLVM now supports attributes on a
    322 function itself, a return value, and its parameters. New supported function
    323 attributes include noinline/alwaysinline and the opt-size flag,
    324 which says the function should be optimized for code size.
    325
    326
  • LLVM IR now directly represents "common" linkage, instead of
  • 327 representing it as a form of weak linkage.
    328
    329
    330
    331
    332
    333
    334
    335 Optimizer Improvements
    336
    337
    338
    339
    340

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

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

    342
    343
    344
    345
  • The Global Value Numbering (GVN) pass now does local Partial Redundancy
  • 346 Elimination (PRE) to eliminate some partially redundant expressions in cases
    347 where doing so won't grow code size.
    348
    349
  • LLVM 2.4 includes a new loop deletion pass (which removes output-free
  • 350 provably-finite loops) and a rewritten Aggressive Dead Code Elimination (ADCE)
    351 pass that no longer uses control dependence information. These changes speed up
    352 the optimizer and also prevent it from deleting output-free infinite
    353 loops.
    354
    355
  • The new AddReadAttrs pass works out which functions are read-only or
  • 356 read-none (these correspond to 'pure' and 'const' in GCC) and marks them
    357 with the appropriate attribute.
    358
    359
  • LLVM 2.4 now includes a new SparsePropagation framework, which makes it
  • 360 trivial to build lattice-based dataflow solvers that operate over LLVM IR. Using
    361 this interface means that you just define objects to represent your lattice
    362 values and the transfer functions that operate on them. It handles the
    363 mechanics of worklist processing, liveness tracking, handling PHI nodes,
    364 etc.
    365
    366
  • The Loop Strength Reduction and induction variable optimization passes have
  • 367 several improvements to avoid inserting MAX expressions, to optimize simple
    368 floating point induction variables and to analyze trip counts of more
    369 loops.
    370
    371
  • Various helper functions (ComputeMaskedBits, ComputeNumSignBits, etc) were
  • 372 pulled out of the Instruction Combining pass and put into a new
    373 ValueTracking.h header, where they can be reused by other passes.
    374
    375
  • The tail duplication pass has been removed from the standard optimizer
  • 376 sequence used by llvm-gcc. This pass still exists, but the benefits it once
    377 provided are now achieved by other passes.
    378
    379
    380
    381
    382
    383
    384
    385 Code Generator Improvements
    386
    387
    388
    389
    390

    We have put a significant amount of work into the code generator infrastructure,

    391 which allows us to implement more aggressive algorithms and make it run
    392 faster:

    393
    394
    395
  • The target-independent code generator supports (and the X86 backend
  • 396 currently implements) a new interface for "fast" instruction selection. This
    397 interface is optimized to produce code as quickly as possible, sacrificing
    398 code quality to do it. This is used by default at -O0 or when using
    399 "llc -fast" on X86. It is straight-forward to add support for
    400 other targets if faster -O0 compilation is desired.
    401
    402
  • In addition to the new 'fast' instruction selection path, many existing
  • 403 pieces of the code generator have been optimized in significant ways.
    404 SelectionDAG's are now pool allocated and use better algorithms in many
    405 places, the ".s" file printers now use raw_ostream to emit text much faster,
    406 etc. The end result of these improvements is that the compiler also takes
    407 substantially less time to generate code that is just as good (and often
    408 better) than before.
    409
    410
  • Each target has been split to separate the ".s" file printing logic from the
  • 411 rest of the target. This enables JIT compilers that don't link in the
    412 (somewhat large) code and data tables used for printing a ".s" file.
    413
    414
  • The code generator now includes a "stack slot coloring" pass, which packs
  • 415 together individual spilled values into common stack slots. This reduces
    416 the size of stack frames with many spills, which tends to increase L1 cache
    417 effectiveness.
    418
    419
  • Various pieces of the register allocator (e.g. the coalescer and two-address
  • 420 operation elimination pass) now know how to rematerialize trivial operations
    421 to avoid copies and include several other optimizations.
    422
    423
  • The graphs produced by
  • 424 the llc -view-*-dags options are now significantly prettier and
    425 easier to read.
    426
    427
  • LLVM 2.4 includes a new register allocator based on Partitioned Boolean
  • 428 Quadratic Programming (PBQP). This register allocator is still in
    429 development, but is very simple and clean.
    430
    431
    432
    433
    434
    435
    436
    437
    438 Target Specific Improvements
    439
    440
    441
    442

    New target-specific features include:

    443

    444
    445
    446
  • Exception handling is supported by default on Linux/x86-64.
  • 447
  • Position Independent Code (PIC) is now supported on Linux/x86-64.
  • 448
  • @llvm.frameaddress now supports getting the frame address of stack frames
  • 449 > 0 on x86/x86-64.
    450
  • MIPS has improved a lot since last release, the most important changes
  • 451 are: Little endian support, floating point support, allegrex core and
    452 intrinsics support. O32 ABI is improved but isn't complete. The EABI
    453 was implemented and is fully supported. We also have support for small
    454 sections and gp_rel relocation for its access, a threshold in bytes can be
    455 specified through command line.
    456
  • The PowerPC backend now supports trampolines.
  • 457
    458
    459
    460
    461
    462
    463
    464 Other Improvements
    465
    466
    467
    468

    New features include:

    469

    470
    471
    472
  • llvmc2 (the generic compiler driver) gained plugin
  • 473 support. It is now easier to experiment with llvmc2 and
    474 build your own tools based on it.
    475
    476
  • LLVM 2.4 includes a number of new generic algorithms and data structures,
  • 477 including a scoped hash table, 'immutable' data structures, a simple
    478 free-list manager, and a raw_ostream class.
    479 The raw_ostream class and
    480 format allow for efficient file output, and various pieces of LLVM
    481 have switched over to use it. The eventual goal is to eliminate
    482 use of std::ostream in favor of it.
    483
    484
  • LLVM 2.4 includes an optional build system based on CMake. It
  • 485 still is in its early stages but can be useful for Visual C++
    486 users who can not use the Visual Studio IDE.
    487
    488
    489
    490 </div>
    562 <li>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
    594
    595
    596
    597
    491598
    492599
    493600
    497604
    498605
    499606

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

    500 on LLVM 2.3, this section lists some "gotchas" that you may run into upgrading
    607 on LLVM 2.4, this section lists some "gotchas" that you may run into upgrading
    501608 from the previous release.

    502609
    503610
    504611
    505
  • The LLVM IR generated by llvm-gcc no longer names all instructions. This
  • 506 makes it run faster, but may be more confusing to some people. If you
    507 prefer to have names, the 'opt -instnamer' pass will add names to
    508 all instructions.
    509
    510
  • The LoadVN and GCSE passes have been removed from the tree. They are
  • 511 obsolete and have been replaced with the GVN and MemoryDependence passes.
    512
    612
  • llvm-gcc defaults to -fno-math-errno on all X86 targets.
  • 613
    513614
    514615
    515616
    517618 API changes are:

    518619
    519620
    520
    521
  • Now, function attributes and return value attributes are managed
  • 522 separately. Interface exported by ParameterAttributes.h header is now
    523 exported by Attributes.h header. The new attributes interface changes are:
    524
    525
  • getParamAttrs method is now replaced by
  • 526 getParamAttributes, getRetAttributes and
    527 getFnAttributes methods.
    528
  • Return value attributes are stored at index 0. Function attributes are
  • 529 stored at index ~0U. Parameter attributes are stored at index that matches
    530 parameter number.
    531
  • ParamAttr namespace is now renamed as Attribute.
  • 532
  • The name of the class that manages reference count of opaque
  • 533 attributes is changed from PAListPtr to AttrListPtr.
    534
  • ParamAttrsWithIndex is now renamed as AttributeWithIndex.
  • 535
    536
    537
    538
    539
  • The DbgStopPointInst methods getDirectory and
  • 540 getFileName now return Value* instead of strings. These can be
    541 converted to strings using llvm::GetConstantStringInfo defined via
    542 "llvm/Analysis/ValueTracking.h".
    543
    544
  • The APIs to create various instructions have changed from lower case
  • 545 "create" methods to upper case "Create" methods (e.g.
    546 BinaryOperator::create). LLVM 2.4 includes both cases, but the
    547 lower case ones are removed in mainline (2.5 and later), please migrate.
    548
    549
  • Various header files like "llvm/ADT/iterator" were given a ".h" suffix.
  • 550 Change your code to #include "llvm/ADT/iterator.h" instead.
    551
    552
  • The getresult instruction has been removed and replaced with the
  • 553 extractvalue instruction. This is part of support for first class
    554 aggregates.
    555
    556
  • In the code generator, many MachineOperand predicates were renamed to be
  • 557 shorter (e.g. isFrameIndex() -> isFI()),
    558 SDOperand was renamed to SDValue (and the "Val"
    559 member was changed to be the getNode() accessor), and the
    560 MVT::ValueType enum has been replaced with an "MVT"
    561 struct. The getSignExtended and getValue methods in the
    562 ConstantSDNode class were renamed to getSExtValue and
    563 getZExtValue respectively, to be more consistent with
    564 the ConstantInt class.
    621
  • Some deprecated interfaces to create Instruction subclasses, that
  • 622 were spelled with lower case "create," have been removed.
    565623
    566624
    567625
    579637

    LLVM is known to work on the following platforms:

    580638
    581639
    582
  • Intel and AMD machines (IA32, X86-64, AMD64, EMT-64) running Red Hat
  • 640
  • Intel and AMD machines (IA32, X86-64, AMD64, EMT-64) running Red Hat
  • 583641 Linux, Fedora Core and FreeBSD (and probably other unix-like systems).
    584
  • PowerPC and X86-based Mac OS X systems, running 10.3 and above in 32-bit
  • 642
  • PowerPC and X86-based Mac OS X systems, running 10.3 and above in 32-bit
  • 585643 and 64-bit modes.
    586644
  • Intel and AMD machines running on Win32 using MinGW libraries (native).
  • 587645
  • Intel and AMD machines running on Win32 with the Cygwin libraries (limited
  • 606664
    607665
    608666
    609

    This section contains significant known problems with the LLVM system,

    667

    This section contains significant known problems with the LLVM system,

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

    629687
    630688
    631689
  • The MSIL, IA64, Alpha, SPU, MIPS, and PIC16 backends are experimental.
  • 632
  • The llc "-filetype=asm" (the default) is the only supported
  • 633 value for this option.
    690
  • The llc "-filetype=asm" (the default) is the only
  • 691 supported value for this option.
    634692
    635693
    636694
    650708
  • The X86 backend generates inefficient floating point code when configured
  • 651709 to generate code for systems that don't have SSE2.
    652710
  • Win64 code generation wasn't widely tested. Everything should work, but we
  • 653 expect small issues to happen. Also, llvm-gcc cannot build mingw64 runtime
    654 currently due
    711 expect small issues to happen. Also, llvm-gcc cannot build the mingw64
    712 runtime currently due
    655713 to several
    656 bugs due to lack of support for the
    657 'u' inline assembly constraint and X87 floating point inline assembly.
    714 bugs and due to lack of support for
    715 the
    716 'u' inline assembly constraint and for X87 floating point inline assembly.
    658717
  • The X86-64 backend does not yet support the LLVM IR instruction
  • 659 va_arg. Currently, the llvm-gcc front-end supports variadic
    718 va_arg. Currently, the llvm-gcc and front-ends support variadic
    660719 argument constructs on X86-64 by lowering them manually.
    661720
    662721
    687746
  • Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6
  • 688747 processors, thumb programs can crash or produce wrong
    689748 results (PR1388).
    690
  • Compilation for ARM Linux OABI (old ABI) is supported, but not fully tested.
  • 749
  • Compilation for ARM Linux OABI (old ABI) is supported but not fully tested.
  • 691750
    692751
  • There is a bug in QEMU-ARM (<= 0.9.0) which causes it to incorrectly
  • 693752 execute
    704763
    705764
    706765
    707
  • The SPARC backend only supports the 32-bit SPARC ABI (-m32), it does not
  • 766
  • The SPARC backend only supports the 32-bit SPARC ABI (-m32); it does not
  • 708767 support the 64-bit SPARC ABI (-m64).
    709768
    710769
    747806
    748807
    749808
    750
  • The Itanium backend is highly experimental, and has a number of known
  • 809
  • The Itanium backend is highly experimental and has a number of known
  • 751810 issues. We are looking for a maintainer for the Itanium backend. If you
    752811 are interested, please contact the LLVMdev mailing list.
    753812
    766825 inline assembly code.
    767826
  • The C backend violates the ABI of common
  • 768827 C++ programs, preventing intermixing between C++ compiled by the CBE and
    769 C++ code compiled with llc or native compilers.
    828 C++ code compiled with llc or native compilers.
    770829
  • The C backend does not support all exception handling constructs.
  • 830
  • The C backend does not support arbitrary precision integers.
  • 771831
    772832
    773833
    822882
    823883
  • Fortran support generally works, but there are still several unresolved bugs
  • 824884 in Bugzilla. Please see the tools/gfortran component for details.
    825
    826
  • The Fortran front-end currently does not build on Darwin (without tweaks)
  • 827 due to unresolved dependencies on the C front-end.
    828885
    829886
    830887
    834891
    835892
    836893
    837 The llvm-gcc 4.2 Ada compiler works fairly well, however this is not a mature
    838 technology and problems should be expected.
    894 The llvm-gcc 4.2 Ada compiler works fairly well; however, this is not a mature
    895 technology, and problems should be expected.
    839896
    840897
  • The Ada front-end currently only builds on X86-32. This is mainly due
  • 841 to lack of trampoline support (pointers to nested functions) on other platforms,
    842 however it also fails to build on X86-64
    898 to lack of trampoline support (pointers to nested functions) on other platforms.
    899 However, it also fails to build on X86-64
    843900 which does support trampolines.
    844901
  • The Ada front-end fails to bootstrap.
  • 902 This is due to lack of LLVM support for setjmp/longjmp style
    903 exception handling, which is used internally by the compiler.
    845904 Workaround: configure with --disable-bootstrap.
    846905
  • The c380004, c393010
  • 847906 and cxg2021 ACATS tests fail
    848 (c380004 also fails with gcc-4.2 mainline).
    849
  • Some gcc specific Ada tests continue to crash the compiler.
  • 907 (c380004 also fails with gcc-4.2 mainline).
    908 If the compiler is built with checks disabled then c393010
    909 causes the compiler to go into an infinite loop, using up all system memory.
    910
  • Some GCC specific Ada tests continue to crash the compiler.
  • 850911
  • The -E binder option (exception backtraces)
  • 851912 does not work and will result in programs
    852913 crashing if an exception is raised. Workaround: do not use -E.