llvm.org GIT mirror llvm / 922d00f
strip out the 2.7 release notes, this really is the 2.8 release notes now. Add a few items like the fpstackifier improvements. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109013 91177308-0d34-0410-b5e6-96231b3b80d8 Chris Lattner 9 years ago
1 changed file(s) with 32 addition(s) and 512 deletion(s). Raw diff Collapse all Expand all
117117 integrating with other development tools. Clang is considered a
118118 production-quality compiler for C and Objective-C on x86 (32- and 64-bit).

119119
120

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

121
122
123
124
  • C++ Support: Clang is now capable of self-hosting! While still
  • 125 alpha-quality, Clang's C++ support has matured enough to build LLVM and Clang,
    126 and C++ is now enabled by default. See the
    127 href="http://clang.llvm.org/cxx_compatibility.html">Clang C++ compatibility
    128 page for common C++ migration issues.
    129
    130
  • Objective-C: Clang now includes experimental support for an updated
  • 131 Objective-C ABI on non-Darwin platforms. This includes support for non-fragile
    132 instance variables and accelerated proxies, as well as greater potential for
    133 future optimisations. The new ABI is used when compiling with the
    134 -fobjc-nonfragile-abi and -fgnu-runtime options. Code compiled with these
    135 options may be mixed with code compiled with GCC or clang using the old GNU ABI,
    136 but requires the libobjc2 runtime from the GNUstep project.
    137
    138
  • New warnings: Clang contains a number of new warnings, including
  • 139 control-flow warnings (unreachable code, missing return statements in a
    140 non-void function, etc.), sign-comparison warnings, and improved
    141 format-string warnings.
    142
    143
  • CIndex API and Python bindings: Clang now includes a C API as part of the
  • 144 CIndex library. Although we may make some changes to the API in the future, it
    145 is intended to be stable and has been designed for use by external projects. See
    146 the Clang
    147 doxygen CIndex
    148 documentation for more details. The CIndex API also includes a preliminary
    149 set of Python bindings.
    150
    151
  • ARM Support: Clang now has ABI support for both the Darwin and Linux ARM
  • 152 ABIs. Coupled with many improvements to the LLVM ARM backend, Clang is now
    153 suitable for use as a beta quality ARM compiler.>
    120

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

    121
    122
    154123
    155124
    156125
    169138 future!). The tool is very good at finding bugs that occur on specific
    170139 paths through code, such as on error conditions.

    171140
    172

    In the LLVM 2.7 time-frame, the analyzer core has made several major and

    173 minor improvements, including better support for tracking the fields of
    174 structures, initial support (not enabled by default yet) for doing
    175 interprocedural (cross-function) analysis, and new checks have been added.
    141

    In the LLVM 2.8 time-frame,

    176142

    177143
    178144
    189155 implementation of the CLI) using LLVM for static and just-in-time
    190156 compilation.

    191157
    192

    193 With the release of LLVM 2.7, VMKit has shifted to a great framework for writing
    194 virtual machines. VMKit now offers precise and efficient garbage collection with
    195 multi-threading support, thanks to the MMTk memory management toolkit, as well
    196 as just in time and ahead of time compilation with LLVM. The major changes in
    197 VMKit 0.27 are:

    198
    199
    200
    201
  • Garbage collection: VMKit now uses the MMTk toolkit for garbage collectors.
  • 202 The first collector to be ported is the MarkSweep collector, which is precise,
    203 and drastically improves the performance of VMKit.
    204
  • Line number information in the JVM: by using the debug metadata of LLVM, the
  • 205 JVM now supports precise line number information, useful when printing a stack
    206 trace.
    207
  • Interface calls in the JVM: we implemented a variant of the Interface Method
  • 208 Table technique for interface calls in the JVM.
    209
    210
    211 </ul>
    158 <p>With the release of LLVM 2.8, ...>
    159
    212160
    213161
    214162
    230178
    231179

    232180 All of the code in the compiler-rt project is available under the standard LLVM
    233 License, a "BSD-style" license. New in LLVM 2.7: compiler_rt now
    234 supports ARM targets.

    181 License, a "BSD-style" license. New in LLVM 2.8:
    182
    183 Soft float support
    184

    235185
    236186
    237187
    264214

    265215
    266216

    267 DragonEgg is a new project which is seeing its first release with llvm-2.7.
    217 2.8 status here.
    268218

    269219
    270220
    287237 LLVM MC Project Blog Post.
    288238

    289239
    290

    2.7 includes major parts of the work required by the new MC Project. A few

    291 targets have been refactored to support it, and work is underway to support a
    292 native assembler in LLVM. This work is not complete in LLVM 2.7, but it has
    293 made substantially more progress on LLVM mainline.

    294
    295

    One minor example of what MC can do is to transcode an AT&T syntax

    296 X86 .s file into intel syntax. You can do this with something like:

    297
    
                      
                    
    298 llvm-mc foo.s -output-asm-variant=1 -o foo-intel.s
    299
    300
    240

    2.8 status here

    301241
    302242
    303243
    304244
    305245
    306 External Open Source Projects Using LLVM 2.7
    246 External Open Source Projects Using LLVM 2.8
    307247
    308248
    309249
    311251
    312252

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

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

    315
    316
    317
    318
    319 Pure
    320
    321
    322
    323

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

    332
    333

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

    334 LLVM 2.7 (and continue to work with older LLVM releases >= 2.5).

    335
    336
    337
    338
    339
    340 Roadsend PHP
    341
    342
    343
    344

    345 Roadsend PHP (rphp) is an open
    346 source implementation of the PHP programming
    347 language that uses LLVM for its optimizer, JIT and static compiler. This is a
    348 reimplementation of an earlier project that is now based on LLVM.
    349

    350
    351
    352
    353
    354 Unladen Swallow
    355
    356
    357
    358

    359 Unladen Swallow is a
    360 branch of Python intended to be fully
    361 compatible and significantly faster. It uses LLVM's optimization passes and JIT
    362 compiler.
    363

    364
    365
    366
    367
    368 TTA-based Codesign Environment (TCE)
    369
    370
    371
    372

    373 TCE is a toolset for designing
    374 application-specific processors (ASP) based on the Transport triggered
    375 architecture (TTA). The toolset provides a complete co-design flow from C/C++
    376 programs down to synthesizable VHDL and parallel program binaries. Processor
    377 customization points include the register files, function units, supported
    378 operations, and the interconnection network.

    379
    380

    TCE uses llvm-gcc/Clang and LLVM for C/C++ language support, target

    381 independent optimizations and also for parts of code generation. It generates
    382 new LLVM-based code generators "on the fly" for the designed TTA processors and
    383 loads them in to the compiler backend as runtime libraries to avoid per-target
    384 recompilation of larger parts of the compiler chain.

    385
    386
    387
    388
    389
    390 SAFECode Compiler
    391
    392
    393
    394

    395 SAFECode is a memory safe C
    396 compiler built using LLVM. It takes standard, unannotated C code, analyzes the
    397 code to ensure that memory accesses and array indexing operations are safe, and
    398 instruments the code with run-time checks when safety cannot be proven
    399 statically.
    400

    401
    402
    403
    404
    405 IcedTea Java Virtual Machine Implementation
    406
    407
    408
    409

    410 IcedTea provides a
    411 harness to build OpenJDK using only free software build tools and to provide
    412 replacements for the not-yet free parts of OpenJDK. One of the extensions that
    413 IcedTea provides is a new JIT compiler named
    414 href="http://icedtea.classpath.org/wiki/ZeroSharkFaq">Shark which uses LLVM
    415 to provide native code generation without introducing processor-dependent
    416 code.
    417

    418

    Icedtea6 1.8 and later have been tested and are known to work with

    419 LLVM 2.7 (and continue to work with older LLVM releases >= 2.6 as well).
    420

    421
    422
    423
    424
    425 LLVM-Lua
    426
    427
    428
    429

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

    435

    LLVM-Lua 1.2.0 have been tested and is known to work with LLVM 2.7.

    436

    437
    438
    439
    440
    441 MacRuby
    442
    443
    444
    445

    446 MacRuby is an implementation of Ruby based on
    447 core Mac OS technologies, sponsored by Apple Inc. It uses LLVM at runtime for
    448 optimization passes, JIT compilation and exception handling. It also allows
    449 static (ahead-of-time) compilation of Ruby code straight to machine code.
    450

    451

    The upcoming MacRuby 0.6 release works with LLVM 2.7.

    452

    453
    454
    455
    456
    457 Glasgow Haskell Compiler (GHC)
    458
    459
    460
    461

    462 GHC is an open source,
    463 state-of-the-art programming suite for Haskell, a standard lazy
    464 functional programming language. It includes an optimizing static
    465 compiler generating good code for a variety of platforms, together
    466 with an interactive system for convenient, quick development.

    467
    468

    In addition to the existing C and native code generators, GHC now

    469 supports an
    470 href="http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM">LLVM
    471 code generator. GHC supports LLVM 2.7.

    472
    254 projects that have already been updated to work with LLVM 2.8.

    473255
    474256
    475257
    476258
    477259
    478 What's New in LLVM 2.7?
    260 What's New in LLVM 2.8?
    479261
    480262
    481263
    495277
    496278
    497279
    498

    In addition to changes to the code, between LLVM 2.6 and 2.7, a number of

    280

    In addition to changes to the code, between LLVM 2.7 and 2.8, a number of

    499281 organization changes have happened:
    500282

    501283
    502284
    503
  • LLVM has a new official logo!
  • 504
    505
  • Ted Kremenek and Doug Gregor have stepped forward as
  • 506 href="http://llvm.org/docs/DeveloperPolicy.html#owners">Code Owners of the
    507 Clang static analyzer and the Clang frontend, respectively.
    508
    509
  • LLVM now has an official Blog at
  • 510 http://blog.llvm.org. This is a great way
    511 to learn about new LLVM-related features as they are implemented. Several
    512 features in this release are already explained on the blog.
    513
    514
  • The LLVM web pages are now checked into the SVN server, in the "www",
  • 515 "www-pubs" and "www-releases" SVN modules. Previously they were hidden in a
    516 largely inaccessible old CVS server.
    517
    518
  • llvm.org is now hosted on a new (and much
  • 519 faster) server. It is still graciously hosted at the University of Illinois
    520 of Urbana Champaign.
    521285
    522286
    523287
    528292
    529293
    530294
    531

    LLVM 2.7 includes several major new capabilities:

    532
    533
    534
  • 2.7 includes initial support for the
  • 535 href="http://en.wikipedia.org/wiki/MicroBlaze">MicroBlaze target.
    536 MicroBlaze is a soft processor core designed for Xilinx FPGAs.
    537
    538
  • 2.7 includes a new LLVM IR "extensible metadata" feature. This feature
  • 539 supports many different use cases, including allowing front-end authors to
    540 encode source level information into LLVM IR, which is consumed by later
    541 language-specific passes. This is a great way to do high-level optimizations
    542 like devirtualization, type-based alias analysis, etc. See the
    543 href="http://blog.llvm.org/2010/04/extensible-metadata-in-llvm-ir.html">
    544 Extensible Metadata Blog Post for more information.
    545
    546
  • 2.7 encodes debug information
  • 547 in a completely new way, built on extensible metadata. The new implementation
    548 is much more memory efficient and paves the way for improvements to optimized
    549 code debugging experience.
    550
    551
  • 2.7 now directly supports taking the address of a label and doing an
  • 552 indirect branch through a pointer. This is particularly useful for
    553 interpreter loops, and is used to implement the GCC "address of label"
    554 extension. For more information, see the
    555 href="http://blog.llvm.org/2010/01/address-of-label-and-indirect-branches.html">
    556 Address of Label and Indirect Branches in LLVM IR Blog Post.
    557
    558
  • 2.7 is the first release to start supporting APIs for assembling and
  • 559 disassembling target machine code. These APIs are useful for a variety of
    560 low level clients, and are surfaced in the new "enhanced disassembly" API.
    561 For more information see the
    562 href="http://blog.llvm.org/2010/01/x86-disassembler.html">The X86
    563 Disassembler Blog Post for more information.
    564
    565
  • 2.7 includes major parts of the work required by the new MC Project,
  • 566 see the MC update above for more information.
    567
    295

    LLVM 2.8 includes several major new capabilities:

    296
    297
    298
  • .
  • 568299
    569300
    570301
    579310 expose new optimization opportunities:

    580311
    581312
    582
  • LLVM IR now supports a 16-bit "half float" data type through
  • 583 href="LangRef.html#int_fp16">two new intrinsics and APFloat support.
    584
  • LLVM IR supports two new function
  • 585 attributes: inlinehint and alignstack(n). The former is a hint to the
    586 optimizer that a function was declared 'inline' and thus the inliner should
    587 weight it higher when considering inlining it. The later
    588 indicates to the code generator that the function diverges from the platform
    589 ABI on stack alignment.
    590
  • The new llvm.objectsize intrinsic
  • 591 allows the optimizer to infer the sizes of memory objects in some cases.
    592 This intrinsic is used to implement the GCC __builtin_object_size
    593 extension.
    594
  • LLVM IR now supports marking load and store instructions with
  • 595 href="LangRef.html#i_load">"non-temporal" hints (building on the new
    596 metadata feature). This hint encourages the code
    597 generator to generate non-temporal accesses when possible, which are useful
    598 for code that is carefully managing cache behavior. Currently, only the
    599 X86 backend provides target support for this feature.
    600
    601
  • LLVM 2.7 has pre-alpha support for
  • 602 href="LangRef.html#t_union">unions in LLVM IR.
    603 Unfortunately, this support is not really usable in 2.7, so if you're
    604 interested in pushing it forward, please help contribute to LLVM mainline.
    605
    606
    607313
    608314
  • LLVM 2.8 changes the internal order of operands in
  • 609315 href="http://llvm.org/doxygen/classllvm_1_1InvokeInst.html">InvokeInst
    628334
    629335
    630336
    631
  • The inliner now merges arrays stack objects in different callees when
  • 632 inlining multiple call sites into one function. This reduces the stack size
    633 of the resultant function.
    634
  • The -basicaa alias analysis pass (which is the default) has been improved to
  • 635 be less dependent on "type safe" pointers. It can now look through bitcasts
    636 and other constructs more aggressively, allowing better load/store
    637 optimization.
    638
  • The load elimination optimization in the GVN Pass [
  • 639 href="http://blog.llvm.org/2009/12/introduction-to-load-elimination-in-gvn.html">intro
    640 blog post] has been substantially improved to be more aggressive about
    641 partial redundancy elimination and do more aggressive phi translation. Please
    642 see the
    643 href="http://blog.llvm.org/2009/12/advanced-topics-in-redundant-load.html">
    644 Advanced Topics in Redundant Load Elimination with a Focus on PHI Translation
    645 Blog Post for more details.
    646
  • The module target data string now
  • 647 includes a notion of 'native' integer data types for the target. This
    648 helps mid-level optimizations avoid promoting complex sequences of
    649 operations to data types that are not natively supported (e.g. converting
    650 i32 operations to i64 on 32-bit chips).
    651
  • The mid-level optimizer is now conservative when operating on a module with
  • 652 no target data. Previously, it would default to SparcV9 settings, which is
    653 not what most people expected.
    654
  • Jump threading is now much more aggressive at simplifying correlated
  • 655 conditionals and threading blocks with otherwise complex logic. It has
    656 subsumed the old "Conditional Propagation" pass, and -condprop has been
    657 removed from LLVM 2.7.
    658
  • The -instcombine pass has been refactored from being one huge file to being
  • 659 a library of its own. Internally, it uses a customized IRBuilder to clean
    660 it up and simplify it.
    661
    662
  • The optimal edge profiling pass is reliable and much more complete than in
  • 663 2.6. It can be used with the llvm-prof tool but isn't wired up to the
    664 llvm-gcc and clang command line options yet.
    665
    666
  • A new experimental alias analysis implementation, -scev-aa, has been added.
  • 667 It uses LLVM's Scalar Evolution implementation to do symbolic analysis of
    668 pointer offset expressions to disambiguate pointers. It can catch a few
    669 cases that basicaa cannot, particularly in complex loop nests.
    670
    671
  • The default pass ordering has been tweaked for improved optimization
  • 672 effectiveness.
    337
  • 673338
    674339
    675340
    684349
    685350
    686351
    687
  • The JIT now supports generating debug information and is compatible with
  • 688 the new GDB 7.0 (and later) interfaces for registering dynamically generated
    689 debug info.
    690
    691
  • The JIT now defaults
  • 692 to compiling eagerly to avoid a race condition in the lazy JIT.
    693 Clients that still want the lazy JIT can switch it on by calling
    694 ExecutionEngine::DisableLazyCompilation(false).
    695
    696
  • It is now possible to create more than one JIT instance in the same process.
  • 697 These JITs can generate machine code in parallel,
    698 although you
    699 still have to obey the other threading restrictions.
    352
  • 700353
    701354
    702355
    714367 it run faster:

    715368
    716369
    717
  • The 'llc -asm-verbose' option (which is now the default) has been enhanced
  • 718 to emit many useful comments to .s files indicating information about spill
    719 slots and loop nest structure. This should make it much easier to read and
    720 understand assembly files. This is wired up in llvm-gcc and clang to
    721 the -fverbose-asm option.
    722
    723
  • New LSR with "full strength reduction" mode, which can reduce address
  • 724 register pressure in loops where address generation is important.
    725
    726
  • A new codegen level Common Subexpression Elimination pass (MachineCSE)
  • 727 is available and enabled by default. It catches redundancies exposed by
    728 lowering.
    729
  • A new pre-register-allocation tail duplication pass is available and enabled
  • 730 by default, it can substantially improve branch prediction quality in some
    731 cases.
    732
  • A new sign and zero extension optimization pass (OptimizeExtsPass)
  • 733 is available and enabled by default. This pass can takes advantage
    734 architecture features like x86-64 implicit zero extension behavior and
    735 sub-registers.
    736
  • The code generator now supports a mode where it attempts to preserve the
  • 737 order of instructions in the input code. This is important for source that
    738 is hand scheduled and extremely sensitive to scheduling. It is compatible
    739 with the GCC -fno-schedule-insns option.
    740
  • The target-independent code generator now supports generating code with
  • 741 arbitrary numbers of result values. Returning more values than was
    742 previously supported is handled by returning through a hidden pointer. In
    743 2.7, only the X86 and XCore targets have adopted support for this
    744 though.
    745
  • The code generator now supports generating code that follows the
  • 746 Glasgow Haskell Compiler Calling
    747 Convention and ABI.
    748
  • The "DAG instruction
  • 749 selection" phase of the code generator has been largely rewritten for
    750 2.7. Previously, tblgen spit out tons of C++ code which was compiled and
    751 linked into the target to do the pattern matching, now it emits a much
    752 smaller table which is read by the target-independent code. The primary
    753 advantages of this approach is that the size and compile time of various
    754 targets is much improved. The X86 code generator shrunk by 1.5MB of code,
    755 for example.
    756
  • Almost the entire code generator has switched to emitting code through the
  • 757 MC interfaces instead of printing textually to the .s file. This led to a
    758 number of cleanups and speedups. In 2.7, debug an exception handling
    759 information does not go through MC yet.
    370
  • MachO writer works.
  • 760371
    761372
    762373
    770381

    771382
    772383
    773
  • The X86 backend now optimizes tails calls much more aggressively for
  • 774 functions that use the standard C calling convention.
    775
  • The X86 backend now models scalar SSE registers as subregs of the SSE vector
  • 776 registers, making the code generator more aggressive in cases where scalars
    777 and vector types are mixed.
    384
  • The X86 backend now supports holding X87 floating point stack values
  • 385 in registers across basic blocks, dramatically improving performance of code
    386 that uses long double, and when targetting CPUs that don't support SSE.
    778387
    779388
    780389
    791400
    792401
    793402
    794
  • The ARM backend now generates instructions in unified assembly syntax.
  • 795
    796
  • llvm-gcc now has complete support for the ARM v7 NEON instruction set. This
  • 797 support differs slightly from the GCC implementation. Please see the
    798
    799 href="http://blog.llvm.org/2010/04/arm-advanced-simd-neon-intrinsics-and.html">
    800 ARM Advanced SIMD (NEON) Intrinsics and Types in LLVM Blog Post for
    801 helpful information if migrating code from GCC to LLVM-GCC.
    802
    803
  • The ARM and Thumb code generators now use register scavenging for stack
  • 804 object address materialization. This allows the use of R3 as a general
    805 purpose register in Thumb1 code, as it was previous reserved for use in
    806 stack address materialization. Secondly, sequential uses of the same
    807 value will now re-use the materialized constant.
    808
    809
  • The ARM backend now has good support for ARMv4 targets and has been tested
  • 810 on StrongARM hardware. Previously, LLVM only supported ARMv4T and
    811 newer chips.
    812
    813
  • Atomic builtins are now supported for ARMv6 and ARMv7 (__sync_synchronize,
  • 814 __sync_fetch_and_add, etc.).
    403
  • 815404
    816405
    817406
    830419

    831420
    832421
    833
  • The optimizer uses the new CodeMetrics class to measure the size of code.
  • 834 Various passes (like the inliner, loop unswitcher, etc) all use this to make
    835 more accurate estimates of the code size impact of various
    836 optimizations.
    837
  • A new
  • 838 llvm/Analysis/InstructionSimplify.h interface is available for doing
    839 symbolic simplification of instructions (e.g. a+0 -> a)
    840 without requiring the instruction to exist. This centralizes a lot of
    841 ad-hoc symbolic manipulation code scattered in various passes.
    842
  • The optimizer now uses a new
  • 843 href="http://llvm.org/doxygen/SSAUpdater_8h-source.html">SSAUpdater
    844 class which efficiently supports
    845 doing unstructured SSA update operations. This centralized a bunch of code
    846 scattered throughout various passes (e.g. jump threading, lcssa,
    847 loop rotate, etc) for doing this sort of thing. The code generator has a
    848 similar
    849 MachineSSAUpdater class.
    850
  • The
  • 851 llvm/Support/Regex.h header exposes a platform independent regular
    852 expression API. Building on this, the
    853 href="TestingGuide.html#FileCheck">FileCheck utility now supports
    854 regular exressions.
    855
  • raw_ostream now supports a circular "debug stream" accessed with "dbgs()".
  • 856 By default, this stream works the same way as "errs()", but if you pass
    857 -debug-buffer-size=1000 to opt, the debug stream is capped to a
    858 fixed sized circular buffer and the output is printed at the end of the
    859 program's execution. This is helpful if you have a long lived compiler
    860 process and you're interested in seeing snapshots in time.
    422
  • 861423
    862424
    863425
    872434

    Other miscellaneous features include:

    873435
    874436
    875
  • You can now build LLVM as a big dynamic library (e.g. "libllvm2.7.so"). To
  • 876 get this, configure LLVM with the --enable-shared option.
    877
    878
  • LLVM command line tools now overwrite their output by default. Previously,
  • 879 they would only do this with -f. This makes them more convenient to use, and
    880 behave more like standard unix tools.
    881
    882
  • The opt and llc tools now autodetect whether their input is a .ll or .bc
  • 883 file, and automatically do the right thing. This means you don't need to
    884 explicitly use the llvm-as tool for most things.
    437
  • 885438
    886439
    887440
    895448
    896449
    897450

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

    898 on LLVM 2.6, this section lists some "gotchas" that you may run into upgrading
    451 on LLVM 2.7, this section lists some "gotchas" that you may run into upgrading
    899452 from the previous release.

    900453
    901454
    902455
    903
  • 904 The Andersen's alias analysis ("anders-aa") pass, the Predicate Simplifier
    905 ("predsimplify") pass, the LoopVR pass, the GVNPRE pass, and the random sampling
    906 profiling ("rsprofiling") passes have all been removed. They were not being
    907 actively maintained and had substantial problems. If you are interested in
    908 these components, you are welcome to ressurect them from SVN, fix the
    909 correctness problems, and resubmit them to mainline.
    910
    911
  • LLVM now defaults to building most libraries with RTTI turned off, providing
  • 912 a code size reduction. Packagers who are interested in building LLVM to support
    913 plugins that require RTTI information should build with "make REQUIRE_RTTI=1"
    914 and should read the new Advice on Packaging LLVM
    915 document.
    916
    917
  • The LLVM interpreter now defaults to not using libffi even
  • 918 if you have it installed. This makes it more likely that an LLVM built on one
    919 system will work when copied to a similar system. To use libffi,
    920 configure with --enable-libffi.
    921
    922
  • Debug information uses a completely different representation, an LLVM 2.6
  • 923 .bc file should work with LLVM 2.7, but debug info won't come forward.
    924
    925
  • The LLVM 2.6 (and earlier) "malloc" and "free" instructions got removed,
  • 926 along with LowerAllocations pass. Now you should just use a call to the
    927 malloc and free functions in libc. These calls are optimized as well as
    928 the old instructions were.
    456
  • .
  • 929457
    930458
    931459

    In addition, many APIs have changed in this release. Some of the major LLVM

    932460 API changes are:

    933461
    934462
    935
    936
  • The add, sub, and mul instructions no longer
  • 937 support floating-point operands. The fadd, fsub, and
    938 fmul instructions should be used for this purpose instead.
    939
    940463
    941464
    942465
    1015538
  • The MSIL, Alpha, SPU, MIPS, PIC16, Blackfin, MSP430, SystemZ and MicroBlaze
  • 1016539 backends are experimental.
    1017540
  • llc "-filetype=asm" (the default) is the only
  • 1018 supported value for this option. The MachO writer is experimental, and
    1019 works much better in mainline SVN.
    541 supported value for this option. XXX Update me
    1020542
    1021543
    1022544
    1033555 all inline assembly that uses the X86
    1034556 floating point stack. It supports the 'f' and 't' constraints, but not
    1035557 'u'.
    1036
  • The X86 backend generates inefficient floating point code when configured
  • 1037 to generate code for systems that don't have SSE2.
    1038558
  • Win64 code generation wasn't widely tested. Everything should work, but we
  • 1039559 expect small issues to happen. Also, llvm-gcc cannot build the mingw64
    1040560 runtime currently due to lack of support for the 'u' inline assembly