X-Git-Url: http://demsky.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FReleaseNotes.html;h=733c1bf00e9bcc5df03e158e295b9946b4e55c51;hb=a0aa45c75979986054a5571dfbd78a4326ea78c0;hp=8cb60bb30ca193ef1d3beec8d2d03b11c297a2b3;hpb=0bad98c78bc23e76463d76bef71c1fed64330a93;p=oota-llvm.git diff --git a/docs/ReleaseNotes.html b/docs/ReleaseNotes.html index 8cb60bb30ca..733c1bf00e9 100644 --- a/docs/ReleaseNotes.html +++ b/docs/ReleaseNotes.html @@ -44,21 +44,21 @@ Release Notes.

This document contains the release notes for the LLVM Compiler -Infrastructure, release 3.0. Here we describe the status of LLVM, including -major improvements from the previous release and significant known problems. -All LLVM releases may be downloaded from the LLVM releases web site.

+ Infrastructure, release 3.0. Here we describe the status of LLVM, including + major improvements from the previous release and significant known problems. + All LLVM releases may be downloaded from + the LLVM releases web site.

For more information about LLVM, including information about the latest -release, please check out the main LLVM -web site. If you have questions or comments, the LLVM Developer's -Mailing List is a good place to send them.

+ release, please check out the main LLVM web + site. If you have questions or comments, + the LLVM + Developer's Mailing List is a good place to send them.

-

Note that if you are reading this file from a Subversion checkout or the -main LLVM web page, this document applies to the next release, not the -current one. To see the release notes for a specific release, please see the -releases page.

+

Note that if you are reading this file from a Subversion checkout or the main + LLVM web page, this document applies to the next release, not the + current one. To see the release notes for a specific release, please see the + releases page.

@@ -78,13 +78,12 @@ current one. To see the release notes for a specific release, please see the
-

-The LLVM 3.0 distribution currently consists of code from the core LLVM -repository (which roughly includes the LLVM optimizers, code generators -and supporting tools), the Clang repository and the llvm-gcc repository. In -addition to this code, the LLVM Project includes other sub-projects that are in -development. Here we include updates on these subprojects. -

+ +

The LLVM 3.0 distribution currently consists of code from the core LLVM + repository (which roughly includes the LLVM optimizers, code generators and + supporting tools), and the Clang repository. In + addition to this code, the LLVM Project includes other sub-projects that are + in development. Here we include updates on these subprojects.

@@ -94,35 +93,63 @@ development. Here we include updates on these subprojects.

Clang is an LLVM front end for the C, -C++, and Objective-C languages. Clang aims to provide a better user experience -through expressive diagnostics, a high level of conformance to language -standards, fast compilation, and low memory use. Like LLVM, Clang provides a -modular, library-based architecture that makes it suitable for creating or -integrating with other development tools. Clang is considered a -production-quality compiler for C, Objective-C, C++ and Objective-C++ on x86 -(32- and 64-bit), and for darwin/arm targets.

