llvm.org GIT mirror llvm / 1f34058
Update. git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_31@156862 91177308-0d34-0410-b5e6-96231b3b80d8 Bill Wendling 8 years ago
1 changed file(s) with 281 addition(s) and 111 deletion(s). Raw diff Collapse all Expand all
2828

Written by the LLVM Team

2929
3030
31

These are in-progress notes for the upcoming LLVM 3.1

32 release.
33 You may prefer the
34 LLVM 3.0
35 Release Notes.
36
3731
3832

3933 Introduction
7367
7468

The LLVM 3.1 distribution currently consists of code from the core LLVM

7569 repository (which roughly includes the LLVM optimizers, code generators and
76 supporting tools), and the Clang repository. In
77 addition to this code, the LLVM Project includes other sub-projects that are
78 in development. Here we include updates on these subprojects.

70 supporting tools), and the Clang repository. In addition to this code, the
71 LLVM Project includes other sub-projects that are in development. Here we
72 include updates on these subprojects.

7973
8074
8175

9387 production-quality compiler for C, Objective-C, C++ and Objective-C++ on x86
9488 (32- and 64-bit), and for Darwin/ARM targets.

9589
96

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

90

In the LLVM 3.1 time-frame, the Clang team has made many improvements.

91 Highlights include:

9792
9893
  • Greatly expanded C++11
  • 9994 support including lambdas, initializer lists, constexpr, user-defined
    105100 Objective C.
    106101
    107102
    108

    For more details about the changes to Clang since the 3.0 release, see the

    109 Clang release notes
    110

    111
    103

    For more details about the changes to Clang since the 3.0 release, see the

    104 Clang release
    105 notes.

    112106
    113107

    If Clang rejects your code but another compiler accepts it, please take a

    114108 look at the language
    123117
    124118
    125119
    120
    126121

    DragonEgg is a

    127122 gcc plugin that replaces GCC's
    128123 optimizers and code generators with LLVM's. It works with gcc-4.5 and gcc-4.6
    133128
    134129

    The 3.1 release has the following notable changes:

    135130
    136
    137
    131
    138132
  • Partial support for gcc-4.7. Ada support is poor, but other languages work
  • 139133 fairly well.
    140134
    149143 aliasing and type ranges to the LLVM optimizers.
    150144
    151145
  • A regression test-suite was added.
  • 152
    153146
    154147
    155148
    170163 implementations of this and other low-level routines (some are 3x faster than
    171164 the equivalent libgcc routines).

    172165
    173

    ....

    166

    As of 3.1, compiler-rt includes the helper functions for atomic operations,

    167 allowing atomic operations on arbitrary-sized quantities to work. These
    168 functions follow the specification defined by gcc and are used by clang.

    174169
    175170
    176171
    181176
    182177
    183178
    184

    LLDB is a ground-up implementation of a command line debugger, as well as a

    185 debugger API that can be used from other applications. LLDB makes use of the
    186 Clang parser to provide high-fidelity expression parsing (particularly for
    187 C++) and uses the LLVM JIT for target support.

    188
    189

    ...

    179

    LLDB is a ground-up implementation of a

    180 command line debugger, as well as a debugger API that can be used from other
    181 applications. LLDB makes use of the Clang parser to provide high-fidelity
    182 expression parsing (particularly for C++) and uses the LLVM JIT for target
    183 support.

    190184
    191185
    192186
    201195 licensed under the MIT and UIUC license, allowing it to be used more
    202196 permissively.

    203197
    204

    ...

    198

    Within the LLVM 3.1 time-frame there were the following highlights:

    199
    200
    201
  • The <atomic> header is now passing all tests, when
  • 202 compiling with clang and linking against the support code from
    203 compiler-rt.
    204
  • FreeBSD now includes libc++ as part of the base system.
  • 205
  • libc++ has been ported to Solaris and, in combination with libcxxrt and
  • 206 clang, is working with a large body of existing code.
    207
    205208
    206209
    207210
    212215
    213216
    214217
    215

    The VMKit project is an

    216 implementation of a Java Virtual Machine (Java VM or JVM) that uses LLVM for
    217 static and just-in-time compilation.
    218
    219

    In the LLVM 3.1 time-frame, VMKit has had significant improvements on both

    220 runtime and startup performance:

    221
    222
    223
  • ...
  • 224
    218

    The VMKit project is an implementation

    219 of a Java Virtual Machine (Java VM or JVM) that uses LLVM for static and
    220 just-in-time compilation.

    221
    222

    In the LLVM 3.1 time-frame, VMKit has had significant improvements on both

    223 runtime and startup performance.

    225224
    226225
    227226
    233232
    234233
    235234
    236

    Polly is an experimental

    235

    Polly is an experimental

    237236 optimizer for data locality and parallelism. It currently provides high-level
    238237 loop optimizations and automatic parallelisation (using the OpenMP run time).
    239238 Work in the area of automatic SIMD and accelerator code generation was
    240 started.
    241
    242

    Within the LLVM 3.1 time-frame there were the following highlights:

    243
    244 >
    239 started.>
    240
    241

    Within the LLVM 3.1 time-frame there were the following highlights:

    242
    243
    245244
  • Polly became an official LLVM project
  • 246
  • Polly can be loaded directly into clang (Enabled by '-O3 -mllvm -polly'
  • 247 )
    248
  • An automatic scheduling optimizer (derived from
  • 249 href="http://pluto-compiler.sourceforge.net/">Pluto) was integrated. It
    250 performs loop transformations to optimize for data-locality and parallelism.
    251 The transformations include, but are not limited to interchange, fusion,
    252 fission, skewing and tiling.
    253
    254 </ul>
    245 <li>Polly can be loaded directly into clang (enabled by '-O3 -mllvm -polly')>
    246
  • An automatic scheduling optimizer (derived
  • 247 from Pluto) was
    248 integrated. It performs loop transformations to optimize for data-locality
    249 and parallelism. The transformations include, but are not limited to
    250 interchange, fusion, fission, skewing and tiling.
    251
    255252
    256253
    257254
    269266 a lot of other language and tools projects. This section lists some of the
    270267 projects that have already been updated to work with LLVM 3.1.

    271268
    269

    Crack

    270
    271
    272
    273

    Crack aims to provide

    274 the ease of development of a scripting language with the performance of a
    275 compiled language. The language derives concepts from C++, Java and Python,
    276 incorporating object-oriented programming, operator overloading and strong
    277 typing.

    278
    279
    280
    281

    FAUST

    282
    283
    284
    285

    FAUST is a compiled language for

    286 real-time audio signal processing. The name FAUST stands for Functional
    287 AUdio STream. Its programming model combines two approaches: functional
    288 programming and block diagram composition. In addition with the C, C++, Java,
    289 JavaScript output formats, the Faust compiler can generate LLVM bitcode, and
    290 works with LLVM 2.7-3.1.

    291
    292
    293
    294

    Glasgow Haskell Compiler (GHC)

    295
    296
    297
    298

    GHC is an open source compiler and

    299 programming suite for Haskell, a lazy functional programming language. It
    300 includes an optimizing static compiler generating good code for a variety of
    301 platforms, together with an interactive system for convenient, quick
    302 development.

    303
    304

    GHC 7.0 and onwards include an LLVM code generator, supporting LLVM 2.8 and

    305 later.

    306
    307
    308
    309

    Julia

    310
    311
    312
    313

    Julia is a high-level,

    314 high-performance dynamic language for technical computing. It provides a
    315 sophisticated compiler, distributed parallel execution, numerical accuracy,
    316 and an extensive mathematical function library. The compiler uses type
    317 inference to generate fast code without any type declarations, and uses
    318 LLVM's optimization passes and JIT compiler. The
    319 Julia Language is designed
    320 around multiple dispatch, giving programs a large degree of flexibility. It
    321 is ready for use on many kinds of problems.

    322
    323
    324
    325

    LLVM D Compiler

    326
    327
    328
    329

    LLVM D Compiler (LDC) is

    330 a compiler for the D programming Language. It is based on the DMD frontend
    331 and uses LLVM as backend.

    332
    333
    334
    335

    Open Shading Language

    336
    337
    338
    339

    Open Shading

    340 Language (OSL) is a small but rich language for programmable shading in
    341 advanced global illumination renderers and other applications, ideal for
    342 describing materials, lights, displacement, and pattern generation. It uses
    343 LLVM to JIT complex shader networks to x86 code at runtime.

    344
    345

    OSL was developed by Sony Pictures Imageworks for use in its in-house

    346 renderer used for feature film animation and visual effects, and is
    347 distributed as open source software with the "New BSD" license.

    348
    349
    350
    351

    Portable OpenCL (pocl)

    352
    353
    354
    355

    In addition to producing an easily portable open source OpenCL

    356 implementation, another major goal of
    357 pocl is improving performance portability of OpenCL programs with
    358 compiler optimizations, reducing the need for target-dependent manual
    359 optimizations. An important part of pocl is a set of LLVM passes used to
    360 statically parallelize multiple work-items with the kernel compiler, even in
    361 the presence of work-group barriers. This enables static parallelization of
    362 the fine-grained static concurrency in the work groups in multiple ways
    363 (SIMD, VLIW, superscalar,...).

    364
    365
    366
    272367

    Pure

    273368
    274

    Pure (http://pure-lang.googlecode.com/) is an algebraic/functional

    275 programming language based on term rewriting. Programs are collections of
    276 equations which are used to evaluate expressions in a symbolic fashion. The
    277 interpreter uses LLVM as a backend to JIT-compile Pure programs to fast native
    278 code. Pure offers dynamic typing, eager and lazy evaluation, lexical closures, a
    279 hygienic macro system (also based on term rewriting), built-in list and matrix
    280 support (including list and matrix comprehensions) and an easy-to-use interface
    281 to C and other programming languages (including the ability to load LLVM bitcode
    282 modules, and inline C, C++, Fortran and Faust code in Pure programs if the
    283 corresponding LLVM-enabled compilers are installed).>
    369 >
    370
    371

    Pure is an

    372 algebraic/functional programming language based on term rewriting. Programs
    373 are collections of equations which are used to evaluate expressions in a
    374 symbolic fashion. The interpreter uses LLVM as a backend to JIT-compile Pure
    375 programs to fast native code. Pure offers dynamic typing, eager and lazy
    376 evaluation, lexical closures, a hygienic macro system (also based on term
    377 rewriting), built-in list and matrix support (including list and matrix
    378 comprehensions) and an easy-to-use interface to C and other programming
    379 languages (including the ability to load LLVM bitcode modules, and inline C,
    380 C++, Fortran and Faust code in Pure programs if the corresponding
    381 LLVM-enabled compilers are installed).

    284382
    285383

    Pure version 0.54 has been tested and is known to work with LLVM 3.1 (and

    286 continues to work with older LLVM releases >= 2.5).

    384 continues to work with older LLVM releases >= 2.5).

    385
    386
    387
    388

    TTA-based Co-design Environment (TCE)

    389
    390
    391
    392

    TCE is a toolset for designing

    393 application-specific processors (ASP) based on the Transport triggered
    394 architecture (TTA). The toolset provides a complete co-design flow from C/C++
    395 programs down to synthesizable VHDL/Verilog and parallel program binaries.
    396 Processor customization points include the register files, function units,
    397 supported operations, and the interconnection network.

    398
    399

    TCE uses Clang and LLVM for C/C++ language support, target independent

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

    404
    405
    287406
    288407
    289408
    334453 A full featured assembler and direct-to-object support for ARM.
    335454
  • Basic Block Placement
  • 336455 Probability driven basic block placement.
    337
  • ....
  • 338456
    339457
    340458
    350468

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

    351469 expose new optimization opportunities:

    352470
    353
    354
  • IR support for half float
  • 355
  • IR support for vectors of pointers, including vector GEPs.
  • 356
  • Module flags have been introduced. They convey information about the
  • 357 module as a whole to LLVM subsystems.
    358
  • Loads can now have range metadata attached to them to describe the
  • 359 possible values being loaded.
    360
  • Inline cost heuristics have been completely overhauled and now closely
  • 361 model constant propagation through call sites, disregard trivially dead
    362 code costs, and can model C++ STL iterator patterns.
    363
  • ....
  • 364 ul>
    471 <ul>
    472
  • A new type representing 16 bit half floating point values has
  • 473 been added.
    474
  • IR now supports vectors of pointers, including vector GEPs.
  • 475
  • Module flags have been introduced. They convey information about the
  • 476 module as a whole to LLVM subsystems. This is currently used to encode
    477 Objective C ABI information.
    478
  • Loads can now have range metadata attached to them to describe the
  • 479 possible values being loaded.
    480
  • The llvm.ctlz and llvm.cttz intrinsics now have an
  • 481 additional argument which indicates whether the behavior of the intrinsic
    482 is undefined on a zero input. This can be used to generate more efficient
    483 code on platforms that only have instructions which don't return the type
    484 size when counting bits in 0.
    485
    486
    365487
    366488
    367489
    384506 post-vectorization cleanup passes. For more information, see the EuroLLVM
    385507 2012 slides:
    386508 Autovectorization with LLVM.
    387
  • ....
  • 509
  • Inline cost heuristics have been completely overhauled and now closely
  • 510 model constant propagation through call sites, disregard trivially dead
    511 code costs, and can model C++ STL iterator patterns.
    388512
    389513
    390514
    404528 to the LLVM MC Project Blog Post.

    405529
    406530
    407
  • ....
  • 531
  • The integrated assembler can optionally emit debug information when
  • 532 assembling a .s file. It can be enabled by passing the
    533 -g option to llvm-mc.
    408534
    409535
    410536
    441567 representation of large clobber lists on call instructions. The register
    442568 mask operand references a bit mask of preserved registers. Everything else
    443569 is clobbered.
    570
  • The DWARF debug info writer gained support for emitting data for the
  • 571 name accelerator tables
    572 DWARF extension. It is used by LLDB to speed up name lookup.
    444573
    445574
    446575

    We added new TableGen infrastructure to support bundling for

    474603

    New features and major changes in the X86 target include:

    475604
    476605
    477
  • Bug fixes and improved support for AVX1
  • 478
  • Support for AVX2 (still incomplete at this point)
  • 606
  • Greatly improved support for AVX2.
  • 607
  • Lots of bug fixes and improvements for AVX1.
  • 608
  • Support for the FMA4 and XOP instruction set extensions.
  • 479609
  • Call instructions use the new register mask operands for faster compile
  • 480610 times and better support for different calling conventions. The old WINCALL
    481611 instructions are no longer needed.
    482612
  • DW2 Exception Handling is enabled on Cygwin and MinGW.
  • 483
  • Support for implicit TLS model used with MS VC runtime
  • 613
  • Support for implicit TLS model used with MSVC runtime.
  • 484614
    485615
    486616
    525655
    526656
    527657
    528
    529

    This release has seen major new work on just about every aspect of the MIPS

    530 backend. Some of the major new features include:

    531
    532
    533
  • ....
  • 534 >
    658 New features and major changes in the MIPS target include:>
    659
    660
    661
  • MIPS32 little-endian direct object code emission is functional.
  • 662
  • MIPS64 little-endian code generation is largely functional for N64 ABI in assembly printing mode with the exception of handling of long double (f128) type.
  • 663
  • Support for new instructions has been added, which includes swap-bytes
  • 664 instructions (WSBH and DSBH), floating point multiply-add/subtract and
    665 negative multiply-add/subtract instructions, and floating
    666 point load/store instructions with reg+reg addressing (LWXC1, etc.)
    667
  • Various fixes to improve performance have been implemented.
  • 668
  • Post-RA scheduling is now enabled at -O3.
  • 669
  • Support for soft-float code generation has been added.
  • 670
  • clang driver's support for MIPS 64-bits targets.
  • 671
  • Support for MIPS floating point ABI option in clang driver.
  • 672
    673
    674
    675
    676

    677 PTX Target Improvements
    678
    679
    680
    681
    682

    An outstanding conditional inversion bug was fixed in this release.

    683
    684

    NOTE: LLVM 3.1 marks the last release of the PTX back-end, in its

    685 current form. The back-end is currently being replaced by the NVPTX
    686 back-end, currently in SVN ToT.

    687
    535688
    536689
    537690
    541694
    542695
    543696
    544

    Support for Qualcomm's Hexagon VLIW processor has been added.

    545
    546
    547
  • ....
  • 548
    549
    697
    698
  • Support for Qualcomm's Hexagon VLIW processor has been added.
  • 550699
    551700
    552701
    563712 from the previous release.

    564713
    565714
    715
  • LLVM's build system now requires a python 2 interpreter to be present at
  • 716 build time. A perl interpreter is no longer required.
    717
  • The C backend has been removed. It had numerous problems, to the point of
  • 718 not being able to compile any nontrivial program.
    719
  • The Alpha, Blackfin and SystemZ targets have been removed due to lack of
  • 720 maintenance.
    566721
  • LLVM 3.1 removes support for reading LLVM 2.9 bitcode files. Going
  • 567722 forward, we aim for all future versions of LLVM to read bitcode files and
    568723 .ll files produced by LLVM 3.0 and later.
    572727
  • LLVM 3.0 and earlier automatically added the returns_twice fo functions
  • 573728 like setjmp based on the name. This functionality was removed in 3.1.
    574729 This affects Clang users, if -ffreestanding is used.
    575
  • ....
  • 576730
    577731
    578732
    619773
  • llvm::getTrapFunctionName()
  • 620774
  • llvm::EnableSegmentedStacks
  • 621775
    622
  • The MDBuilder class has been added to simplify the creation of
  • 623 metadata.
    624
  • ....
  • 776
    777
  • The MDBuilder class has been added to simplify the creation
  • 778 of metadata.
    625779
    626780
    627781
    638792
    639793
    640794
    641
  • llvm-stress is a command line tool for generating random .ll files to fuzz
  • 642 different LLVM components.
    643
  • llvm-ld has been removed. Use llvm-link or Clang instead.
  • 644
  • ....
  • 645
    646
    647
    648
  • ....
  • 649
    795
  • llvm-stress is a command line tool for generating random
  • 796 .ll files to fuzz different LLVM components.
    797
  • The llvm-ld tool has been removed. The clang driver provides a
  • 798 more reliable solution for turning a set of bitcode files into a binary.
    799 To merge bitcode files llvm-link can be used instead.
    800
    801
    802
    803
    804
    805
    806

    807 Python Bindings
    808
    809
    810
    811
    812

    Officially supported Python bindings have been added! Feature support is far

    813 from complete. The current bindings support interfaces to:

    814
    815
  • Object File Interface
  • 816
  • Disassembler
  • 817
    818
    819

    Using the Object File Interface, it is possible to inspect binary object files.

    820 Think of it as a Python version of readelf or llvm-objdump.

    821
    822

    Support for additional features is currently being developed by community

    823 contributors. If you are interested in shaping the direction of the Python
    824 bindings, please express your intent on IRC or the developers list.

    650825
    651826
    652827
    672847

    Known problem areas include:

    673848
    674849
    675
  • The Alpha, Blackfin, CellSPU, MSP430, PTX, SystemZ and
  • 676 XCore backends are experimental, and the Alpha, Blackfin and SystemZ
    677 targets have already been removed from mainline.
    850
  • The CellSPU, MSP430, PTX and XCore backends are experimental.
  • 678851
    679852
  • The integrated assembler, disassembler, and JIT is not supported by
  • 680853 several targets. If an integrated assembler is not supported, then a
    681854 system assembler is required. For more details, see the
    682855 href="CodeGenerator.html#targetfeatures">Target Features Matrix.
    683856
    684
    685
  • The C backend has numerous problems and is not being actively maintained.
  • 686 Depending on it for anything serious is not advised.
    687857
    688858
    689859