diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/CodeGenerator.html | 196 | ||||
| -rw-r--r-- | docs/CommandGuide/index.html | 3 | ||||
| -rw-r--r-- | docs/CommandGuide/llvm-build.pod | 5 | ||||
| -rw-r--r-- | docs/CommandGuide/llvm-cov.pod | 45 | ||||
| -rw-r--r-- | docs/ExceptionHandling.html | 23 | ||||
| -rw-r--r-- | docs/LLVMBuild.html | 16 | ||||
| -rw-r--r-- | docs/LLVMBuild.txt | 1 | ||||
| -rw-r--r-- | docs/LangRef.html | 391 | ||||
| -rw-r--r-- | docs/ReleaseNotes.html | 1125 | ||||
| -rw-r--r-- | docs/SegmentedStacks.html | 8 | ||||
| -rw-r--r-- | docs/TestingGuide.html | 27 |
11 files changed, 619 insertions, 1221 deletions
diff --git a/docs/CodeGenerator.html b/docs/CodeGenerator.html index 62ea6ca..345eb7c 100644 --- a/docs/CodeGenerator.html +++ b/docs/CodeGenerator.html @@ -50,6 +50,7 @@ <li><a href="#machinebasicblock">The <tt>MachineBasicBlock</tt> class</a></li> <li><a href="#machinefunction">The <tt>MachineFunction</tt> class</a></li> + <li><a href="#machineinstrbundle"><tt>MachineInstr Bundles</tt></a></li> </ul> </li> <li><a href="#mc">The "MC" Layer</a> @@ -97,6 +98,14 @@ <li><a href="#regAlloc_builtIn">Built in register allocators</a></li> </ul></li> <li><a href="#codeemit">Code Emission</a></li> + <li><a href="#vliw_packetizer">VLIW Packetizer</a> + <ul> + <li><a href="#vliw_mapping">Mapping from instructions to functional + units</a></li> + <li><a href="#vliw_repr">How the packetization tables are + generated and used</a></li> + </ul> + </li> </ul> </li> <li><a href="#nativeassembler">Implementing a Native Assembler</a></li> @@ -753,6 +762,88 @@ ret </div> +<!-- ======================================================================= --> +<h3> + <a name="machineinstrbundle"><tt>MachineInstr Bundles</tt></a> +</h3> + +<div> + +<p>LLVM code generator can model sequences of instructions as MachineInstr + bundles. A MI bundle can model a VLIW group / pack which contains an + arbitrary number of parallel instructions. It can also be used to model + a sequential list of instructions (potentially with data dependencies) that + cannot be legally separated (e.g. ARM Thumb2 IT blocks).</p> + +<p>Conceptually a MI bundle is a MI with a number of other MIs nested within: +</p> + +<div class="doc_code"> +<pre> +-------------- +| Bundle | --------- +-------------- \ + | ---------------- + | | MI | + | ---------------- + | | + | ---------------- + | | MI | + | ---------------- + | | + | ---------------- + | | MI | + | ---------------- + | +-------------- +| Bundle | -------- +-------------- \ + | ---------------- + | | MI | + | ---------------- + | | + | ---------------- + | | MI | + | ---------------- + | | + | ... + | +-------------- +| Bundle | -------- +-------------- \ + | + ... +</pre> +</div> + +<p> MI bundle support does not change the physical representations of + MachineBasicBlock and MachineInstr. All the MIs (including top level and + nested ones) are stored as sequential list of MIs. The "bundled" MIs are + marked with the 'InsideBundle' flag. A top level MI with the special BUNDLE + opcode is used to represent the start of a bundle. It's legal to mix BUNDLE + MIs with indiviual MIs that are not inside bundles nor represent bundles. +</p> + +<p> MachineInstr passes should operate on a MI bundle as a single unit. Member + methods have been taught to correctly handle bundles and MIs inside bundles. + The MachineBasicBlock iterator has been modified to skip over bundled MIs to + enforce the bundle-as-a-single-unit concept. An alternative iterator + instr_iterator has been added to MachineBasicBlock to allow passes to + iterate over all of the MIs in a MachineBasicBlock, including those which + are nested inside bundles. The top level BUNDLE instruction must have the + correct set of register MachineOperand's that represent the cumulative + inputs and outputs of the bundled MIs.</p> + +<p> Packing / bundling of MachineInstr's should be done as part of the register + allocation super-pass. More specifically, the pass which determines what + MIs should be bundled together must be done after code generator exits SSA + form (i.e. after two-address pass, PHI elimination, and copy coalescing). + Bundles should only be finalized (i.e. adding BUNDLE MIs and input and + output register MachineOperands) after virtual registers have been + rewritten into physical registers. This requirement eliminates the need to + add virtual register operands to BUNDLE instructions which would effectively + double the virtual register def and use lists.</p> + </div> <!-- *********************************************************************** --> @@ -2001,6 +2092,73 @@ to implement an assembler for your target.</p> </div> +<!-- ======================================================================= --> +<h3> + <a name="vliw_packetizer">VLIW Packetizer</a> +</h3> + +<div> + +<p>In a Very Long Instruction Word (VLIW) architecture, the compiler is + responsible for mapping instructions to functional-units available on + the architecture. To that end, the compiler creates groups of instructions + called <i>packets</i> or <i>bundles</i>. The VLIW packetizer in LLVM is + a target-independent mechanism to enable the packetization of machine + instructions.</p> + +<!-- _______________________________________________________________________ --> + +<h4> + <a name="vliw_mapping">Mapping from instructions to functional units</a> +</h4> + +<div> + +<p>Instructions in a VLIW target can typically be mapped to multiple functional +units. During the process of packetizing, the compiler must be able to reason +about whether an instruction can be added to a packet. This decision can be +complex since the compiler has to examine all possible mappings of instructions +to functional units. Therefore to alleviate compilation-time complexity, the +VLIW packetizer parses the instruction classes of a target and generates tables +at compiler build time. These tables can then be queried by the provided +machine-independent API to determine if an instruction can be accommodated in a +packet.</p> +</div> + +<!-- ======================================================================= --> +<h4> + <a name="vliw_repr"> + How the packetization tables are generated and used + </a> +</h4> + +<div> + +<p>The packetizer reads instruction classes from a target's itineraries and +creates a deterministic finite automaton (DFA) to represent the state of a +packet. A DFA consists of three major elements: inputs, states, and +transitions. The set of inputs for the generated DFA represents the instruction +being added to a packet. The states represent the possible consumption +of functional units by instructions in a packet. In the DFA, transitions from +one state to another occur on the addition of an instruction to an existing +packet. If there is a legal mapping of functional units to instructions, then +the DFA contains a corresponding transition. The absence of a transition +indicates that a legal mapping does not exist and that the instruction cannot +be added to the packet.</p> + +<p>To generate tables for a VLIW target, add <i>Target</i>GenDFAPacketizer.inc +as a target to the Makefile in the target directory. The exported API provides +three functions: <tt>DFAPacketizer::clearResources()</tt>, +<tt>DFAPacketizer::reserveResources(MachineInstr *MI)</tt>, and +<tt>DFAPacketizer::canReserveResources(MachineInstr *MI)</tt>. These functions +allow a target packetizer to add an instruction to an existing packet and to +check whether an instruction can be added to a packet. See +<tt>llvm/CodeGen/DFAPacketizer.h</tt> for more information.</p> + +</div> + +</div> + </div> <!-- *********************************************************************** --> @@ -2213,6 +2371,7 @@ is the key:</p> <th>Feature</th> <th>ARM</th> <th>CellSPU</th> + <th>Hexagon</th> <th>MBlaze</th> <th>MSP430</th> <th>Mips</th> @@ -2227,6 +2386,7 @@ is the key:</p> <td><a href="#feat_reliable">is generally reliable</a></td> <td class="yes"></td> <!-- ARM --> <td class="no"></td> <!-- CellSPU --> + <td class="yes"></td> <!-- Hexagon --> <td class="no"></td> <!-- MBlaze --> <td class="unknown"></td> <!-- MSP430 --> <td class="yes"></td> <!-- Mips --> @@ -2241,6 +2401,7 @@ is the key:</p> <td><a href="#feat_asmparser">assembly parser</a></td> <td class="no"></td> <!-- ARM --> <td class="no"></td> <!-- CellSPU --> + <td class="no"></td> <!-- Hexagon --> <td class="yes"></td> <!-- MBlaze --> <td class="no"></td> <!-- MSP430 --> <td class="no"></td> <!-- Mips --> @@ -2255,6 +2416,7 @@ is the key:</p> <td><a href="#feat_disassembler">disassembler</a></td> <td class="yes"></td> <!-- ARM --> <td class="no"></td> <!-- CellSPU --> + <td class="no"></td> <!-- Hexagon --> <td class="yes"></td> <!-- MBlaze --> <td class="no"></td> <!-- MSP430 --> <td class="no"></td> <!-- Mips --> @@ -2269,6 +2431,7 @@ is the key:</p> <td><a href="#feat_inlineasm">inline asm</a></td> <td class="yes"></td> <!-- ARM --> <td class="no"></td> <!-- CellSPU --> + <td class="yes"></td> <!-- Hexagon --> <td class="yes"></td> <!-- MBlaze --> <td class="unknown"></td> <!-- MSP430 --> <td class="no"></td> <!-- Mips --> @@ -2283,6 +2446,7 @@ is the key:</p> <td><a href="#feat_jit">jit</a></td> <td class="partial"><a href="#feat_jit_arm">*</a></td> <!-- ARM --> <td class="no"></td> <!-- CellSPU --> + <td class="no"></td> <!-- Hexagon --> <td class="no"></td> <!-- MBlaze --> <td class="unknown"></td> <!-- MSP430 --> <td class="yes"></td> <!-- Mips --> @@ -2297,6 +2461,7 @@ is the key:</p> <td><a href="#feat_objectwrite">.o file writing</a></td> <td class="no"></td> <!-- ARM --> <td class="no"></td> <!-- CellSPU --> + <td class="no"></td> <!-- Hexagon --> <td class="yes"></td> <!-- MBlaze --> <td class="no"></td> <!-- MSP430 --> <td class="no"></td> <!-- Mips --> @@ -2311,6 +2476,7 @@ is the key:</p> <td><a href="#feat_tailcall">tail calls</a></td> <td class="yes"></td> <!-- ARM --> <td class="no"></td> <!-- CellSPU --> + <td class="yes"></td> <!-- Hexagon --> <td class="no"></td> <!-- MBlaze --> <td class="unknown"></td> <!-- MSP430 --> <td class="no"></td> <!-- Mips --> @@ -2321,6 +2487,20 @@ is the key:</p> <td class="unknown"></td> <!-- XCore --> </tr> +<tr> + <td><a href="#feat_segstacks">segmented stacks</a></td> + <td class="no"></td> <!-- ARM --> + <td class="no"></td> <!-- CellSPU --> + <td class="no"></td> <!-- MBlaze --> + <td class="no"></td> <!-- MSP430 --> + <td class="no"></td> <!-- Mips --> + <td class="no"></td> <!-- PTX --> + <td class="no"></td> <!-- PowerPC --> + <td class="no"></td> <!-- Sparc --> + <td class="partial"><a href="#feat_segstacks_x86">*</a></td> <!-- X86 --> + <td class="no"></td> <!-- XCore --> +</tr> + </table> @@ -2404,6 +2584,22 @@ more more details</a>.</p> </div> +<!-- _______________________________________________________________________ --> +<h4 id="feat_segstacks">Segmented Stacks</h4> + +<div> + +<p>This box indicates whether the target supports segmented stacks. This +replaces the traditional large C stack with many linked segments. It +is compatible with the <a href="http://gcc.gnu.org/wiki/SplitStacks">gcc +implementation</a> used by the Go front end.</p> + +<p id="feat_segstacks_x86">Basic support exists on the X86 backend. Currently +vararg doesn't work and the object files are not marked the way the gold +linker expects, but simple Go programs can be built by dragonegg.</p> + +</div> + </div> <!-- ======================================================================= --> diff --git a/docs/CommandGuide/index.html b/docs/CommandGuide/index.html index 166cca1..145569c 100644 --- a/docs/CommandGuide/index.html +++ b/docs/CommandGuide/index.html @@ -72,6 +72,9 @@ options) arguments to the tool you are interested in.</p> <li><a href="/cmds/llvm-diff.html"><b>llvm-diff</b></a> - structurally compare two modules</li> +<li><a href="/cmds/llvm-cov.html"><b>llvm-cov</b></a> - + emit coverage information</li> + </ul> </div> diff --git a/docs/CommandGuide/llvm-build.pod b/docs/CommandGuide/llvm-build.pod index 78648ba..14e08cb 100644 --- a/docs/CommandGuide/llvm-build.pod +++ b/docs/CommandGuide/llvm-build.pod @@ -46,7 +46,10 @@ component combinations. =item B<--write-llvmbuild> Write out new I<LLVMBuild.txt> files based on the loaded components. This is -useful for auto-upgrading the schema of the files. +useful for auto-upgrading the schema of the files. B<llvm-build> will try to a +limited extent to preserve the comments which were written in the original +source file, although at this time it only preserves block comments that preceed +the section names in the I<LLVMBuild> files. =item B<--write-cmake-fragment> diff --git a/docs/CommandGuide/llvm-cov.pod b/docs/CommandGuide/llvm-cov.pod new file mode 100644 index 0000000..e8ff683 --- /dev/null +++ b/docs/CommandGuide/llvm-cov.pod @@ -0,0 +1,45 @@ +=pod + +=head1 NAME + +llvm-cov - emit coverage information + +=head1 SYNOPSIS + +B<llvm-cov> [-gcno=filename] [-gcda=filename] [dump] + +=head1 DESCRIPTION + +The experimental B<llvm-cov> tool reads in description file generated by compiler +and coverage data file generated by instrumented program. This program assumes +that the description and data file uses same format as gcov files. + +=head1 OPTIONS + +=over + +=item B<-gcno=filename] + +This option selects input description file generated by compiler while instrumenting +program. + +=item B<-gcda=filename] + +This option selects coverage data file generated by instrumented compiler. + +=item B<-dump> + +This options enables output dump that is suitable for a developer to help debug +B<llvm-cov> itself. + +=back + +=head1 EXIT STATUS + +B<llvm-cov> returns 1 if it cannot read input files. Otherwise, it exits with zero. + +=head1 AUTHOR + +B<llvm-cov> is maintained by the LLVM Team (L<http://llvm.org/>). + +=cut diff --git a/docs/ExceptionHandling.html b/docs/ExceptionHandling.html index b378deb..42881f5 100644 --- a/docs/ExceptionHandling.html +++ b/docs/ExceptionHandling.html @@ -38,7 +38,6 @@ <li><a href="#llvm_eh_sjlj_longjmp"><tt>llvm.eh.sjlj.longjmp</tt></a></li> <li><a href="#llvm_eh_sjlj_lsda"><tt>llvm.eh.sjlj.lsda</tt></a></li> <li><a href="#llvm_eh_sjlj_callsite"><tt>llvm.eh.sjlj.callsite</tt></a></li> - <li><a href="#llvm_eh_sjlj_dispatchsetup"><tt>llvm.eh.sjlj.dispatchsetup</tt></a></li> </ol></li> <li><a href="#asm">Asm Table Formats</a> <ol> @@ -50,7 +49,7 @@ </tr></table> <div class="doc_author"> - <p>Written by <a href="mailto:jlaskey@mac.com">Jim Laskey</a></p> + <p>Written by the <a href="http://llvm.org/">LLVM Team</a></p> </div> @@ -499,25 +498,6 @@ </div> <!-- ======================================================================= --> -<h4> - <a name="llvm_eh_sjlj_dispatchsetup">llvm.eh.sjlj.dispatchsetup</a> -</h4> - -<div> - -<pre> - void @llvm.eh.sjlj.dispatchsetup(i32 %dispatch_value) -</pre> - -<p>For SJLJ based exception handling, the <tt>llvm.eh.sjlj.dispatchsetup</tt> - intrinsic is used by targets to do any unwind edge setup they need. By - default, no action is taken.</p> - -</div> - -</div> - -<!-- ======================================================================= --> <h2> <a name="asm">Asm Table Formats</a> </h2> @@ -573,7 +553,6 @@ <a href="http://validator.w3.org/check/referer"><img src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a> - <a href="mailto:sabre@nondot.org">Chris Lattner</a><br> <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br> Last modified: $Date$ </address> diff --git a/docs/LLVMBuild.html b/docs/LLVMBuild.html index 2f06e30..b069467 100644 --- a/docs/LLVMBuild.html +++ b/docs/LLVMBuild.html @@ -147,7 +147,7 @@ $ROOT of project trees for things which can be checked out separately. --> <i>; Comments start with a semi-colon.</i> <i>; Sections are declared using square brackets.</i> -[component 0] +[component_0] <i>; Properties are declared using '=' and are contained in the previous section. ; @@ -160,7 +160,7 @@ boolean_property_name = 1 <em>(or 0)</em> </pre> </div> - <p>LLVMBuild files are expected to define a strict set of section and + <p>LLVMBuild files are expected to define a strict set of sections and properties. An typical component description file for a library component would look typically look like the following example:</p> <div class="doc_code"> @@ -176,14 +176,22 @@ required_libraries = Archive BitReader Core Support TransformUtils <p>A full description of the exact sections and properties which are allowed follows.</p> + <p>Each file may define exactly one common component, named "common". The + common component may define the following properties:</p> + <ul> + <li><i>subdirectories</i> <b>[optional]</b> + <p>If given, a list of the names of the subdirectories from the current + subpath to search for additional LLVMBuild files.</p></li> + </ul> + <p>Each file may define multiple components. Each component is described by a section who name starts with "component". The remainder of the section name is ignored, but each section name must be unique. Typically components are just number in order for files with multiple components ("component_0", "component_1", and so on).<p> - <p><b>Section names not matches this format are currently - unused and are disallowed.</b></p> + <p><b>Section names not matches this format (or the "common" section) are + currently unused and are disallowed.</b></p> <p>Every component is defined by the properties in the section. The exact list of properties that are allowed depends on the component diff --git a/docs/LLVMBuild.txt b/docs/LLVMBuild.txt index 581d7dd..d5aea86 100644 --- a/docs/LLVMBuild.txt +++ b/docs/LLVMBuild.txt @@ -19,4 +19,3 @@ type = Group name = Docs parent = $ROOT - diff --git a/docs/LangRef.html b/docs/LangRef.html index a9ec800..90308a4 100644 --- a/docs/LangRef.html +++ b/docs/LangRef.html @@ -92,7 +92,7 @@ <li><a href="#complexconstants">Complex Constants</a></li> <li><a href="#globalconstants">Global Variable and Function Addresses</a></li> <li><a href="#undefvalues">Undefined Values</a></li> - <li><a href="#trapvalues">Trap Values</a></li> + <li><a href="#poisonvalues">Poison Values</a></li> <li><a href="#blockaddress">Addresses of Basic Blocks</a></li> <li><a href="#constantexprs">Constant Expressions</a></li> </ol> @@ -288,10 +288,10 @@ </li> <li><a href="#int_memorymarkers">Memory Use Markers</a> <ol> - <li><a href="#int_lifetime_start"><tt>llvm.lifetime.start</tt></a></li> - <li><a href="#int_lifetime_end"><tt>llvm.lifetime.end</tt></a></li> - <li><a href="#int_invariant_start"><tt>llvm.invariant.start</tt></a></li> - <li><a href="#int_invariant_end"><tt>llvm.invariant.end</tt></a></li> + <li><a href="#int_lifetime_start">'<tt>llvm.lifetime.start</tt>' Intrinsic</a></li> + <li><a href="#int_lifetime_end">'<tt>llvm.lifetime.end</tt>' Intrinsic</a></li> + <li><a href="#int_invariant_start">'<tt>llvm.invariant.start</tt>' Intrinsic</a></li> + <li><a href="#int_invariant_end">'<tt>llvm.invariant.end</tt>' Intrinsic</a></li> </ol> </li> <li><a href="#int_general">General intrinsics</a> @@ -306,6 +306,8 @@ '<tt>llvm.stackprotector</tt>' Intrinsic</a></li> <li><a href="#int_objectsize"> '<tt>llvm.objectsize</tt>' Intrinsic</a></li> + <li><a href="#int_expect"> + '<tt>llvm.expect</tt>' Intrinsic</a></li> </ol> </li> </ol> @@ -1214,6 +1216,12 @@ define void @f() optsize { ... } exception by calling the <tt>C++</tt> exception throwing methods, but may use the <tt>unwind</tt> instruction.</dd> + <dt><tt><b><a name="returns_twice">returns_twice</a></b></tt></dt> + <dd>This attribute indicates that this function can return twice. The + C <code>setjmp</code> is an example of such a function. The compiler + disables some optimizations (like tail calls) in the caller of these + functions.</dd> + <dt><tt><b><a name="ssp">ssp</a></b></tt></dt> <dd>This attribute indicates that the function should emit a stack smashing protector. It is in the form of a "canary"—a random value placed on @@ -1241,12 +1249,6 @@ define void @f() optsize { ... } show that no exceptions passes by it. This is normally the case for the ELF x86-64 abi, but it can be disabled for some compilation units.</dd> - - <dt><tt><b><a name="returns_twice">returns_twice</a></b></tt></dt> - <dd>This attribute indicates that this function can return - twice. The C <code>setjmp</code> is an example of such a function. - The compiler disables some optimizations (like tail calls) in the caller of - these functions.</dd> </dl> </div> @@ -1911,9 +1913,9 @@ in signal handlers).</p> <div> <p>Aggregate Types are a subset of derived types that can contain multiple - member types. <a href="#t_array">Arrays</a>, - <a href="#t_struct">structs</a>, and <a href="#t_vector">vectors</a> are - aggregate types.</p> + member types. <a href="#t_array">Arrays</a> and + <a href="#t_struct">structs</a> are aggregate types. + <a href="#t_vector">Vectors</a> are not considered to be aggregate types.</p> </div> @@ -2187,8 +2189,8 @@ in signal handlers).</p> </pre> <p>The number of elements is a constant integer value larger than 0; elementtype - may be any integer or floating point type. Vectors of size zero are not - allowed, and pointers are not allowed as the element type.</p> + may be any integer or floating point type, or a pointer to these types. + Vectors of size zero are not allowed. </p> <h5>Examples:</h5> <table class="layout"> @@ -2204,6 +2206,10 @@ in signal handlers).</p> <td class="left"><tt><2 x i64></tt></td> <td class="left">Vector of 2 64-bit integer values.</td> </tr> + <tr class="layout"> + <td class="left"><tt><4 x i64*></tt></td> + <td class="left">Vector of 4 pointers to 64-bit integer values.</td> + </tr> </table> </div> @@ -2500,22 +2506,21 @@ b: unreachable <!-- ======================================================================= --> <h3> - <a name="trapvalues">Trap Values</a> + <a name="poisonvalues">Poison Values</a> </h3> <div> -<p>Trap values are similar to <a href="#undefvalues">undef values</a>, however - instead of representing an unspecified bit pattern, they represent the - fact that an instruction or constant expression which cannot evoke side - effects has nevertheless detected a condition which results in undefined - behavior.</p> +<p>Poison values are similar to <a href="#undefvalues">undef values</a>, however + they also represent the fact that an instruction or constant expression which + cannot evoke side effects has nevertheless detected a condition which results + in undefined behavior.</p> -<p>There is currently no way of representing a trap value in the IR; they +<p>There is currently no way of representing a poison value in the IR; they only exist when produced by operations such as <a href="#i_add"><tt>add</tt></a> with the <tt>nsw</tt> flag.</p> -<p>Trap value behavior is defined in terms of value <i>dependence</i>:</p> +<p>Poison value behavior is defined in terms of value <i>dependence</i>:</p> <ul> <li>Values other than <a href="#i_phi"><tt>phi</tt></a> nodes depend on @@ -2566,62 +2571,61 @@ b: unreachable </ul> -<p>Whenever a trap value is generated, all values which depend on it evaluate - to trap. If they have side effects, they evoke their side effects as if each - operand with a trap value were undef. If they have externally-visible side - effects, the behavior is undefined.</p> +<p>Poison Values have the same behavior as <a href="#undefvalues">undef values</a>, + with the additional affect that any instruction which has a <i>dependence</i> + on a poison value has undefined behavior.</p> <p>Here are some examples:</p> <pre class="doc_code"> entry: - %trap = sub nuw i32 0, 1 ; Results in a trap value. - %still_trap = and i32 %trap, 0 ; Whereas (and i32 undef, 0) would return 0. - %trap_yet_again = getelementptr i32* @h, i32 %still_trap - store i32 0, i32* %trap_yet_again ; undefined behavior + %poison = sub nuw i32 0, 1 ; Results in a poison value. + %still_poison = and i32 %poison, 0 ; 0, but also poison. + %poison_yet_again = getelementptr i32* @h, i32 %still_poison + store i32 0, i32* %poison_yet_again ; memory at @h[0] is poisoned - store i32 %trap, i32* @g ; Trap value conceptually stored to memory. - %trap2 = load i32* @g ; Returns a trap value, not just undef. + store i32 %poison, i32* @g ; Poison value stored to memory. + %poison2 = load i32* @g ; Poison value loaded back from memory. - volatile store i32 %trap, i32* @g ; External observation; undefined behavior. + store volatile i32 %poison, i32* @g ; External observation; undefined behavior. %narrowaddr = bitcast i32* @g to i16* %wideaddr = bitcast i32* @g to i64* - %trap3 = load i16* %narrowaddr ; Returns a trap value. - %trap4 = load i64* %wideaddr ; Returns a trap value. + %poison3 = load i16* %narrowaddr ; Returns a poison value. + %poison4 = load i64* %wideaddr ; Returns a poison value. - %cmp = icmp slt i32 %trap, 0 ; Returns a trap value. - br i1 %cmp, label %true, label %end ; Branch to either destination. + %cmp = icmp slt i32 %poison, 0 ; Returns a poison value. + br i1 %cmp, label %true, label %end ; Branch to either destination. true: - volatile store i32 0, i32* @g ; This is control-dependent on %cmp, so - ; it has undefined behavior. + store volatile i32 0, i32* @g ; This is control-dependent on %cmp, so + ; it has undefined behavior. br label %end end: %p = phi i32 [ 0, %entry ], [ 1, %true ] - ; Both edges into this PHI are - ; control-dependent on %cmp, so this - ; always results in a trap value. + ; Both edges into this PHI are + ; control-dependent on %cmp, so this + ; always results in a poison value. - volatile store i32 0, i32* @g ; This would depend on the store in %true - ; if %cmp is true, or the store in %entry - ; otherwise, so this is undefined behavior. + store volatile i32 0, i32* @g ; This would depend on the store in %true + ; if %cmp is true, or the store in %entry + ; otherwise, so this is undefined behavior. br i1 %cmp, label %second_true, label %second_end - ; The same branch again, but this time the - ; true block doesn't have side effects. + ; The same branch again, but this time the + ; true block doesn't have side effects. second_true: ; No side effects! ret void second_end: - volatile store i32 0, i32* @g ; This time, the instruction always depends - ; on the store in %end. Also, it is - ; control-equivalent to %end, so this is - ; well-defined (again, ignoring earlier - ; undefined behavior in this example). + store volatile i32 0, i32* @g ; This time, the instruction always depends + ; on the store in %end. Also, it is + ; control-equivalent to %end, so this is + ; well-defined (ignoring earlier undefined + ; behavior in this example). </pre> </div> @@ -2800,7 +2804,7 @@ second_end: <div> <p>LLVM supports inline assembler expressions (as opposed - to <a href="#moduleasm"> Module-Level Inline Assembly</a>) through the use of + to <a href="#moduleasm">Module-Level Inline Assembly</a>) through the use of a special value. This value represents the inline assembler as a string (containing the instructions to emit), a list of operand constraints (stored as a string), a flag that indicates whether or not the inline asm @@ -2842,23 +2846,27 @@ call void asm alignstack "eieio", ""() <p>If both keywords appear the '<tt>sideeffect</tt>' keyword must come first.</p> +<!-- <p>TODO: The format of the asm and constraints string still need to be documented here. Constraints on what can be done (e.g. duplication, moving, etc need to be documented). This is probably best done by reference to another document that covers inline asm from a holistic perspective.</p> + --> +<!-- _______________________________________________________________________ --> <h4> -<a name="inlineasm_md">Inline Asm Metadata</a> + <a name="inlineasm_md">Inline Asm Metadata</a> </h4> <div> -<p>The call instructions that wrap inline asm nodes may have a "!srcloc" MDNode - attached to it that contains a list of constant integers. If present, the - code generator will use the integer as the location cookie value when report - errors through the LLVMContext error reporting mechanisms. This allows a - front-end to correlate backend errors that occur with inline asm back to the - source code that produced it. For example:</p> +<p>The call instructions that wrap inline asm nodes may have a + "<tt>!srcloc</tt>" MDNode attached to it that contains a list of constant + integers. If present, the code generator will use the integer as the + location cookie value when report errors through the <tt>LLVMContext</tt> + error reporting mechanisms. This allows a front-end to correlate backend + errors that occur with inline asm back to the source code that produced it. + For example:</p> <pre class="doc_code"> call void asm sideeffect "something bad", ""()<b>, !srcloc !42</b> @@ -2867,7 +2875,7 @@ call void asm sideeffect "something bad", ""()<b>, !srcloc !42</b> </pre> <p>It is up to the front-end to make sense of the magic numbers it places in the - IR. If the MDNode contains multiple constants, the code generator will use + IR. If the MDNode contains multiple constants, the code generator will use the one that corresponds to the line of the asm that the error occurs on.</p> </div> @@ -2889,20 +2897,33 @@ call void asm sideeffect "something bad", ""()<b>, !srcloc !42</b> preceding exclamation point ('<tt>!</tt>').</p> <p>A metadata string is a string surrounded by double quotes. It can contain - any character by escaping non-printable characters with "\xx" where "xx" is - the two digit hex code. For example: "<tt>!"test\00"</tt>".</p> + any character by escaping non-printable characters with "<tt>\xx</tt>" where + "<tt>xx</tt>" is the two digit hex code. For example: + "<tt>!"test\00"</tt>".</p> <p>Metadata nodes are represented with notation similar to structure constants (a comma separated list of elements, surrounded by braces and preceded by an - exclamation point). For example: "<tt>!{ metadata !"test\00", i32 - 10}</tt>". Metadata nodes can have any values as their operand.</p> + exclamation point). Metadata nodes can have any values as their operand. For + example:</p> + +<div class="doc_code"> +<pre> +!{ metadata !"test\00", i32 10} +</pre> +</div> <p>A <a href="#namedmetadatastructure">named metadata</a> is a collection of metadata nodes, which can be looked up in the module symbol table. For - example: "<tt>!foo = metadata !{!4, !3}</tt>". + example:</p> + +<div class="doc_code"> +<pre> +!foo = metadata !{!4, !3} +</pre> +</div> <p>Metadata can be used as function arguments. Here <tt>llvm.dbg.value</tt> - function is using two metadata arguments.</p> + function is using two metadata arguments:</p> <div class="doc_code"> <pre> @@ -2911,7 +2932,8 @@ call void @llvm.dbg.value(metadata !24, i64 0, metadata !25) </div> <p>Metadata can be attached with an instruction. Here metadata <tt>!21</tt> is - attached with <tt>add</tt> instruction using <tt>!dbg</tt> identifier.</p> + attached to the <tt>add</tt> instruction using the <tt>!dbg</tt> + identifier:</p> <div class="doc_code"> <pre> @@ -2922,6 +2944,7 @@ call void @llvm.dbg.value(metadata !24, i64 0, metadata !25) <p>More information about specific metadata nodes recognized by the optimizers and code generator is found below.</p> +<!-- _______________________________________________________________________ --> <h4> <a name="tbaa">'<tt>tbaa</tt>' Metadata</a> </h4> @@ -2966,6 +2989,7 @@ call void @llvm.dbg.value(metadata !24, i64 0, metadata !25) </div> +<!-- _______________________________________________________________________ --> <h4> <a name="fpaccuracy">'<tt>fpaccuracy</tt>' Metadata</a> </h4> @@ -3378,7 +3402,7 @@ IfUnequal: <i><a href="ExceptionHandling.html#overview">landing pad</a></i> for the exception. As such, '<tt>exception</tt>' label is required to have the "<a href="#i_landingpad"><tt>landingpad</tt></a>" instruction, which contains - the information about about the behavior of the program after unwinding + the information about the behavior of the program after unwinding happens, as its first non-PHI instruction. The restrictions on the "<tt>landingpad</tt>" instruction's tightly couples it to the "<tt>invoke</tt>" instruction, so that the important information contained @@ -3593,7 +3617,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <p><tt>nuw</tt> and <tt>nsw</tt> stand for "No Unsigned Wrap" and "No Signed Wrap", respectively. If the <tt>nuw</tt> and/or <tt>nsw</tt> keywords are present, the result value of the <tt>add</tt> - is a <a href="#trapvalues">trap value</a> if unsigned and/or signed overflow, + is a <a href="#poisonvalues">poison value</a> if unsigned and/or signed overflow, respectively, occurs.</p> <h5>Example:</h5> @@ -3674,7 +3698,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <p><tt>nuw</tt> and <tt>nsw</tt> stand for "No Unsigned Wrap" and "No Signed Wrap", respectively. If the <tt>nuw</tt> and/or <tt>nsw</tt> keywords are present, the result value of the <tt>sub</tt> - is a <a href="#trapvalues">trap value</a> if unsigned and/or signed overflow, + is a <a href="#poisonvalues">poison value</a> if unsigned and/or signed overflow, respectively, occurs.</p> <h5>Example:</h5> @@ -3761,7 +3785,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <p><tt>nuw</tt> and <tt>nsw</tt> stand for "No Unsigned Wrap" and "No Signed Wrap", respectively. If the <tt>nuw</tt> and/or <tt>nsw</tt> keywords are present, the result value of the <tt>mul</tt> - is a <a href="#trapvalues">trap value</a> if unsigned and/or signed overflow, + is a <a href="#poisonvalues">poison value</a> if unsigned and/or signed overflow, respectively, occurs.</p> <h5>Example:</h5> @@ -3831,7 +3855,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <p>Division by zero leads to undefined behavior.</p> <p>If the <tt>exact</tt> keyword is present, the result value of the - <tt>udiv</tt> is a <a href="#trapvalues">trap value</a> if %op1 is not a + <tt>udiv</tt> is a <a href="#poisonvalues">poison value</a> if %op1 is not a multiple of %op2 (as such, "((a udiv exact b) mul b) == a").</p> @@ -3875,7 +3899,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> a 32-bit division of -2147483648 by -1.</p> <p>If the <tt>exact</tt> keyword is present, the result value of the - <tt>sdiv</tt> is a <a href="#trapvalues">trap value</a> if the result would + <tt>sdiv</tt> is a <a href="#poisonvalues">poison value</a> if the result would be rounded.</p> <h5>Example:</h5> @@ -4084,9 +4108,9 @@ that the invoke/unwind semantics are likely to change in future versions.</p> shift amount in <tt>op2</tt>.</p> <p>If the <tt>nuw</tt> keyword is present, then the shift produces a - <a href="#trapvalues">trap value</a> if it shifts out any non-zero bits. If + <a href="#poisonvalues">poison value</a> if it shifts out any non-zero bits. If the <tt>nsw</tt> keyword is present, then the shift produces a - <a href="#trapvalues">trap value</a> if it shifts out any bits that disagree + <a href="#poisonvalues">poison value</a> if it shifts out any bits that disagree with the resultant sign bit. As such, NUW/NSW have the same semantics as they would if the shift were expressed as a mul instruction with the same nsw/nuw bits in (mul %op1, (shl 1, %op2)).</p> @@ -4133,7 +4157,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> shift amount in <tt>op2</tt>.</p> <p>If the <tt>exact</tt> keyword is present, the result value of the - <tt>lshr</tt> is a <a href="#trapvalues">trap value</a> if any of the bits + <tt>lshr</tt> is a <a href="#poisonvalues">poison value</a> if any of the bits shifted out are non-zero.</p> @@ -4181,7 +4205,7 @@ that the invoke/unwind semantics are likely to change in future versions.</p> the corresponding shift amount in <tt>op2</tt>.</p> <p>If the <tt>exact</tt> keyword is present, the result value of the - <tt>ashr</tt> is a <a href="#trapvalues">trap value</a> if any of the bits + <tt>ashr</tt> is a <a href="#poisonvalues">poison value</a> if any of the bits shifted out are non-zero.</p> <h5>Example:</h5> @@ -4223,9 +4247,9 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <table border="1" cellspacing="0" cellpadding="4"> <tbody> <tr> - <td>In0</td> - <td>In1</td> - <td>Out</td> + <th>In0</th> + <th>In1</th> + <th>Out</th> </tr> <tr> <td>0</td> @@ -4284,9 +4308,9 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <table border="1" cellspacing="0" cellpadding="4"> <tbody> <tr> - <td>In0</td> - <td>In1</td> - <td>Out</td> + <th>In0</th> + <th>In1</th> + <th>Out</th> </tr> <tr> <td>0</td> @@ -4348,9 +4372,9 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <table border="1" cellspacing="0" cellpadding="4"> <tbody> <tr> - <td>In0</td> - <td>In1</td> - <td>Out</td> + <th>In0</th> + <th>In1</th> + <th>Out</th> </tr> <tr> <td>0</td> @@ -4761,8 +4785,8 @@ that the invoke/unwind semantics are likely to change in future versions.</p> <h5>Syntax:</h5> <pre> - store [volatile] <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] <i>; yields {void}</i> - store atomic [volatile] <ty> <value>, <ty>* <pointer> [singlethread] <ordering>, align <alignment> <i>; yields {void}</i> + store [volatile] <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] <i>; yields {void}</i> + store atomic [volatile] <ty> <value>, <ty>* <pointer> [singlethread] <ordering>, align <alignment> <i>; yields {void}</i> </pre> <h5>Overview:</h5> @@ -4891,7 +4915,7 @@ thread. (This is useful for interacting with signal handlers.)</p> <h5>Syntax:</h5> <pre> - cmpxchg [volatile] <ty>* <pointer>, <ty> <cmp>, <ty> <new> [singlethread] <ordering> <i>; yields {ty}</i> + cmpxchg [volatile] <ty>* <pointer>, <ty> <cmp>, <ty> <new> [singlethread] <ordering> <i>; yields {ty}</i> </pre> <h5>Overview:</h5> @@ -4949,13 +4973,13 @@ FIXME: Is a weaker ordering constraint on failure helpful in practice? <h5>Example:</h5> <pre> entry: - %orig = atomic <a href="#i_load">load</a> i32* %ptr unordered <i>; yields {i32}</i> + %orig = atomic <a href="#i_load">load</a> i32* %ptr unordered <i>; yields {i32}</i> <a href="#i_br">br</a> label %loop loop: %cmp = <a href="#i_phi">phi</a> i32 [ %orig, %entry ], [%old, %loop] %squared = <a href="#i_mul">mul</a> i32 %cmp, %cmp - %old = cmpxchg i32* %ptr, i32 %cmp, i32 %squared <i>; yields {i32}</i> + %old = cmpxchg i32* %ptr, i32 %cmp, i32 %squared <i>; yields {i32}</i> %success = <a href="#i_icmp">icmp</a> eq i32 %cmp, %old <a href="#i_br">br</a> i1 %success, label %done, label %loop @@ -5047,6 +5071,7 @@ specified by the <var>operation</var> argument:</p> <pre> <result> = getelementptr <pty>* <ptrval>{, <ty> <idx>}* <result> = getelementptr inbounds <pty>* <ptrval>{, <ty> <idx>}* + <result> = getelementptr <ptr vector> ptrval, <vector index type> idx </pre> <h5>Overview:</h5> @@ -5055,7 +5080,8 @@ specified by the <var>operation</var> argument:</p> It performs address calculation only and does not access memory.</p> <h5>Arguments:</h5> -<p>The first argument is always a pointer, and forms the basis of the +<p>The first argument is always a pointer or a vector of pointers, + and forms the basis of the calculation. The remaining arguments are indices that indicate which of the elements of the aggregate object are indexed. The interpretation of each index is dependent on the type being indexed into. The first index always @@ -5093,54 +5119,57 @@ int *foo(struct ST *s) { } </pre> -<p>The LLVM code generated by the GCC frontend is:</p> +<p>The LLVM code generated by Clang is:</p> <pre class="doc_code"> -%RT = <a href="#namedtypes">type</a> { i8 , [10 x [20 x i32]], i8 } -%ST = <a href="#namedtypes">type</a> { i32, double, %RT } +%struct.RT = <a href="#namedtypes">type</a> { i8, [10 x [20 x i32]], i8 } +%struct.ST = <a href="#namedtypes">type</a> { i32, double, %struct.RT } -define i32* @foo(%ST* %s) { +define i32* @foo(%struct.ST* %s) nounwind uwtable readnone optsize ssp { entry: - %reg = getelementptr %ST* %s, i32 1, i32 2, i32 1, i32 5, i32 13 - ret i32* %reg + %arrayidx = getelementptr inbounds %struct.ST* %s, i64 1, i32 2, i32 1, i64 5, i64 13 + ret i32* %arrayidx } </pre> <h5>Semantics:</h5> -<p>In the example above, the first index is indexing into the '<tt>%ST*</tt>' - type, which is a pointer, yielding a '<tt>%ST</tt>' = '<tt>{ i32, double, %RT - }</tt>' type, a structure. The second index indexes into the third element - of the structure, yielding a '<tt>%RT</tt>' = '<tt>{ i8 , [10 x [20 x i32]], - i8 }</tt>' type, another structure. The third index indexes into the second - element of the structure, yielding a '<tt>[10 x [20 x i32]]</tt>' type, an - array. The two dimensions of the array are subscripted into, yielding an - '<tt>i32</tt>' type. The '<tt>getelementptr</tt>' instruction returns a - pointer to this element, thus computing a value of '<tt>i32*</tt>' type.</p> +<p>In the example above, the first index is indexing into the + '<tt>%struct.ST*</tt>' type, which is a pointer, yielding a + '<tt>%struct.ST</tt>' = '<tt>{ i32, double, %struct.RT }</tt>' type, a + structure. The second index indexes into the third element of the structure, + yielding a '<tt>%struct.RT</tt>' = '<tt>{ i8 , [10 x [20 x i32]], i8 }</tt>' + type, another structure. The third index indexes into the second element of + the structure, yielding a '<tt>[10 x [20 x i32]]</tt>' type, an array. The + two dimensions of the array are subscripted into, yielding an '<tt>i32</tt>' + type. The '<tt>getelementptr</tt>' instruction returns a pointer to this + element, thus computing a value of '<tt>i32*</tt>' type.</p> <p>Note that it is perfectly legal to index partially through a structure, returning a pointer to an inner element. Because of this, the LLVM code for the given testcase is equivalent to:</p> -<pre> - define i32* @foo(%ST* %s) { - %t1 = getelementptr %ST* %s, i32 1 <i>; yields %ST*:%t1</i> - %t2 = getelementptr %ST* %t1, i32 0, i32 2 <i>; yields %RT*:%t2</i> - %t3 = getelementptr %RT* %t2, i32 0, i32 1 <i>; yields [10 x [20 x i32]]*:%t3</i> - %t4 = getelementptr [10 x [20 x i32]]* %t3, i32 0, i32 5 <i>; yields [20 x i32]*:%t4</i> - %t5 = getelementptr [20 x i32]* %t4, i32 0, i32 13 <i>; yields i32*:%t5</i> - ret i32* %t5 - } +<pre class="doc_code"> +define i32* @foo(%struct.ST* %s) { + %t1 = getelementptr %struct.ST* %s, i32 1 <i>; yields %struct.ST*:%t1</i> + %t2 = getelementptr %struct.ST* %t1, i32 0, i32 2 <i>; yields %struct.RT*:%t2</i> + %t3 = getelementptr %struct.RT* %t2, i32 0, i32 1 <i>; yields [10 x [20 x i32]]*:%t3</i> + %t4 = getelementptr [10 x [20 x i32]]* %t3, i32 0, i32 5 <i>; yields [20 x i32]*:%t4</i> + %t5 = getelementptr [20 x i32]* %t4, i32 0, i32 13 <i>; yields i32*:%t5</i> + ret i32* %t5 +} </pre> <p>If the <tt>inbounds</tt> keyword is present, the result value of the - <tt>getelementptr</tt> is a <a href="#trapvalues">trap value</a> if the + <tt>getelementptr</tt> is a <a href="#poisonvalues">poison value</a> if the base pointer is not an <i>in bounds</i> address of an allocated object, or if any of the addresses that would be formed by successive addition of the offsets implied by the indices to the base address with infinitely precise signed arithmetic are not an <i>in bounds</i> address of that allocated object. The <i>in bounds</i> addresses for an allocated object are all the addresses that point into the object, plus the address one - byte past the end.</p> + byte past the end. + In cases where the base is a vector of pointers the <tt>inbounds</tt> keyword + applies to each of the computations element-wise. </p> <p>If the <tt>inbounds</tt> keyword is not present, the offsets are added to the base address with silently-wrapping two's complement arithmetic. If the @@ -5167,6 +5196,13 @@ entry: %iptr = getelementptr [10 x i32]* @arr, i16 0, i16 0 </pre> +<p>In cases where the pointer argument is a vector of pointers, only a + single index may be used, and the number of vector elements has to be + the same. For example: </p> +<pre class="doc_code"> + %A = getelementptr <4 x i8*> %ptrs, <4 x i64> %offsets, +</pre> + </div> </div> @@ -5539,13 +5575,16 @@ entry: </pre> <h5>Overview:</h5> -<p>The '<tt>ptrtoint</tt>' instruction converts the pointer <tt>value</tt> to - the integer type <tt>ty2</tt>.</p> +<p>The '<tt>ptrtoint</tt>' instruction converts the pointer or a vector of + pointers <tt>value</tt> to + the integer (or vector of integers) type <tt>ty2</tt>.</p> <h5>Arguments:</h5> <p>The '<tt>ptrtoint</tt>' instruction takes a <tt>value</tt> to cast, which - must be a <a href="#t_pointer">pointer</a> value, and a type to cast it to - <tt>ty2</tt>, which must be an <a href="#t_integer">integer</a> type.</p> + must be a a value of type <a href="#t_pointer">pointer</a> or a vector of + pointers, and a type to cast it to + <tt>ty2</tt>, which must be an <a href="#t_integer">integer</a> or a vector + of integers type.</p> <h5>Semantics:</h5> <p>The '<tt>ptrtoint</tt>' instruction converts <tt>value</tt> to integer type @@ -5558,8 +5597,9 @@ entry: <h5>Example:</h5> <pre> - %X = ptrtoint i32* %X to i8 <i>; yields truncation on 32-bit architecture</i> - %Y = ptrtoint i32* %x to i64 <i>; yields zero extension on 32-bit architecture</i> + %X = ptrtoint i32* %P to i8 <i>; yields truncation on 32-bit architecture</i> + %Y = ptrtoint i32* %P to i64 <i>; yields zero extension on 32-bit architecture</i> + %Z = ptrtoint <4 x i32*> %P to <4 x i64><i>; yields vector zero extension for a vector of addresses on 32-bit architecture</i> </pre> </div> @@ -5598,6 +5638,7 @@ entry: %X = inttoptr i32 255 to i32* <i>; yields zero extension on 64-bit architecture</i> %Y = inttoptr i32 255 to i32* <i>; yields no-op on 32-bit architecture</i> %Z = inttoptr i64 0 to i32* <i>; yields truncation on 32-bit architecture</i> + %Z = inttoptr <4 x i32> %G to <4 x i8*><i>; yields truncation of vector G to four pointers</i> </pre> </div> @@ -5632,8 +5673,9 @@ entry: <p>The '<tt>bitcast</tt>' instruction converts <tt>value</tt> to type <tt>ty2</tt>. It is always a <i>no-op cast</i> because no bits change with this conversion. The conversion is done as if the <tt>value</tt> had been - stored to memory and read back as type <tt>ty2</tt>. Pointer types may only - be converted to other pointer types with this instruction. To convert + stored to memory and read back as type <tt>ty2</tt>. + Pointer (or vector of pointers) types may only be converted to other pointer + (or vector of pointers) types with this instruction. To convert pointers to other types, use the <a href="#i_inttoptr">inttoptr</a> or <a href="#i_ptrtoint">ptrtoint</a> instructions first.</p> @@ -5641,7 +5683,8 @@ entry: <pre> %X = bitcast i8 255 to i8 <i>; yields i8 :-1</i> %Y = bitcast i32* %x to sint* <i>; yields sint*:%x</i> - %Z = bitcast <2 x int> %V to i64; <i>; yields i64: %V</i> + %Z = bitcast <2 x int> %V to i64; <i>; yields i64: %V</i> + %Z = bitcast <2 x i32*> %V to <2 x i64*> <i>; yields <2 x i64*></i> </pre> </div> @@ -5672,8 +5715,8 @@ entry: <h5>Overview:</h5> <p>The '<tt>icmp</tt>' instruction returns a boolean value or a vector of - boolean values based on comparison of its two integer, integer vector, or - pointer operands.</p> + boolean values based on comparison of its two integer, integer vector, + pointer, or pointer vector operands.</p> <h5>Arguments:</h5> <p>The '<tt>icmp</tt>' instruction takes three operands. The first operand is @@ -7293,12 +7336,12 @@ LLVM</a>.</p> targets support all bit widths or vector types, however.</p> <pre> - declare i8 @llvm.ctlz.i8 (i8 <src>) - declare i16 @llvm.ctlz.i16(i16 <src>) - declare i32 @llvm.ctlz.i32(i32 <src>) - declare i64 @llvm.ctlz.i64(i64 <src>) - declare i256 @llvm.ctlz.i256(i256 <src>) - declare <2 x i32> @llvm.ctlz.v2i32(<2 x i32> <src;gt) + declare i8 @llvm.ctlz.i8 (i8 <src>, i1 <is_zero_undef>) + declare i16 @llvm.ctlz.i16 (i16 <src>, i1 <is_zero_undef>) + declare i32 @llvm.ctlz.i32 (i32 <src>, i1 <is_zero_undef>) + declare i64 @llvm.ctlz.i64 (i64 <src>, i1 <is_zero_undef>) + declare i256 @llvm.ctlz.i256(i256 <src>, i1 <is_zero_undef>) + declase <2 x i32> @llvm.ctlz.v2i32(<2 x i32> <src>, i1 <is_zero_undef>) </pre> <h5>Overview:</h5> @@ -7306,15 +7349,22 @@ LLVM</a>.</p> leading zeros in a variable.</p> <h5>Arguments:</h5> -<p>The only argument is the value to be counted. The argument may be of any - integer type, or any vector type with integer element type. - The return type must match the argument type.</p> +<p>The first argument is the value to be counted. This argument may be of any + integer type, or a vectory with integer element type. The return type + must match the first argument type.</p> + +<p>The second argument must be a constant and is a flag to indicate whether the + intrinsic should ensure that a zero as the first argument produces a defined + result. Historically some architectures did not provide a defined result for + zero values as efficiently, and many algorithms are now predicated on + avoiding zero-value inputs.</p> <h5>Semantics:</h5> <p>The '<tt>llvm.ctlz</tt>' intrinsic counts the leading (most significant) - zeros in a variable, or within each element of the vector if the operation - is of vector type. If the src == 0 then the result is the size in bits of - the type of src. For example, <tt>llvm.ctlz(i32 2) = 30</tt>.</p> + zeros in a variable, or within each element of the vector. + If <tt>src == 0</tt> then the result is the size in bits of the type of + <tt>src</tt> if <tt>is_zero_undef == 0</tt> and <tt>undef</tt> otherwise. + For example, <tt>llvm.ctlz(i32 2) = 30</tt>.</p> </div> @@ -7331,12 +7381,12 @@ LLVM</a>.</p> support all bit widths or vector types, however.</p> <pre> - declare i8 @llvm.cttz.i8 (i8 <src>) - declare i16 @llvm.cttz.i16(i16 <src>) - declare i32 @llvm.cttz.i32(i32 <src>) - declare i64 @llvm.cttz.i64(i64 <src>) - declare i256 @llvm.cttz.i256(i256 <src>) - declase <2 x i32> @llvm.cttz.v2i32(<2 x i32> <src>) + declare i8 @llvm.cttz.i8 (i8 <src>, i1 <is_zero_undef>) + declare i16 @llvm.cttz.i16 (i16 <src>, i1 <is_zero_undef>) + declare i32 @llvm.cttz.i32 (i32 <src>, i1 <is_zero_undef>) + declare i64 @llvm.cttz.i64 (i64 <src>, i1 <is_zero_undef>) + declare i256 @llvm.cttz.i256(i256 <src>, i1 <is_zero_undef>) + declase <2 x i32> @llvm.cttz.v2i32(<2 x i32> <src>, i1 <is_zero_undef>) </pre> <h5>Overview:</h5> @@ -7344,15 +7394,22 @@ LLVM</a>.</p> trailing zeros.</p> <h5>Arguments:</h5> -<p>The only argument is the value to be counted. The argument may be of any - integer type, or a vectory with integer element type.. The return type - must match the argument type.</p> +<p>The first argument is the value to be counted. This argument may be of any + integer type, or a vectory with integer element type. The return type + must match the first argument type.</p> + +<p>The second argument must be a constant and is a flag to indicate whether the + intrinsic should ensure that a zero as the first argument produces a defined + result. Historically some architectures did not provide a defined result for + zero values as efficiently, and many algorithms are now predicated on + avoiding zero-value inputs.</p> <h5>Semantics:</h5> <p>The '<tt>llvm.cttz</tt>' intrinsic counts the trailing (least significant) zeros in a variable, or within each element of a vector. - If the src == 0 then the result is the size in bits of - the type of src. For example, <tt>llvm.cttz(2) = 1</tt>.</p> + If <tt>src == 0</tt> then the result is the size in bits of the type of + <tt>src</tt> if <tt>is_zero_undef == 0</tt> and <tt>undef</tt> otherwise. + For example, <tt>llvm.cttz(2) = 1</tt>.</p> </div> @@ -8185,11 +8242,35 @@ LLVM</a>.</p> compile time.</p> </div> +<!-- _______________________________________________________________________ --> +<h4> + <a name="int_expect">'<tt>llvm.expect</tt>' Intrinsic</a> +</h4> +<div> + +<h5>Syntax:</h5> +<pre> + declare i32 @llvm.expect.i32(i32 <val>, i32 <expected_val>) + declare i64 @llvm.expect.i64(i64 <val>, i64 <expected_val>) +</pre> + +<h5>Overview:</h5> +<p>The <tt>llvm.expect</tt> intrinsic provides information about expected (the + most probable) value of <tt>val</tt>, which can be used by optimizers.</p> + +<h5>Arguments:</h5> +<p>The <tt>llvm.expect</tt> intrinsic takes two arguments. The first + argument is a value. The second argument is an expected value, this needs to + be a constant value, variables are not allowed.</p> + +<h5>Semantics:</h5> +<p>This intrinsic is lowered to the <tt>val</tt>.</p> </div> </div> +</div> <!-- *********************************************************************** --> <hr> <address> diff --git a/docs/ReleaseNotes.html b/docs/ReleaseNotes.html index f2d8930..b9361a5 100644 --- a/docs/ReleaseNotes.html +++ b/docs/ReleaseNotes.html @@ -4,20 +4,22 @@ <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <link rel="stylesheet" href="llvm.css" type="text/css"> - <title>LLVM 3.0 Release Notes</title> + <title>LLVM 3.1 Release Notes</title> </head> <body> -<h1>LLVM 3.0 Release Notes</h1> +<h1>LLVM 3.1 Release Notes</h1> -<img align=right src="http://llvm.org/img/DragonSmall.png" - width="136" height="136" alt="LLVM Dragon Logo"> +<div> +<img style="float:right" src="http://llvm.org/img/DragonSmall.png" + width="136" height="136" alt="LLVM Dragon Logo"> +</div> <ol> <li><a href="#intro">Introduction</a></li> <li><a href="#subproj">Sub-project Status Update</a></li> - <li><a href="#externalproj">External Projects Using LLVM 3.0</a></li> - <li><a href="#whatsnew">What's New in LLVM 3.0?</a></li> + <li><a href="#externalproj">External Projects Using LLVM 3.1</a></li> + <li><a href="#whatsnew">What's New in LLVM?</a></li> <li><a href="GettingStarted.html">Installation Instructions</a></li> <li><a href="#knownproblems">Known Problems</a></li> <li><a href="#additionalinfo">Additional Information</a></li> @@ -27,13 +29,11 @@ <p>Written by the <a href="http://llvm.org/">LLVM Team</a></p> </div> -<!-- -<h1 style="color:red">These are in-progress notes for the upcoming LLVM 3.0 +<h1 style="color:red">These are in-progress notes for the upcoming LLVM 3.1 release.<br> You may prefer the -<a href="http://llvm.org/releases/2.9/docs/ReleaseNotes.html">LLVM 2.9 +<a href="http://llvm.org/releases/3.0/docs/ReleaseNotes.html">LLVM 3.0 Release Notes</a>.</h1> - --> <!-- *********************************************************************** --> <h2> @@ -44,8 +44,9 @@ Release Notes</a>.</h1> <div> <p>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. + Infrastructure, release 3.1. Here we describe the status of LLVM, including + major improvements from the previous release, improvements in various + subprojects of LLVM, and some of the current users of the code. All LLVM releases may be downloaded from the <a href="http://llvm.org/releases/">LLVM releases web site</a>.</p> @@ -61,16 +62,8 @@ Release Notes</a>.</h1> <a href="http://llvm.org/releases/">releases page</a>.</p> </div> - -<!-- Features that need text if they're finished for 3.1: - ARM EHABI - combiner-aa? - strong phi elim - loop dependence analysis - CorrelatedValuePropagation - lib/Transforms/IPO/MergeFunctions.cpp => consider for 3.1. - --> - + + <!-- *********************************************************************** --> <h2> <a name="subproj">Sub-project Status Update</a> @@ -79,7 +72,7 @@ Release Notes</a>.</h1> <div> -<p>The LLVM 3.0 distribution currently consists of code from the core LLVM +<p>The LLVM 3.1 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 @@ -99,37 +92,18 @@ Release Notes</a>.</h1> 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.</p> - -<p>In the LLVM 3.0 time-frame, the Clang team has made many improvements:</p> + (32- and 64-bit), and for Darwin/ARM targets.</p> +<p>In the LLVM 3.1 time-frame, the Clang team has made many improvements:</p> <ul> - <li>Greatly improved support for building C++ applications, with greater - stability and better diagnostics.</li> - - <li><a href="http://clang.llvm.org/cxx_status.html">Improved support</a> for - the <a href="http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50372">C++ - 2011</a> 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.</li> - - <li>Implemented support for some features of the upcoming C1x standard, - including static assertions and generic selections.</li> - - <li>Better detection of include and linking paths for system headers and - libraries, especially for Linux distributions.</li> - - <li>Implemented support - for <a href="http://clang.llvm.org/docs/AutomaticReferenceCounting.html">Automatic - Reference Counting</a> for Objective-C.</li> - - <li>Implemented a number of optimizations in <tt>libclang</tt>, the Clang C - interface, to improve the performance of code completion and the mapping - from source locations to abstract syntax tree nodes.</li> + <li>...</li> </ul> - + <p>For more details about the changes to Clang since the 2.9 release, see the +<a href="http://clang.llvm.org/docs/ReleaseNotes.html">Clang release notes</a> +</p> + + <p>If Clang rejects your code but another compiler accepts it, please take a look at the <a href="http://clang.llvm.org/compatibility.html">language compatibility</a> guide to make sure this is not intentional or a known @@ -151,26 +125,12 @@ Release Notes</a>.</h1> supports Ada, C, C++ and Fortran. It has partial support for Go, Java, Obj-C and Obj-C++.</p> -<p>The 3.0 release has the following notable changes:</p> - - <li>GCC version 4.6 is now fully supported.</li> +<p>The 3.1 release has the following notable changes:</p> - <li>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).</li> - - <li>The <tt>-fplugin-arg-dragonegg-enable-gcc-optzns</tt> 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.</li> + <ul> - <li>The type and constant conversion logic has been almost entirely rewritten, - fixing a multitude of obscure bugs.</li> + <li>...</li> -<ul> -<!-- -<li></li> ---> </ul> </div> @@ -191,7 +151,7 @@ Release Notes</a>.</h1> implementations of this and other low-level routines (some are 3x faster than the equivalent libgcc routines).</p> -<p>In the LLVM 3.0 timeframe,</p> +<p>....</p> </div> @@ -202,11 +162,12 @@ Release Notes</a>.</h1> <div> -<p>LLDB has advanced by leaps and bounds in the 3.0 timeframe. It is - dramatically more stable and useful, and includes both a - new <a href="http://lldb.llvm.org/tutorial.html">tutorial</a> and - a <a href="http://lldb.llvm.org/lldb-gdb.html">side-by-side comparison with - GDB</a>.</p> +<p>LLDB is a ground-up implementation of a command line debugger, as well as a + debugger API that can be used from other applications. LLDB makes use of the + Clang parser to provide high-fidelity expression parsing (particularly for + C++) and uses the LLVM JIT for target support.</p> + +<p>...</p> </div> @@ -221,22 +182,7 @@ Release Notes</a>.</h1> licensed</a> under the MIT and UIUC license, allowing it to be used more permissively.</p> -</div> - - -<!--=========================================================================--> -<h3> -<a name="LLBrowse">LLBrowse: IR Browser</a> -</h3> - -<div> - -<p><a href="http://llvm.org/svn/llvm-project/llbrowse/trunk/doc/LLBrowse.html"> - LLBrowse</a> is an interactive viewer for LLVM modules. It can load any LLVM - module and displays its contents as an expandable tree view, facilitating an - easy way to inspect types, functions, global variables, or metadata nodes. It - is fully cross-platform, being based on the popular wxWidgets GUI - toolkit.</p> +<p>...</p> </div> @@ -251,54 +197,20 @@ Release Notes</a>.</h1> implementation of a Java Virtual Machine (Java VM or JVM) that uses LLVM for static and just-in-time compilation. - <p>In the LLVM 3.0 time-frame, VMKit has had significant improvements on both + <p>In the LLVM 3.1 time-frame, VMKit has had significant improvements on both runtime and startup performance:</p> <ul> - <li>Precompilation: by compiling ahead of time a small subset of Java's core - library, the startup performance have been highly optimized to the point that - running a 'Hello World' program takes less than 30 milliseconds.</li> - - <li>Customization: by customizing virtual methods for individual classes, - the VM can statically determine the target of a virtual call, and decide to - inline it.</li> - - <li>Inlining: the VM does more inlining than it did before, by allowing more - bytecode instructions to be inlined, and thanks to customization. It also - inlines GC barriers, and object allocations.</li> - - <li>New exception model: the generated code for a method that does not do - any try/catch is not penalized anymore by the eventuality of calling a - method that throws an exception. Instead, the method that throws the - exception jumps directly to the method that could catch it.</li> + <li>...</li> </ul> </div> - - -<!--=========================================================================--> -<!-- -<h3> -<a name="klee">KLEE: A Symbolic Execution Virtual Machine</a> -</h3> - -<div> -<p> -<a href="http://klee.llvm.org/">KLEE</a> is a symbolic execution framework for -programs in LLVM bitcode form. KLEE tries to symbolically evaluate "all" paths -through the application and records state transitions that lead to fault -states. This allows it to construct testcases that lead to faults and can even -be used to verify some algorithms. -</p> - -<p>UPDATE!</p> -</div>--> </div> <!-- *********************************************************************** --> <h2> - <a name="externalproj">External Open Source Projects Using LLVM 3.0</a> + <a name="externalproj">External Open Source Projects Using LLVM 3.1</a> </h2> <!-- *********************************************************************** --> @@ -306,392 +218,15 @@ be used to verify some algorithms. <p>An exciting aspect of LLVM is that it is used as an enabling technology for a lot of other language and tools projects. This section lists some of the - projects that have already been updated to work with LLVM 3.0.</p> - -<!--=========================================================================--> -<h3>AddressSanitizer</h3> - -<div> - -<p><a href="http://code.google.com/p/address-sanitizer/">AddressSanitizer</a> - uses compiler instrumentation and a specialized malloc library to find C/C++ - bugs such as use-after-free and out-of-bound accesses to heap, stack, and - globals. The key feature of the tool is speed: the average slowdown - introduced by AddressSanitizer is less than 2x.</p> - -</div> - -<!--=========================================================================--> -<h3>ClamAV</h3> - -<div> - -<p><a href="http://www.clamav.net">Clam AntiVirus</a> is an open source (GPL) - anti-virus toolkit for UNIX, designed especially for e-mail scanning on mail - gateways.</p> - -<p>Since version 0.96 it - has <a href="http://vrt-sourcefire.blogspot.com/2010/09/introduction-to-clamavs-low-level.html">bytecode - signatures</a> that allow writing detections for complex malware.</p> - -<p>It uses LLVM's JIT to speed up the execution of bytecode on X86, X86-64, - PPC32/64, falling back to its own interpreter otherwise. The git version was - updated to work with LLVM 3.0.</p> - -</div> - -<!--=========================================================================--> -<h3>clang_complete for VIM</h3> - -<div> - -<p><a href="https://github.com/Rip-Rip/clang_complete">clang_complete</a> is a - VIM plugin, that provides accurate C/C++ autocompletion using the clang front - end. The development version of clang complete, can directly use libclang - which can maintain a cache to speed up auto completion.</p> - -</div> - -<!--=========================================================================--> -<h3>clReflect</h3> - -<div> - -<p><a href="https://bitbucket.org/dwilliamson/clreflect">clReflect</a> is a C++ - parser that uses clang/LLVM to derive a light-weight reflection database - suitable for use in game development. It comes with a very simple runtime - library for loading and querying the database, requiring no external - dependencies (including CRT), and an additional utility library for object - management and serialisation.</p> - -</div> - -<!--=========================================================================--> -<h3>Cling C++ Interpreter</h3> - -<div> - -<p><a href="http://cern.ch/cling">Cling</a> is an interactive compiler interface - (aka C++ interpreter). It uses LLVM's JIT and clang; it currently supports - C++ and C. It has a prompt interface, runs source files, calls into shared - libraries, prints the value of expressions, even does runtime lookup of - identifiers (dynamic scopes). And it just behaves like one would expect from - an interpreter.</p> - -</div> - -<!--=========================================================================--> -<h3>Crack Programming Language</h3> - -<div> - -<p><a href="http://code.google.com/p/crack-language/">Crack</a> 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.</p> - -</div> - -<!--=========================================================================--> -<h3>Eero</h3> - -<div> - -<p><a href="http://eerolanguage.org/">Eero</a> is a fully - header-and-binary-compatible dialect of Objective-C 2.0, implemented with a - patched version of the Clang/LLVM compiler. It features a streamlined syntax, - Python-like indentation, and new operators, for improved readability and - reduced code clutter. It also has new features such as limited forms of - operator overloading and namespaces, and strict (type-and-operator-safe) - enumerations. It is inspired by languages such as Smalltalk, Python, and - Ruby.</p> - -</div> - -<!--=========================================================================--> -<h3>Glasgow Haskell Compiler (GHC)</h3> - -<div> - -<p>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.</p> - -<p>GHC 7.0 and onwards include an LLVM code generator, supporting LLVM 2.8 and - later. Since LLVM 2.9, GHC now includes experimental support for the ARM - platform with LLVM 3.0.</p> - -</div> - -<!--=========================================================================--> -<h3>gwXscript</h3> - -<div> - -<p><a href="http://botwars.tk/gwscript/">gwXscript</a> is an object oriented, - aspect oriented programming language which can create both executables (ELF, - EXE) and shared libraries (DLL, SO, DYNLIB). The compiler is implemented in - its own language and translates scripts into LLVM-IR which can be optimized - and translated into native code by the LLVM framework. Source code in - gwScript contains definitions that expand the namespaces. So you can build - your project and simply 'plug out' features by removing a file. The remaining - project does not leave scars since you directly separate concerns by the - 'template' feature of gwX. It is also possible to add new features to a - project by just adding files and without editing the original project. This - language is used for example to create games or content management systems - that should be extendable.</p> - -<p>gwXscript is strongly typed and offers comfort with its native types string, - hash and array. You can easily write new libraries in gwXscript or native - code. gwXscript is type safe and users should not be able to crash your - program or execute malicious code except code that is eating CPU time.</p> - -</div> - -<!--=========================================================================--> -<h3>include-what-you-use</h3> - -<div> - -<p><a href="http://code.google.com/p/include-what-you-use">include-what-you-use</a> - is a tool to ensure that a file directly <code>#include</code>s - all <code>.h</code> files that provide a symbol that the file uses. It also - removes superfluous <code>#include</code>s from source files.</p> - -</div> - -<!--=========================================================================--> -<h3>ispc: The Intel SPMD Program Compiler</h3> - -<div> - -<p><a href="http://ispc.github.com">ispc</a> is a compiler for "single program, - multiple data" (SPMD) programs. It compiles a C-based SPMD programming - language to run on the SIMD units of CPUs; it often delivers 5-6x speedups on - a single core of a CPU with an 8-wide SIMD unit compared to serial code, - while still providing a clean and easy-to-understand programming model. For - an introduction to the language and its performance, - see <a href="http://ispc.github.com/example.html">the walkthrough</a> of a short - example program. ispc is licensed under the BSD license.</p> - -</div> - -<!--=========================================================================--> -<h3>LanguageKit and Pragmatic Smalltalk</h3> - -<div> - -<p><a href="http://etoileos.com/etoile/features/languagekit/">LanguageKit</a> is - a framework for implementing dynamic languages sharing an object model with - Objective-C. It provides static and JIT compilation using LLVM along with - its own interpreter. Pragmatic Smalltalk is a dialect of Smalltalk, built on - top of LanguageKit, that interfaces directly with Objective-C, sharing the - same object representation and message sending behaviour. These projects are - developed as part of the Étoié desktop environment.</p> - -</div> - -<!--=========================================================================--> -<h3>LuaAV</h3> - -<div> - -<p><a href="http://lua-av.mat.ucsb.edu/blog/">LuaAV</a> is a real-time - audiovisual scripting environment based around the Lua language and a - collection of libraries for sound, graphics, and other media protocols. LuaAV - uses LLVM and Clang to JIT compile efficient user-defined audio synthesis - routines specified in a declarative syntax.</p> - -</div> - -<!--=========================================================================--> -<h3>Mono</h3> - -<div> - -<p>An open source, cross-platform implementation of C# and the CLR that is - binary compatible with Microsoft.NET. Has an optional, dynamically-loaded - LLVM code generation backend in Mini, the JIT compiler.</p> - -<p>Note that we use a Git mirror of LLVM with some patches. See: - https://github.com/mono/llvm</p> - -</div> - -<!--=========================================================================--> -<h3>Polly</h3> - -<div> - -<p><a href="http://polly.grosser.es">Polly</a> is an advanced data-locality - optimizer and automatic parallelizer. It uses an advanced, mathematical - model to calculate detailed data dependency information which it uses to - optimize the loop structure of a program. Polly can speed up sequential code - by improving memory locality and consequently the cache use. Furthermore, - Polly is able to expose different kind of parallelism which it exploits by - introducing (basic) OpenMP and SIMD code. A mid-term goal of Polly is to - automatically create optimized GPU code.</p> - -</div> - -<!--=========================================================================--> -<h3>Portable OpenCL (pocl)</h3> - -<div> - -<p>Portable OpenCL is an open source implementation of the OpenCL standard which - can be easily adapted for new targets. One of the goals of the project is - improving performance portability of OpenCL programs, avoiding the need for - target-dependent manual optimizations. A "native" target is included, which - allows running OpenCL kernels on the host (CPU).</p> - -</div> - -<!--=========================================================================--> -<h3>Pure</h3> - -<div> -<p><a href="http://pure-lang.googlecode.com/">Pure</a> 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).</p> - -<p>Pure version 0.48 has been tested and is known to work with LLVM 3.0 - (and continues to work with older LLVM releases >= 2.5).</p> - -</div> - -<!--=========================================================================--> -<h3>Renderscript</h3> - -<div> - -<p><a href="http://developer.android.com/guide/topics/renderscript/index.html">Renderscript</a> - is Android's advanced 3D graphics rendering and compute API. It provides a - portable C99-based language with extensions to facilitate common use cases - for enhancing graphics and thread level parallelism. The Renderscript - compiler frontend is based on Clang/LLVM. It emits a portable bitcode format - for the actual compiled script code, as well as reflects a Java interface for - developers to control the execution of the compiled bitcode. Executable - machine code is then generated from this bitcode by an LLVM backend on the - device. Renderscript is thus able to provide a mechanism by which Android - developers can improve performance of their applications while retaining - portability.</p> - -</div> - -<!--=========================================================================--> -<h3>SAFECode</h3> - -<div> - -<p><a href="http://safecode.cs.illinois.edu">SAFECode</a> is a memory safe C/C++ - compiler built using LLVM. It takes standard, unannotated C/C++ code, - analyzes the code to ensure that memory accesses and array indexing - operations are safe, and instruments the code with run-time checks when - safety cannot be proven statically. SAFECode can be used as a debugging aid - (like Valgrind) to find and repair memory safety bugs. It can also be used - to protect code from security attacks at run-time.</p> - -</div> - -<!--=========================================================================--> -<h3>The Stupid D Compiler (SDC)</h3> - -<div> - -<p><a href="https://github.com/bhelyer/SDC">The Stupid D Compiler</a> is a - project seeking to write a self-hosting compiler for the D programming - language without using the frontend of the reference compiler (DMD).</p> - -</div> - -<!--=========================================================================--> -<h3>TTA-based Co-design Environment (TCE)</h3> - -<div> - -<p>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.</p> - -<p>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.</p> - -</div> - -<!--=========================================================================--> -<h3>Tart Programming Language</h3> - -<div> - -<p><a href="http://code.google.com/p/tart/">Tart</a> is a general-purpose, - strongly typed programming language designed for application - developers. Strongly inspired by Python and C#, Tart focuses on practical - solutions for the professional software developer, while avoiding the clutter - and boilerplate of legacy languages like Java and C++. Although Tart is still - in development, the current implementation supports many features expected of - a modern programming language, such as garbage collection, powerful - bidirectional type inference, a greatly simplified syntax for template - metaprogramming, closures and function literals, reflection, operator - overloading, explicit mutability and immutability, and much more. Tart is - flexible enough to accommodate a broad range of programming styles and - philosophies, while maintaining a strong commitment to simplicity, minimalism - and elegance in design.</p> - -</div> - -<!--=========================================================================--> -<h3>ThreadSanitizer</h3> - -<div> + projects that have already been updated to work with LLVM 3.1.</p> -<p><a href="http://code.google.com/p/data-race-test/">ThreadSanitizer</a> 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.</p> + ... to be filled in right before the release ... </div> -<!--=========================================================================--> -<h3>The ZooLib C++ Cross-Platform Application Framework</h3> - -<div> - -<p><a href="http://www.zoolib.org/">ZooLib</a> is Open Source under the MIT - License. It provides GUI, filesystem access, TCP networking, thread-safe - memory management, threading and locking for Mac OS X, Classic Mac OS, - Microsoft Windows, POSIX operating systems with X11, BeOS, Haiku, Apple's iOS - and Research in Motion's BlackBerry.</p> - -<p>My current work is to use CLang's static analyzer to improve ZooLib's code - quality. I also plan to set up LLVM compiles of the demo programs and test - programs using CLang and LLVM on all the platforms that CLang, LLVM and - ZooLib all support.</p> - -</div> - -</div> - <!-- *********************************************************************** --> <h2> - <a name="whatsnew">What's New in LLVM 3.0?</a> + <a name="whatsnew">What's New in LLVM 3.1?</a> </h2> <!-- *********************************************************************** --> @@ -708,48 +243,36 @@ be used to verify some algorithms. <div> -<p><b>llvm-gcc is gone</b></p> + <!-- Features that need text if they're finished for 3.1: + ARM EHABI + combiner-aa? + strong phi elim + loop dependence analysis + CorrelatedValuePropagation + lib/Transforms/IPO/MergeFunctions.cpp => consider for 3.1. + Integrated assembler on by default for arm/thumb? + + --> -<p>LLVM 3.0 includes several major new capabilities:</p> - -<!-- Near dead: + <!-- Near dead: Analysis/RegionInfo.h + Dom Frontiers SparseBitVector: used in LiveVar. - - --> - -<!-- - Type system rewrite. - Better performance for Neon code in clang due to SRoA improvements. - New regalloc on by default. Lin scan going away in 3.1 - PGO / builtin_expect improvements (summary needed) - Big EH rewrite. - AVX support, assembler, compiler and disassembler. - IndVar improvements: andy - PTX backend improvements: Justin - llvm-rtdyld & MC JIT: JimG - InstAliases now automatically used in the asmprinter where they are shorter. - Integrated assembler on by default for arm/thumb? - PostOrder Dominator frontiers were removed. - Line Profiling / gcov support - EH and debug information produced with CFI directives, yielding smaller executables: http://blog.mozilla.com/respindola/2011/05/12/cfi-directives/ - X86-64 generates smaller and faster code at -O0 (fast isel improvements) - Better code generation for Cortex-A9 - Many APIs take ArrayRef's now. - Pass manager extension API. - - --> - -<ul> + llvm/lib/Archive - replace with lib object? + --> -<!-- -<li></li> ---> - +<p>LLVM 3.1 includes several major changes and big features:</p> + +<ul> + <li><a href="../tools/clang/docs/AddressSanitizer.html">AddressSanitizer</a>, + a fast memory error detector.</li> + <li><a href="CodeGenerator.html#machineinstrbundle">MachineInstr Bundles</a>, + Support to model instruction bundling / packing.</li> + <li>....</li> </ul> - + </div> + <!--=========================================================================--> <h3> <a name="coreimprovements">LLVM IR and Core Improvements</a> @@ -760,140 +283,9 @@ be used to verify some algorithms. <p>LLVM IR has several new features for better support of new targets and that expose new optimization opportunities:</p> -<p>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 <code>invoke</code> instruction, making it hard - to recover that information.</p> - -<p>The new EH system makes exception handling a first-class member of the IR. It - adds two new instructions:</p> - -<ul> - <li><a href="LangRef.html#i_landingpad"><code>landingpad</code></a> — - 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 <code>invoke</code> - instruction.</li> - - <li><a href="LangRef.html#i_resume"><code>resume</code></a> — this - instruction causes the current exception to resume traveling up the - stack. It replaces the <code>@llvm.eh.resume</code> intrinsic.</li> -</ul> - -<p>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, - <code>@llvm.eh.exception</code> and <code>@llvm.eh.selector</code> have been - superceded by the <code>landingpad</code> instruction. Instead of generating - a call to <code>@llvm.eh.exception</code> and <code>@llvm.eh.selector</code>: - -<div class="doc_code"> -<pre> -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))); - -<i>// Add selector clauses to Args.</i> - -// The selector call. -Builder.CreateCall(SlctrIntr, Args, "exc_sel"); -</pre> -</div> - -<p>You should instead generate a <code>landingpad</code> instruction, that - returns an exception object and selector value:</p> - -<div class="doc_code"> -<pre> -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()); -</pre> -</div> - -<p>It's now trivial to add the individual clauses to the <code>landingpad</code> - instruction.</p> - -<div class="doc_code"> -<pre> -<i><b>// Adding a catch clause</b></i> -Constant *TypeInfo = getTypeInfo(); -LPadInst->addClause(TypeInfo); - -<i><b>// Adding a C++ catch-all</b></i> -LPadInst->addClause(Constant::getNullValue(Builder.getInt8PtrTy())); - -<i><b>// Adding a cleanup</b></i> -LPadInst->setCleanup(true); - -<i><b>// Adding a filter clause</b></i> -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)); -</pre> -</div> - -<p>Converting from using the <code>@llvm.eh.resume</code> intrinsic to - the <code>resume</code> instruction is trivial. It takes the exception - pointer and exception selector values returned by - the <code>landingpad</code> instruction:</p> - -<div class="doc_code"> -<pre> -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); -</pre> -</div> - -</div> - -<!--=========================================================================--> -<h3> -<a name="loopoptimization">Loop Optimization Improvements</a> -</h3> - -<div> -<p>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.</p> - -<p>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.</p> + <ul> + <li>....</li> + </ul> </div> <!--=========================================================================--> @@ -903,16 +295,12 @@ Builder.CreateResume(UnwindData); <div> -<p>In addition to a large array of minor performance tweaks and bug fixes, this +<p>In addition to many minor performance tweaks and bug fixes, this release includes a few major enhancements and additions to the optimizers:</p> <ul> -<!-- -<li></li> ---> -</li> - + <li>....</li> </ul> </div> @@ -927,24 +315,14 @@ Builder.CreateResume(UnwindData); <p>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.</p> + in. For more information, please see + the <a href="http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html">Intro + to the LLVM MC Project Blog Post</a>.</p> <ul> - <li>The ELF object streamers are much more full featured.</li> - <li>Target dependent relocation handling has been refactored into the Targets.</li> - <li>Early stage MC-JIT infrastructure has been implemented.</li> + <li>....</li> </ul> -<p>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.</p> - -<p>For more information, please see - the <a href="http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html">Intro - to the LLVM MC Project Blog Post</a>.</p> - </div> <!--=========================================================================--> @@ -959,9 +337,7 @@ compiler and provides better integration with the platform ABI as a result.</p> make it run faster:</p> <ul> -<!-- -<li></li> ---> + <li>....</li> </ul> </div> @@ -975,17 +351,7 @@ compiler and provides better integration with the platform ABI as a result.</p> <p>New features and major changes in the X86 target include:</p> <ul> - - <li>The X86 backend now supports - all <a href="http://llvm.org/PR879">inline assembly that uses the X86 - floating point stack</a>.</li> - - <li>The CRC32 intrinsics have been renamed. The intrinsics were previously - <code>@llvm.x86.sse42.crc32.[8|16|32]</code> - and <code>@llvm.x86.sse42.crc64.[8|64]</code>. They have been renamed to - <code>@llvm.x86.sse42.crc32.32.[8|16|32]</code> and - <code>@llvm.x86.sse42.crc32.64.[8|64]</code>.</li> - + <li>....</li> </ul> </div> @@ -1000,13 +366,11 @@ compiler and provides better integration with the platform ABI as a result.</p> <p>New features of the ARM target include:</p> <ul> - <li>Reworked Set Jump Long Jump EH Lowering,</li> - <li>improved support for Cortex-M series processors, and</li> - <li>beta quality integrated assembler support.</li> + <li>....</li> </ul> </div> - + <!--=========================================================================--> <h3> <a name="MIPS">MIPS Target Improvements</a> @@ -1014,62 +378,25 @@ compiler and provides better integration with the platform ABI as a result.</p> <div> -<p>New features and major changes in the MIPS target include:</p> +<p>This release has seen major new work on just about every aspect of the MIPS + backend. Some of the major new features include:</p> <ul> - <li>Most MIPS32r1 and r2 instructions are now supported.</li> - <li>LE/BE MIPS32r1/r2 has been tested extensively.</li> - <li>O32 ABI has been fully tested.</li> - <li>MIPS backend has migrated to using the MC infrastructure for assembly printing. Initial support for direct object code emission has been implemented too.</li> - <li>Delay slot filler has been updated. Now it tries to fill delay slots with useful instructions instead of always filling them with NOPs.</li> - <li>Support for old-style JIT is complete.</li> - <li>Support for old architectures (MIPS1 and MIPS2) has been removed.</li> - <li>Initial support for MIPS64 has been added.</li> + <li>....</li> </ul> </div> <!--=========================================================================--> <h3> - <a name="PTX">PTX Target Improvements</a> -</h3> - -<div> - - <p> - 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.</p> - - <p>That said, the backend is already being used for domain-specific languages - and works well with the <a href="http://www.pcc.me.uk/~peter/libclc/">libclc - library</a> 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.</p> - -</div> - -<!--=========================================================================--> -<h3> <a name="OtherTS">Other Target Specific Improvements</a> </h3> <div> - <p>PPC32/ELF va_arg was implemented.</p> - <p>PPC32 initial support for .o file writing was implemented.</p> - <p>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 <code>-mcpu=mblaze3</code> - and the 5-stage pipeline model can be selected with - <code>-mcpu=mblaze5</code>.</p> - <ul> -<!-- -<li></li> ---> + <li>....</li> + + </ul> </div> @@ -1082,37 +409,18 @@ compiler and provides better integration with the platform ABI as a result.</p> <div> <p>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 + LLVM 3.1, this section lists some "gotchas" that you may run into upgrading from the previous release.</p> <ul> - <li>The <code>LLVMC</code> front end code was removed while separating - out language independence.</li> - <li>The <code>LowerSetJmp</code> pass wasn't used effectively by any - target and has been removed.</li> - <li>The old <code>TailDup</code> pass was not used in the standard pipeline - and was unable to update ssa form, so it has been removed. - <li>The syntax of volatile loads and stores in IR has been changed to - "<code>load volatile</code>"/"<code>store volatile</code>". The old - syntax ("<code>volatile load</code>"/"<code>volatile store</code>") - is still accepted, but is now considered deprecated.</li> - <li>The old atomic intrinscs (<code>llvm.memory.barrier</code> and - <code>llvm.atomic.*</code>) are now gone. Please use the new atomic - instructions, described in the <a href="Atomics.html">atomics guide</a>. -</ul> - -<h4>Windows (32-bit)</h4> -<div> - -<ul> - <li>On Win32(MinGW32 and MSVC), Windows 2000 will not be supported. - Windows XP or higher is required.</li> +<li>LLVM 3.1 removes support for reading LLVM 2.9 bitcode files. Going forward, + we aim for all future versions of LLVM to read bitcode files and .ll files + produced by LLVM 3.0 and later.</li> + <li>....</li> </ul> </div> -</div> - <!--=========================================================================--> <h3> <a name="api_changes">Internal API Changes</a> @@ -1124,104 +432,7 @@ compiler and provides better integration with the platform ABI as a result.</p> LLVM API changes are:</p> <ul> - <li>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.</li> - - <li><code>PHINode::reserveOperandSpace</code> 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 <code>PHINode::Create</code>.</li> - - <li>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 <code>PHINode::block_begin</code> - and <code>PHINode::block_end</code>.</li> - - <li>Various functions now take an <code>ArrayRef</code> 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 <code>ArrayRef</code> instead - of a reference to a <code>SmallVector</code> - or <code>std::vector</code>. These include: -<ul> -<!-- Please keep this list sorted. --> -<li><code>CallInst::Create</code></li> -<li><code>ComputeLinearIndex</code> (in <code>llvm/CodeGen/Analysis.h</code>)</li> -<li><code>ConstantArray::get</code></li> -<li><code>ConstantExpr::getExtractElement</code></li> -<li><code>ConstantExpr::getGetElementPtr</code></li> -<li><code>ConstantExpr::getInBoundsGetElementPtr</code></li> -<li><code>ConstantExpr::getIndices</code></li> -<li><code>ConstantExpr::getInsertElement</code></li> -<li><code>ConstantExpr::getWithOperands</code></li> -<li><code>ConstantFoldCall</code> (in <code>llvm/Analysis/ConstantFolding.h</code>)</li> -<li><code>ConstantFoldInstOperands</code> (in <code>llvm/Analysis/ConstantFolding.h</code>)</li> -<li><code>ConstantVector::get</code></li> -<li><code>DIBuilder::createComplexVariable</code></li> -<li><code>DIBuilder::getOrCreateArray</code></li> -<li><code>ExtractValueInst::Create</code></li> -<li><code>ExtractValueInst::getIndexedType</code></li> -<li><code>ExtractValueInst::getIndices</code></li> -<li><code>FindInsertedValue</code> (in <code>llvm/Analysis/ValueTracking.h</code>)</li> -<li><code>gep_type_begin</code> (in <code>llvm/Support/GetElementPtrTypeIterator.h</code>)</li> -<li><code>gep_type_end</code> (in <code>llvm/Support/GetElementPtrTypeIterator.h</code>)</li> -<li><code>GetElementPtrInst::Create</code></li> -<li><code>GetElementPtrInst::CreateInBounds</code></li> -<li><code>GetElementPtrInst::getIndexedType</code></li> -<li><code>InsertValueInst::Create</code></li> -<li><code>InsertValueInst::getIndices</code></li> -<li><code>InvokeInst::Create</code></li> -<li><code>IRBuilder::CreateCall</code></li> -<li><code>IRBuilder::CreateExtractValue</code></li> -<li><code>IRBuilder::CreateGEP</code></li> -<li><code>IRBuilder::CreateInBoundsGEP</code></li> -<li><code>IRBuilder::CreateInsertValue</code></li> -<li><code>IRBuilder::CreateInvoke</code></li> -<li><code>MDNode::get</code></li> -<li><code>MDNode::getIfExists</code></li> -<li><code>MDNode::getTemporary</code></li> -<li><code>MDNode::getWhenValsUnresolved</code></li> -<li><code>SimplifyGEPInst</code> (in <code>llvm/Analysis/InstructionSimplify.h</code>)</li> -<li><code>TargetData::getIndexedOffset</code></li> -</ul></li> - - <li>All forms of <code>StringMap::getOrCreateValue</code> have been remove - except for the one which takes a <code>StringRef</code>.</li> - - <li>The <code>LLVMBuildUnwind</code> function from the C API was removed. The - LLVM <code>unwind</code> 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.</li> - - <li>The <code>LLVMAddLowerSetJmpPass</code> function from the C API was - removed because the <code>LowerSetJmp</code> pass was removed.</li> - - <li>The <code>DIBuilder</code> interface used by front ends to encode - debugging information in the LLVM IR now expects clients to - use <code>DIBuilder::finalize()</code> at the end of translation unit to - complete debugging information encoding.</li> - - <li>The way the type system works has been - rewritten: <code>PATypeHolder</code> and <code>OpaqueType</code> are gone, - and all APIs deal with <code>Type*</code> instead of <code>const - Type*</code>. If you need to create recursive structures, then create a - named structure, and use <code>setBody()</code> 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).</li> - - <li>TargetSelect.h moved to Support/ from Target/</li> - - <li>UpgradeIntrinsicCall no longer upgrades pre-2.9 intrinsic calls (for - example <code>llvm.memset.i32</code>).</li> - - <li>It is mandatory to initialize all out-of-tree passes too and their dependencies now with - <code>INITIALIZE_PASS{BEGIN,END,}</code> - and <code>INITIALIZE_{PASS,AG}_DEPENDENCY</code>.</li> - - <li>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.</li> + <li>....</li> </ul> </div> @@ -1236,150 +447,34 @@ compiler and provides better integration with the platform ABI as a result.</p> <div> -<p>This section contains significant known problems with the LLVM system, listed - by component. If you run into a problem, please check - the <a href="http://llvm.org/bugs/">LLVM bug database</a> and submit a bug if - there isn't already one.</p> - -<!-- ======================================================================= --> -<h3> - <a name="experimental">Experimental features included with this release</a> -</h3> - -<div> - -<p>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 <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev - list</a>.</p> - -<ul> - <li>The Alpha, Blackfin, CellSPU, MicroBlaze, MSP430, MIPS, PTX, SystemZ and - XCore backends are experimental.</li> - - <li><tt>llc</tt> "<tt>-filetype=obj</tt>" is experimental on all targets other - than darwin and ELF X86 systems.</li> -</ul> - -</div> - -<!-- ======================================================================= --> -<h3> - <a name="x86-be">Known problems with the X86 back-end</a> -</h3> - -<div> - -<ul> - <li>The X86-64 backend <a href="http://llvm.org/PR1740">does not yet support - the <tt>va_arg</tt> LLVM IR instruction</a>. Currently, front-ends support - variadic argument constructs on X86-64 by lowering them manually.</li> -</ul> - -</div> - -<!-- ======================================================================= --> -<h3> - <a name="ppc-be">Known problems with the PowerPC back-end</a> -</h3> - -<div> - -<ul> - <li>The PPC32/ELF support lacks PIC support.</li> -</ul> - -</div> - -<!-- ======================================================================= --> -<h3> - <a name="arm-be">Known problems with the ARM back-end</a> -</h3> - -<div> - -<ul> - <li>Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6 - processors, thumb programs can crash or produce wrong results - (<a href="http://llvm.org/PR1388">PR1388</a>).</li> - - <li>Compilation for ARM Linux OABI (old ABI) is supported but not fully - tested.</li> -</ul> - -</div> - -<!-- ======================================================================= --> -<h3> - <a name="sparc-be">Known problems with the SPARC back-end</a> -</h3> - -<div> - -<ul> - <li>The SPARC backend only supports the 32-bit SPARC ABI (-m32); it does not - support the 64-bit SPARC ABI (-m64).</li> -</ul> - -</div> - -<!-- ======================================================================= --> -<h3> - <a name="mips-be">Known problems with the MIPS back-end</a> -</h3> - -<div> - -<ul> - <li>64-bit MIPS targets are not supported yet.</li> -</ul> - -</div> - -<!-- ======================================================================= --> -<h3> - <a name="alpha-be">Known problems with the Alpha back-end</a> -</h3> - -<div> - -<ul> - <li>On 21164s, some rare FP arithmetic sequences which may trap do not have - the appropriate nops inserted to ensure restartability.</li> -</ul> +<p>LLVM is generally a production quality compiler, and is used by a broad range + of applications and shipping in many products. That said, not every + subsystem is as mature as the aggregate, particularly the more obscure + targets. If you run into a problem, please check the <a + href="http://llvm.org/bugs/">LLVM bug database</a> and submit a bug if + there isn't already one or ask on the <a + href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev + list</a>.</p> -</div> - -<!-- ======================================================================= --> -<h3> - <a name="c-be">Known problems with the C back-end</a> -</h3> - -<div> - -<p>The C backend has numerous problems and is not being actively maintained. - Depending on it for anything serious is not advised.</p> + <p>Known problem areas include:</p> <ul> - <li><a href="http://llvm.org/PR802">The C backend has only basic support for - inline assembly code</a>.</li> - - <li><a href="http://llvm.org/PR1658">The C backend violates the ABI of common - C++ programs</a>, preventing intermixing between C++ compiled by the CBE - and C++ code compiled with <tt>llc</tt> or native compilers.</li> - - <li>The C backend does not support all exception handling constructs.</li> - - <li>The C backend does not support arbitrary precision integers.</li> + <li>The Alpha, Blackfin, CellSPU, MSP430, PTX, SystemZ and + XCore backends are experimental, and the Alpha, Blackfin and SystemZ + targets have already been removed from mainline.</li> + + <li>The integrated assembler, disassembler, and JIT is not supported by + several targets. If an integrated assembler is not supported, then a + system assembler is required. For more details, see the <a + href="CodeGenerator.html#targetfeatures">Target Features Matrix</a>. + </li> + + <li>The C backend has numerous problems and is not being actively maintained. + Depending on it for anything serious is not advised.</li> </ul> </div> -</div> - <!-- *********************************************************************** --> <h2> <a name="additionalinfo">Additional Information</a> diff --git a/docs/SegmentedStacks.html b/docs/SegmentedStacks.html index a91b109..16f5507 100644 --- a/docs/SegmentedStacks.html +++ b/docs/SegmentedStacks.html @@ -20,18 +20,12 @@ <li><a href="#alloca">Variable Sized Allocas</a></li> </ol> </li> - <li><a href="#results">Results</a> - <ol> - <li><a href="#go">Go on LLVM</a></li> - <li><a href="#abi">Runtime ABI</a></li> - </ol> - </li> </ol> <h2><a name="intro">Introduction</a></h2> <div> <p> - Segmented stack allows stack space to be allocated incrementally than as a monolithic chunk (of some worst case size) at thread initialization. This is done by allocating stack blocks (henceforth called <em>stacklets</em>) and linking them into a doubly linked list. The function prologue is responsible for checking if the current stacklet has enough space for the function to execute; and if not, call into the libgcc runtime to allocate more stack space. Support for segmented stacks on x86 / Linux is currently being worked on. + Segmented stack allows stack space to be allocated incrementally than as a monolithic chunk (of some worst case size) at thread initialization. This is done by allocating stack blocks (henceforth called <em>stacklets</em>) and linking them into a doubly linked list. The function prologue is responsible for checking if the current stacklet has enough space for the function to execute; and if not, call into the libgcc runtime to allocate more stack space. When using <tt>llc</tt>, segmented stacks can be enabled by adding <tt>-segmented-stacks</tt> to the command line. </p> <p> The runtime functionality is <a href="http://gcc.gnu.org/wiki/SplitStacks">already there in libgcc</a>. diff --git a/docs/TestingGuide.html b/docs/TestingGuide.html index 3309ac3..bb47cb1 100644 --- a/docs/TestingGuide.html +++ b/docs/TestingGuide.html @@ -253,40 +253,35 @@ programs), first checkout and setup the <tt>test-suite</tt> module:</p> <div class="doc_code"> <pre> -% cd llvm/projects +% cd ~/llvm/projects % svn co http://llvm.org/svn/llvm-project/test-suite/trunk test-suite % cd .. -% ./configure --with-llvmgccdir=$LLVM_GCC_DIR </pre> </div> -<p>where <tt>$LLVM_GCC_DIR</tt> is the directory where -you <em>installed</em> llvm-gcc, not its src or obj -dir. The <tt>--with-llvmgccdir</tt> option assumes that -the <tt>llvm-gcc-4.2</tt> module was configured with -<tt>--program-prefix=llvm-</tt>, and therefore that the C and C++ -compiler drivers are called <tt>llvm-gcc</tt> and <tt>llvm-g++</tt> -respectively. If this is not the case, -use <tt>--with-llvmgcc</tt>/<tt>--with-llvmgxx</tt> to specify each -executable's location.</p> +<p>and then configure and build normally as you would from the +<a href="http://llvm.org/docs/GettingStarted.html#quickstart">Getting Started +Guide</a>. This will autodetect first the built clang if you are building +clang, then <tt>clang</tt> in your path and finally look for <tt>llvm-gcc</tt> +in your path. <p>Then, run the entire test suite by running make in the <tt>test-suite</tt> -directory:</p> +subdirectory of your build directory:</p> <div class="doc_code"> <pre> -% cd projects/test-suite +% cd <i>where-you-built-llvm</i>/projects/test-suite % gmake </pre> </div> -<p>Usually, running the "nightly" set of tests is a good idea, and you can also +<p>Usually, running the "simple" set of tests is a good idea, and you can also let it generate a report by running:</p> <div class="doc_code"> <pre> -% cd projects/test-suite -% gmake TEST=nightly report report.html +% cd <i>where-you-built-llvm</i>/projects/test-suite +% gmake TEST=simple report report.html </pre> </div> |