+ C++, and Objective-C languages. Clang aims to provide a better user + experience through expressive diagnostics, a high level of conformance to + language standards, fast compilation, and low memory use. Like LLVM, Clang + provides a modular, library-based architecture that makes it suitable for + creating or integrating with other development tools. Clang is considered a + production-quality compiler for C, Objective-C, C++ and Objective-C++ on x86 + (32- and 64-bit), and for darwin/arm targets.

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

    -
  • Greatly improved support for building C++ applications, with greater stability and better diagnostics.
    • +
  • Greatly improved support for building C++ applications, with greater + stability and better diagnostics.
    • -
  • Improved support for the C++ 2011 standard, including implementations of non-static data member initializers, alias templates, delegating constructors, the range-based for loop, and implicitly-generated move constructors and move assignment operators, among others.
    • - -
  • Implemented support for some features of the upcoming C1x standard, including static assertions and generic selections.
    • +
  • Improved support for + the C++ + 2011 standard, including implementations of non-static data member + initializers, alias templates, delegating constructors, the range-based + for loop, and implicitly-generated move constructors and move assignment + operators, among others.
    • + +
  • Implemented support for some features of the upcoming C1x standard, + including static assertions and generic selections.
    • -
  • Better detection of include and linking paths for system headers and libraries, especially for Linux distributions.
    • +
  • Better detection of include and linking paths for system headers and + libraries, especially for Linux distributions.
    • -
  • Implemented support for Automatic Reference Counting for Objective-C.
    • +
  • Several improvements to Objective-C support, including: -
  • Implemented a number of optimizations in libclang, the Clang C interface, to improve the performance of code completion and the mapping from source locations to abstract syntax tree nodes.
    • +
      +
    • + Automatic Reference Counting (ARC) and an improved memory model + cleanly separating object and C memory.
      • + +
    • A migration tool for moving legacy code to ARC
      • + +
    • Better support for data hiding, allowing instance variables to be + declared in implementation contexts or class extensions
      • +
    • Weak linking for classes
      • +
    • Improved static type checking by inferring the return type of methods + such as +alloc and -init.
      • +
    + + Some new features require either the Mac OS X 10.7 / iOS 5 Objective-C + runtime, or version 1.6 or later of the GNUstep Objective-C runtime + version. + +
  • Implemented a number of optimizations in libclang, the Clang C + interface, to improve the performance of code completion and the mapping + from source locations to abstract syntax tree nodes.

If Clang rejects your code but another compiler accepts it, please take a -look at the language -compatibility guide to make sure this is not intentional or a known issue. -

+ look at the language + compatibility guide to make sure this is not intentional or a known + issue.

@@ -132,20 +159,30 @@ compatibility guide to make sure this is not intentional or a known issue.

-

-DragonEgg is a -gcc plugin that replaces GCC's -optimizers and code generators with LLVM's. -Currently it requires a patched version of gcc-4.5. -The plugin can target the x86-32 and x86-64 processor families and has been -used successfully on the Darwin, FreeBSD and Linux platforms. -The Ada, C, C++ and Fortran languages work well. -The plugin is capable of compiling plenty of Obj-C, Obj-C++ and Java but it is -not known whether the compiled code actually works or not! -

+

DragonEgg is a + gcc plugin that replaces GCC's + optimizers and code generators with LLVM's. It works with gcc-4.5 or gcc-4.6, + targets the x86-32 and x86-64 processor families, and has been successfully + used on the Darwin, FreeBSD, KFreeBSD, Linux and OpenBSD platforms. It fully + supports Ada, C, C++ and Fortran. It has partial support for Go, Java, Obj-C + and Obj-C++.

+ +

The 3.0 release has the following notable changes:

+ +
  • GCC version 4.6 is now fully supported.
    • + +
  • Patching and building GCC is no longer required: the plugin should work + with your system GCC (version 4.5 or 4.6; on Debian/Ubuntu systems the + gcc-4.5-plugin-dev or gcc-4.6-plugin-dev package is also needed).
    • + +
  • The -fplugin-arg-dragonegg-enable-gcc-optzns option, which runs + GCC's optimizers as well as LLVM's, now works much better. This is the + option to use if you want ultimate performance! It not yet completely + stable: it may cause the plugin to crash.
    • + +
  • The type and constant conversion logic has been almost entirely rewritten, + fixing a multitude of obscure bugs.
    • -

    -The 3.0 release has the following notable changes:

    +

    Tart Programming Language

    @@ -397,104 +706,19 @@ object-oriented programming, operator overloading and strong typing.

    - - - - - +

    ThreadSanitizer

    - - +

    ThreadSanitizer is a + data race detector for (mostly) C and C++ code, available for Linux, Mac OS + and Windows. On different systems, we use binary instrumentation frameworks + (Valgrind and Pin) as frontends that generate the program events for the race + detection algorithm. On Linux, there's an option of using LLVM-based + compile-time instrumentation.

    - - - - - - - - @@ -506,9 +730,8 @@ Faust compiler can now generate LLVM bitcode, and works with LLVM 2.7-3.0.

    This release includes a huge number of bug fixes, performance tweaks and -minor improvements. Some of the major improvements and new features are listed -in this section. -

    + minor improvements. Some of the major improvements and new features are + listed in this section.

    @@ -517,8 +740,39 @@ in this section.
    +

    llvm-gcc is gone

    +

    LLVM 3.0 includes several major new capabilities:

    + + + + +
      +
    • landingpad — + this instruction defines a landing pad basic block. It contains all of the + information that's needed by the code generator. It's also required to be + the first non-PHI instruction in the landing pad. In addition, a landing + pad may be jumped to only by the unwind edge of an invoke + instruction.
      • + +
    • resume — this + instruction causes the current exception to resume traveling up the + stack. It replaces the @llvm.eh.resume intrinsic.
    +

    Converting from the old EH API to the new EH API is rather simple, because a + lot of complexity has been removed. The two intrinsics, + @llvm.eh.exception and @llvm.eh.selector have been + superseded by the landingpad instruction. Instead of generating + a call to @llvm.eh.exception and @llvm.eh.selector: + +

    +
    +Function *ExcIntr = Intrinsic::getDeclaration(TheModule,
+                                              Intrinsic::eh_exception);
+Function *SlctrIntr = Intrinsic::getDeclaration(TheModule,
+                                                Intrinsic::eh_selector);
+
+// The exception pointer.
+Value *ExnPtr = Builder.CreateCall(ExcIntr, "exc_ptr");
+
+std::vector<Value*> Args;
+Args.push_back(ExnPtr);
+Args.push_back(Builder.CreateBitCast(Personality,
+                                     Type::getInt8PtrTy(Context)));
+
+// Add selector clauses to Args.
+
+// The selector call.
+Builder.CreateCall(SlctrIntr, Args, "exc_sel");
+
    +
    + +

    You should instead generate a landingpad instruction, that + returns an exception object and selector value:

    + +
    +
    +LandingPadInst *LPadInst =
+  Builder.CreateLandingPad(StructType::get(Int8PtrTy, Int32Ty, NULL),
+                           Personality, 0);
+
+Value *LPadExn = Builder.CreateExtractValue(LPadInst, 0);
+Builder.CreateStore(LPadExn, getExceptionSlot());
+
+Value *LPadSel = Builder.CreateExtractValue(LPadInst, 1);
+Builder.CreateStore(LPadSel, getEHSelectorSlot());
+
    +
    + +

    It's now trivial to add the individual clauses to the landingpad + instruction.

    + +
    +
    +// Adding a catch clause
