Date: Thu, 20 Oct 2011 21:10:27 +0000 Subject: Vendor import of llvm release_30 branch r142614: http://llvm.org/svn/llvm-project/llvm/branches/release_30@142614 --- docs/ReleaseNotes.html | 769 +++++++++++++++++++++++++++++++------------------ 1 file changed, 493 insertions(+), 276 deletions(-) (limited to 'docs/ReleaseNotes.html') diff --git a/docs/ReleaseNotes.html b/docs/ReleaseNotes.html index d54698d..b0d4f67 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), 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.

@@ -94,20 +93,47 @@ 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.
+ +
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.
+ +
Implemented support + for Automatic + Reference Counting for Objective-C.
+ +
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.

@@ -117,20 +143,17 @@ 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. 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!

+ +

The 3.0 release has the following notable changes:

-The 3.0 release has the following notable changes:

dual

The VMKit project is an implementation - of a Java Virtual Machine (Java VM or JVM) that uses LLVM for static and - just-in-time compilation. As of LLVM 3.0, VMKit now supports generational - garbage collectors. The garbage collectors are provided by the MMTk framework, - and VMKit can be configured to use one of the numerous implemented collectors - of MMTk. -

+ of a Java Virtual Machine (Java VM or JVM) that uses LLVM for static and + just-in-time compilation. As of LLVM 3.0, VMKit now supports generational + garbage collectors. The garbage collectors are provided by the MMTk + framework, and VMKit can be configured to use one of the numerous implemented + collectors of MMTk.

Crack Programming Language

-Crack aims to provide the -ease of development of a scripting language with the performance of a compiled -language. The language derives concepts from C++, Java and Python, incorporating -object-oriented programming, operator overloading and strong typing.

+ +

Crack aims to provide + the ease of development of a scripting language with the performance of a + compiled language. The language derives concepts from C++, Java and Python, + incorporating object-oriented programming, operator overloading and strong + typing.

TTA-based Codesign Environment (TCE)

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

+ the Transport triggered architecture (TTA). The toolset provides a complete + co-design flow from C/C++ programs down to synthesizable VHDL and parallel + program binaries. Processor customization points include the register files, + function units, supported operations, and the interconnection network.

TCE uses Clang and LLVM for C/C++ language support, target independent -optimizations and also for parts of code generation. It generates new LLVM-based -code generators "on the fly" for the designed TTA processors and loads them in -to the compiler backend as runtime libraries to avoid per-target recompilation -of larger parts of the compiler chain.

PinaVM

PinaVM is an open -source, SystemC front-end. Unlike many -other front-ends, PinaVM actually executes the elaboration of the -program analyzed using LLVM's JIT infrastructure. It later enriches the -bitcode with SystemC-specific information.

+ source, SystemC front-end. Unlike many + other front-ends, PinaVM actually executes the elaboration of the program + analyzed using LLVM's JIT infrastructure. It later enriches the bitcode with + SystemC-specific information.

Pure

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

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

Pure version 0.47 has been tested and is known to work with LLVM 3.0 - (and continues to work with older LLVM releases >= 2.5).

Pure version 0.47 has been tested and is known to work with LLVM 3.0 (and + continues to work with older LLVM releases >= 2.5).

IcedTea Java Virtual Machine Implementation

-IcedTea provides a -harness to build OpenJDK using only free software build tools and to provide -replacements for the not-yet free parts of OpenJDK. One of the extensions that -IcedTea provides is a new JIT compiler named Shark which uses LLVM -to provide native code generation without introducing processor-dependent -code. -

OpenJDK 7 b112, IcedTea6 1.9 and IcedTea7 1.13 and later have been tested -and are known to work with LLVM 3.0 (and continue to work with older LLVM -releases >= 2.6 as well).

IcedTea provides a + harness to build OpenJDK using only free software build tools and to provide + replacements for the not-yet free parts of OpenJDK. One of the extensions + that IcedTea provides is a new JIT compiler + named Shark + which uses LLVM to provide native code generation without introducing + processor-dependent code.

+ +

OpenJDK 7 b112, IcedTea6 1.9 and IcedTea7 1.13 and later have been tested and + are known to work with LLVM 3.0 (and continue to work with older LLVM + releases >= 2.6 as well).

Glasgow Haskell Compiler (GHC)

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

+ +

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

In addition to the existing C and native code generators, GHC 7.0 now -supports an LLVM code generator. GHC supports LLVM 2.7 and later.

+ supports an LLVM code generator. GHC supports LLVM 2.7 and later.

Polly - Polyhedral optimizations for LLVM

Polly is a project that aims to provide advanced memory access optimizations -to better take advantage of SIMD units, cache hierarchies, multiple cores or -even vector accelerators for LLVM. Built around an abstract mathematical -description based on Z-polyhedra, it provides the infrastructure to develop -advanced optimizations in LLVM and to connect complex external optimizers. In -its first year of existence Polly already provides an exact value-based -dependency analysis as well as basic SIMD and OpenMP code generation support. -Furthermore, Polly can use PoCC(Pluto) an advanced optimizer for data-locality -and parallelism.

+ to better take advantage of SIMD units, cache hierarchies, multiple cores or + even vector accelerators for LLVM. Built around an abstract mathematical + description based on Z-polyhedra, it provides the infrastructure to develop + advanced optimizations in LLVM and to connect complex external optimizers. In + its first year of existence Polly already provides an exact value-based + dependency analysis as well as basic SIMD and OpenMP code generation support. + Furthermore, Polly can use PoCC(Pluto) an advanced optimizer for + data-locality and parallelism.

Rubinius

Rubinius is an environment - for running Ruby code which strives to write as much of the implementation in - Ruby as possible. Combined with a bytecode interpreting VM, it uses LLVM to - optimize and compile ruby code down to machine code. Techniques such as type - feedback, method inlining, and deoptimization are all used to remove dynamism - from ruby execution and increase performance.

Rubinius is an environment + for running Ruby code which strives to write as much of the implementation in + Ruby as possible. Combined with a bytecode interpreting VM, it uses LLVM to + optimize and compile ruby code down to machine code. Techniques such as type + feedback, method inlining, and deoptimization are all used to remove dynamism + from ruby execution and increase performance.

+ +

@@ -398,12 +427,13 @@ and parallelism.

-FAUST is a compiled language for real-time -audio signal processing. The name FAUST stands for Functional AUdio STream. Its -programming model combines two approaches: functional programming and block -diagram composition. In addition with the C, C++, JAVA output formats, the -Faust compiler can now generate LLVM bitcode, and works with LLVM 2.7-3.0.

+ +

FAUST is a compiled language for + real-time audio signal processing. The name FAUST stands for Functional AUdio + STream. Its programming model combines two approaches: functional programming + and block diagram composition. In addition with the C, C++, JAVA output + formats, the Faust compiler can now generate LLVM bitcode, and works with + LLVM 2.7-3.0.

@@ -418,9 +448,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.

@@ -447,15 +476,121 @@ in this section.

LLVM IR has several new features for better support of new targets and that -expose new optimization opportunities:

+ expose new optimization opportunities:

+ +

One of the biggest changes is that 3.0 has a new exception handling + system. The old system used LLVM intrinsics to convey the exception handling + information to the code generator. It worked in most cases, but not + all. Inlining was especially difficult to get right. Also, the intrinsics + could be moved away from the invoke instruction, making it hard + to recover that information.

+ +

The new EH system makes exception handling a first-class member of the IR. It + adds two new instructions:

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 + superceded 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);
+

@@ -466,7 +601,8 @@ 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:

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

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

@@ -511,8 +646,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:

@@ -576,18 +715,35 @@ it run faster:

If you're already an LLVM user or developer with out-of-tree changes based -on LLVM 2.9, this section lists some "gotchas" that you may run into upgrading -from the previous release.