+Constant *TypeInfo = getTypeInfo();
+LPadInst->addClause(TypeInfo);
+
+// Adding a C++ catch-all
+LPadInst->addClause(Constant::getNullValue(Builder.getInt8PtrTy()));
+
+// Adding a cleanup
+LPadInst->setCleanup(true);
+
+// Adding a filter clause
+std::vector<Constant*> TypeInfos;
+Constant *TypeInfo = getFilterTypeInfo();
+TypeInfos.push_back(Builder.CreateBitCast(TypeInfo, Builder.getInt8PtrTy()));
+
+ArrayType *FilterTy = ArrayType::get(Int8PtrTy, TypeInfos.size());
+LPadInst->addClause(ConstantArray::get(FilterTy, TypeInfos));
+
    +
    + +

    Converting from using the @llvm.eh.resume intrinsic to + the resume instruction is trivial. It takes the exception + pointer and exception selector values returned by + the landingpad instruction:

    + +
    +
    +Type *UnwindDataTy = StructType::get(Builder.getInt8PtrTy(),
+                                     Builder.getInt32Ty(), NULL);
+Value *UnwindData = UndefValue::get(UnwindDataTy);
+Value *ExcPtr = Builder.CreateLoad(getExceptionObjSlot());
+Value *ExcSel = Builder.CreateLoad(getExceptionSelSlot());
+UnwindData = Builder.CreateInsertValue(UnwindData, ExcPtr, 0, "exc_ptr");
+UnwindData = Builder.CreateInsertValue(UnwindData, ExcSel, 1, "exc_sel");
+Builder.CreateResume(UnwindData);
+
    +
    + +
    + + +

    +Loop Optimization Improvements +

    + +
    +

    The induction variable simplification pass in 3.0 only modifies + induction variables when profitable. Sign and zero extension + elimination, linear function test replacement, loop unrolling, and + other simplifications that require induction variable analysis have + been generalized so they no longer require loops to be rewritten in a + typically suboptimal form prior to optimization. This new design + preserves more IR level information, avoids undoing earlier loop + optimizations (particularly hand-optimized loops), and no longer + strongly depends on the code generator rewriting loops a second time + in a now optimal form--an intractable problem.

    + +

    The original behavior can be restored with -mllvm -enable-iv-rewrite; + however, support for this mode will be short lived. As such, bug + reports should be filed for any significant performance regressions + when moving from -mllvm -enable-iv-rewrite to the 3.0 default mode.

    @@ -554,12 +937,17 @@ expose new optimization opportunities:

    In addition to a large array of minor performance tweaks and bug fixes, this -release includes a few major enhancements and additions to the optimizers:

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

    @@ -572,22 +960,27 @@ release includes a few major enhancements and additions to the optimizers:

    -

    -The LLVM Machine Code (aka MC) subsystem was created to solve a number -of problems in the realm of assembly, disassembly, object file format handling, -and a number of other related areas that CPU instruction-set level tools work -in.

    + +

    The LLVM Machine Code (aka MC) subsystem was created to solve a number of + problems in the realm of assembly, disassembly, object file format handling, + and a number of other related areas that CPU instruction-set level tools work + in.

      - +
    • The ELF object streamers are much more full featured.
      • +
    • Target dependent relocation handling has been refactored into the Targets.
      • +
    • Early stage MC-JIT infrastructure has been implemented.
    -

    For more information, please see the Intro to the -LLVM MC Project Blog Post. -

    +

    The MC-JIT is a major new feature for MC, and will eventually grow to replace +the current JIT implementation. It emits object files direct to memory and +uses a runtime dynamic linker to resolve references and drive lazy compilation. +The MC-JIT enables much greater code reuse between the JIT and the static +compiler and provides better integration with the platform ABI as a result.

    + +

    For more information, please see + the Intro + to the LLVM MC Project Blog Post.

    @@ -599,8 +992,8 @@ LLVM MC Project Blog Post.

    We have put a significant amount of work into the code generator -infrastructure, which allows us to implement more aggressive algorithms and make -it run faster:

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

      +
    • Reworked Set Jump Long Jump EH Lowering,
      • +
    • improved support for Cortex-M series processors, and
      • +
    • beta quality integrated assembler support.
    + + +

    +MIPS Target Improvements +

    + +
    + +

    New features and major changes in the MIPS target include:

    + +
      +
    • Most MIPS32r1 and r2 instructions are now supported.
      • +
    • LE/BE MIPS32r1/r2 has been tested extensively.
      • +
    • O32 ABI has been fully tested.
      • +
    • MIPS backend has migrated to using the MC infrastructure for assembly printing. Initial support for direct object code emission has been implemented too.
      • +
    • Delay slot filler has been updated. Now it tries to fill delay slots with useful instructions instead of always filling them with NOPs.
      • +
    • Support for old-style JIT is complete.
      • +
    • Support for old architectures (MIPS1 and MIPS2) has been removed.
      • +
    • Initial support for MIPS64 has been added.
      • +
    +
    + + +

    + PTX Target Improvements +

    + +
    + +

    + The PTX back-end is still experimental, but is fairly usable for compute kernels + in LLVM 3.0. Most scalar arithmetic is implemented, as well as intrinsics to + access the special PTX registers and sync instructions. The major missing + pieces are texture/sampler support and some vector operations.

    + +

    That said, the backend is already being used for domain-specific languages + and works well with the libclc + library to supply OpenCL built-ins. With it, you can use Clang to compile + OpenCL code into PTX and execute it by loading the resulting PTX as a binary + blob using the nVidia OpenCL library. It has been tested with several OpenCL + programs, including some from the nVidia GPU Computing SDK, and the performance + is on par with the nVidia compiler.

    + +
    +

    Other Target Specific Improvements

    + +

    PPC32/ELF va_arg was implemented.

    +

    PPC32 initial support for .o file writing was implemented.

    +

    MicroBlaze scheduling itineraries were added that model the + 3-stage and the 5-stage pipeline architectures. The 3-stage + pipeline model can be selected with -mcpu=mblaze3 + and the 5-stage pipeline model can be selected with + -mcpu=mblaze5.

    +
    +
    @@ -679,14 +1135,19 @@ it run faster:

    "load volatile"/"store volatile". The old syntax ("volatile load"/"volatile store") is still accepted, but is now considered deprecated. +
  • The old atomic intrinsics (llvm.memory.barrier and + llvm.atomic.*) are now gone. Please use the new atomic + instructions, described in the atomics guide.

    Windows (32-bit)

    +
    • On Win32(MinGW32 and MSVC), Windows 2000 will not be supported. Windows XP or higher is required.
    +
    • @@ -702,24 +1163,25 @@ it run faster:

    LLVM API changes are:

    +
    @@ -812,10 +1275,10 @@ merged with other structures, even if their layout is identical.
    -

    This section contains significant known problems with the LLVM system, -listed by component. If you run into a problem, please check the LLVM bug database and submit a bug if -there isn't already one.

    +

    This section contains significant known problems with the LLVM system, listed + by component. If you run into a problem, please check + the LLVM bug database and submit a bug if + there isn't already one.

    @@ -825,18 +1288,19 @@ there isn't already one.

    The following components of this LLVM release are either untested, known to -be broken or unreliable, or are in early development. These components should -not be relied on, and bugs should not be filed against them, but they may be -useful to some people. In particular, if you would like to work on one of these -components, please contact us on the LLVMdev list.

    + be broken or unreliable, or are in early development. These components + should not be relied on, and bugs should not be filed against them, but they + may be useful to some people. In particular, if you would like to work on + one of these components, please contact us on + the LLVMdev + list.

      -
    • The Alpha, CellSPU, MicroBlaze, MSP430, MIPS, PTX, - and XCore backends are experimental.
      • -
    • llc "-filetype=obj" is experimental on all targets - other than darwin and ELF X86 systems.
      • - +
    • The Alpha, Blackfin, CellSPU, MicroBlaze, MSP430, MIPS, PTX, SystemZ and + XCore backends are experimental.
      • + +
    • llc "-filetype=obj" is experimental on all targets other + than darwin and ELF X86 systems.
    @@ -849,27 +1313,9 @@ href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev list.

      -
    • The X86 backend does not yet support - all inline assembly that uses the X86 - floating point stack. It supports the 'f' and 't' constraints, but not - 'u'.
      • -
    • The X86-64 backend does not yet support the LLVM IR instruction - va_arg. Currently, front-ends support variadic - argument constructs on X86-64 by lowering them manually.
      • -
    • Windows x64 (aka Win64) code generator has a few issues. -
        -
      • llvm-gcc cannot build the mingw-w64 runtime currently - due to lack of support for the 'u' inline assembly - constraint and for X87 floating point inline assembly.
        • -
      • On mingw-w64, you will see unresolved symbol __chkstk - due to Bug 8919. - It is fixed in r128206.
        • -
      • Miss-aligned MOVDQA might crash your program. It is due to - Bug 9483, - lack of handling aligned internal globals.
        • -
      -
      • - +
    • The X86-64 backend does not yet support + the va_arg LLVM IR instruction. Currently, front-ends support + variadic argument constructs on X86-64 by lowering them manually.
    @@ -882,8 +1328,7 @@ href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev list.

      -
    • The Linux PPC32/ABI support needs testing for the interpreter and static -compilation, and lacks support for debug information.
      • +
    • The PPC32/ELF support lacks PIC support.
    @@ -896,11 +1341,12 @@ compilation, and lacks support for debug information.
      -
    • Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6 -processors, thumb programs can crash or produce wrong -results (PR1388).
      • -
    • Compilation for ARM Linux OABI (old ABI) is supported but not fully tested. -
      • +
    • Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6 + processors, thumb programs can crash or produce wrong results + (PR1388).
      • + +
    • Compilation for ARM Linux OABI (old ABI) is supported but not fully + tested.
    @@ -913,8 +1359,8 @@ results (PR1388).
      -
    • The SPARC backend only supports the 32-bit SPARC ABI (-m32); it does not - support the 64-bit SPARC ABI (-m64).
      • +
    • The SPARC backend only supports the 32-bit SPARC ABI (-m32); it does not + support the 64-bit SPARC ABI (-m64).
    @@ -927,7 +1373,7 @@ results (PR1388).
      -
    • 64-bit MIPS targets are not supported yet.
      • +
    • 64-bit MIPS targets are not supported yet.
    @@ -940,11 +1386,10 @@ results (PR1388).
      - -
    • On 21164s, some rare FP arithmetic sequences which may trap do not have the -appropriate nops inserted to ensure restartability.
      • - +
    • On 21164s, some rare FP arithmetic sequences which may trap do not have + the appropriate nops inserted to ensure restartability.
    +
    @@ -955,47 +1400,21 @@ appropriate nops inserted to ensure restartability.

    The C backend has numerous problems and is not being actively maintained. -Depending on it for anything serious is not advised.

    + Depending on it for anything serious is not advised.

    +
  • The C backend has only basic support for + inline assembly code.
    • -
    - - - -

    - Known problems with the llvm-gcc front-end -

    - -
    +
  • The C backend violates the ABI of common + C++ programs, preventing intermixing between C++ compiled by the CBE + and C++ code compiled with llc or native compilers.
    • -

    LLVM 3.0 will be the last release of llvm-gcc.

    +
  • The C backend does not support all exception handling constructs.
    • -

    llvm-gcc is generally very stable for the C family of languages. The only - major language feature of GCC not supported by llvm-gcc is the - __builtin_apply family of builtins. However, some extensions - are only supported on some targets. For example, trampolines are only - supported on some targets (these are used when you take the address of a - nested function).

    - -

    Fortran support generally works, but there are still several unresolved bugs - in Bugzilla. Please see the - tools/gfortran component for details. Note that llvm-gcc is missing major - Fortran performance work in the frontend and library that went into GCC after - 4.2. If you are interested in Fortran, we recommend that you consider using - dragonegg instead.

    +
  • The C backend does not support arbitrary precision integers.
    • + -

    The llvm-gcc 4.2 Ada compiler has basic functionality, but is no longer being -actively maintained. If you are interested in Ada, we recommend that you -consider using dragonegg instead.

    @@ -1008,17 +1427,16 @@ consider using dragonegg instead.

    -

    A wide variety of additional information is available on the LLVM web page, in particular in the documentation section. The web page also -contains versions of the API documentation which is up-to-date with the -Subversion version of the source code. -You can access versions of these documents specific to this release by going -into the "llvm/doc/" directory in the LLVM tree.

    +

    A wide variety of additional information is available on + the LLVM web page, in particular in + the documentation section. The web page + also contains versions of the API documentation which is up-to-date with the + Subversion version of the source code. You can access versions of these + documents specific to this release by going into the "llvm/doc/" + directory in the LLVM tree.

    If you have any questions or comments about LLVM, please feel free to contact -us via the mailing -lists.

    + us via the mailing lists.