If you're already an LLVM user or developer with out-of-tree changes based on + LLVM 2.9, this section lists some "gotchas" that you may run into upgrading + from the previous release.

The LLVMC front end code was removed while separating + out language independence.
The LowerSetJmp pass wasn't used effectively by any + target and has been removed.
The old TailDup pass was not used in the standard pipeline + and was unable to update ssa form, so it has been removed. +
The syntax of volatile loads and stores in IR has been changed to + "load volatile"/"store volatile". The old + syntax ("volatile load"/"volatile store") + is still accepted, but is now considered deprecated.

+ +

Windows (32-bit)

+ +

On Win32(MinGW32 and MSVC), Windows 2000 will not be supported. + Windows XP or higher is required.

Internal API Changes @@ -596,33 +752,41 @@ from the previous release.

In addition, many APIs have changed in this release. Some of the major - LLVM API changes are:
+ LLVM API changes are:

- -
`PHINode::reserveOperandSpace` has been removed. Instead, you - must specify how many operands to reserve space for when you create the - PHINode, by passing an extra argument into `PHINode::Create`.
- -
PHINodes no longer store their incoming BasicBlocks as operands. Instead, - the list of incoming BasicBlocks is stored separately, and can be accessed - with new functions `PHINode::block_begin` - and `PHINode::block_end`.
- -
Various functions now take an `ArrayRef` instead of either a pair - of pointers (or iterators) to the beginning and end of a range, or a pointer - and a length. Others now return an `ArrayRef` instead of a - reference to a `SmallVector` or `std::vector`. These - include: +
The biggest and most pervasive change is that llvm::Type's are no longer + returned or accepted as 'const' values. Instead, just pass around + non-const Type's.
+ +
`PHINode::reserveOperandSpace` has been removed. Instead, you + must specify how many operands to reserve space for when you create the + PHINode, by passing an extra argument + into `PHINode::Create`.
+ +
PHINodes no longer store their incoming BasicBlocks as operands. Instead, + the list of incoming BasicBlocks is stored separately, and can be accessed + with new functions `PHINode::block_begin` + and `PHINode::block_end`.
+ +
Various functions now take an `ArrayRef` instead of either a + pair of pointers (or iterators) to the beginning and end of a range, or a + pointer and a length. Others now return an `ArrayRef` instead + of a reference to a `SmallVector` + or `std::vector`. These include:

`CallInst::Create`

`ComputeLinearIndex` (in `llvm/CodeGen/Analysis.h`)

`ConstantArray::get`

`ConstantExpr::getExtractElement`
+
`ConstantExpr::getGetElementPtr`
+
`ConstantExpr::getInBoundsGetElementPtr`

`ConstantExpr::getIndices`

`ConstantExpr::getInsertElement`

`ConstantExpr::getWithOperands`
+
`ConstantFoldCall` (in `llvm/Analysis/ConstantFolding.h`)
+
`ConstantFoldInstOperands` (in `llvm/Analysis/ConstantFolding.h`)

`ConstantVector::get`

`DIBuilder::createComplexVariable`

`DIBuilder::getOrCreateArray`
@@ -630,23 +794,67 @@ from the previous release.

`ExtractValueInst::getIndexedType`

`ExtractValueInst::getIndices`

`FindInsertedValue` (in `llvm/Analysis/ValueTracking.h`)
+
`gep_type_begin` (in `llvm/Support/GetElementPtrTypeIterator.h`)
+
`gep_type_end` (in `llvm/Support/GetElementPtrTypeIterator.h`)
+
`GetElementPtrInst::Create`
+
`GetElementPtrInst::CreateInBounds`
+
`GetElementPtrInst::getIndexedType`
+
`InsertValueInst::Create`
+
`InsertValueInst::getIndices`
+
`InvokeInst::Create`

`IRBuilder::CreateCall`

`IRBuilder::CreateExtractValue`
+
`IRBuilder::CreateGEP`
+
`IRBuilder::CreateInBoundsGEP`

`IRBuilder::CreateInsertValue`

`IRBuilder::CreateInvoke`
-
`InsertValueInst::Create`
-
`InsertValueInst::getIndices`
-
`InvokeInst::Create`

`MDNode::get`

`MDNode::getIfExists`

`MDNode::getTemporary`

`MDNode::getWhenValsUnresolved`
+
`SimplifyGEPInst` (in `llvm/Analysis/InstructionSimplify.h`)
+
`TargetData::getIndexedOffset`

-
All forms of `StringMap::getOrCreateValue` have been remove - except for the one which takes a `StringRef`.
+
All forms of `StringMap::getOrCreateValue` have been remove + except for the one which takes a `StringRef`.
+ +
The `LLVMBuildUnwind` function from the C API was removed. The + LLVM `unwind` instruction has been deprecated for a long time + and isn't used by the current front-ends. So this was removed during the + exception handling rewrite.
+ +
The `LLVMAddLowerSetJmpPass` function from the C API was + removed because the `LowerSetJmp` pass was removed.
+ +
The `DIBuilder` interface used by front ends to encode + debugging information in the LLVM IR now expects clients to + use `DIBuilder::finalize()` at the end of translation unit to + complete debugging information encoding.
+ +
The way the type system works has been + rewritten: `PATypeHolder` and `OpaqueType` are gone, + and all APIs deal with `Type` instead of `const + Type`. If you need to create recursive structures, then create a + named structure, and use `setBody()` when all its elements are + built. Type merging and refining is gone too: named structures are not + merged with other structures, even if their layout is identical. (of + course anonymous structures are still uniqued by layout).
+ +
TargetSelect.h moved to Support/ from Target/
+
UpgradeIntrinsicCall no longer upgrades pre-2.9 intrinsic calls (for + example `llvm.memset.i32`).
+ +
It is mandatory to initialize all out-of-tree passes too and their dependencies now with + `INITIALIZE_PASS{BEGIN,END,}` + and `INITIALIZE_{PASS,AG}_DEPENDENCY`.
+ +
The interface for MemDepResult in MemoryDependenceAnalysis has been + enhanced with new return types Unknown and NonFuncLocal, in addition to + the existing types Clobber, Def, and NonLocal.

+

@@ -659,10 +867,10 @@ from the previous release.

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.

@@ -672,18 +880,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, 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.
- +
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.

@@ -697,23 +906,28 @@ 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'.
+ 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.
+ `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.
+
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.
+ Bug 9483, lack + of handling aligned internal globals.

@@ -729,8 +943,8 @@ 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 Linux PPC32/ABI support needs testing for the interpreter and static + compilation, and lacks support for debug information.

@@ -743,11 +957,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.

@@ -760,8 +975,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).

@@ -774,7 +989,7 @@ results (PR1388).

-
64-bit MIPS targets are not supported yet.
+
64-bit MIPS targets are not supported yet.

@@ -787,11 +1002,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.

+
@@ -802,16 +1016,19 @@ 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.
-
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.
-
The C backend does not support all exception handling constructs.
-
The C backend does not support arbitrary precision integers.
+
The C backend has only basic support for + inline assembly code.
+ +
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.
+ +
The C backend does not support all exception handling constructs.
+ +
The C backend does not support arbitrary precision integers.

@@ -824,7 +1041,7 @@ Depending on it for anything serious is not advised.

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

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 @@ -841,8 +1058,9 @@ Depending on it for anything serious is not advised.
dragonegg instead.

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.
+ actively maintained. If you are interested in Ada, we recommend that you + consider using dragonegg instead.
+

@@ -855,17 +1073,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.

@@ -879,7 +1096,7 @@ lists.

src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"> LLVM Compiler Infrastructure
- Last modified: $Date: 2011-07-15 10:37:34 +0200 (Fri, 15 Jul 2011) $ + Last modified: $Date: 2011-10-17 08:31:58 +0200 (Mon, 17 Oct 2011) $ -- cgit v1.1