diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/CodeGenerator.html | 10 | ||||
| -rw-r--r-- | docs/CodingStandards.html | 2 | ||||
| -rw-r--r-- | docs/CommandGuide/FileCheck.pod | 58 | ||||
| -rw-r--r-- | docs/CommandGuide/lit.pod | 50 | ||||
| -rw-r--r-- | docs/CommandGuide/llc.pod | 2 | ||||
| -rw-r--r-- | docs/DeveloperPolicy.html | 4 | ||||
| -rw-r--r-- | docs/ExceptionHandling.html | 2 | ||||
| -rw-r--r-- | docs/ExtendingLLVM.html | 13 | ||||
| -rw-r--r-- | docs/FAQ.html | 24 | ||||
| -rw-r--r-- | docs/GettingStarted.html | 9 | ||||
| -rw-r--r-- | docs/LLVMBuild.html | 10 | ||||
| -rw-r--r-- | docs/LangRef.html | 53 | ||||
| -rw-r--r-- | docs/ProgrammersManual.html | 17 | ||||
| -rw-r--r-- | docs/ReleaseNotes.html | 125 | ||||
| -rw-r--r-- | docs/SourceLevelDebugging.html | 108 | ||||
| -rw-r--r-- | docs/TableGenFundamentals.html | 2 | ||||
| -rw-r--r-- | docs/TestingGuide.html | 20 | ||||
| -rw-r--r-- | docs/WritingAnLLVMPass.html | 138 |
18 files changed, 429 insertions, 218 deletions
diff --git a/docs/CodeGenerator.html b/docs/CodeGenerator.html index 32a3a97..c4b15df 100644 --- a/docs/CodeGenerator.html +++ b/docs/CodeGenerator.html @@ -861,6 +861,8 @@ ret </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="mc">The "MC" Layer</a> @@ -1615,9 +1617,9 @@ def : Pat<(i32 imm:$imm), range from 1 to 1023. To see how this numbering is defined for a particular architecture, you can read the <tt>GenRegisterNames.inc</tt> file for that architecture. For instance, by - inspecting <tt>lib/Target/X86/X86GenRegisterNames.inc</tt> we see that the - 32-bit register <tt>EAX</tt> is denoted by 15, and the MMX register - <tt>MM0</tt> is mapped to 48.</p> + inspecting <tt>lib/Target/X86/X86GenRegisterInfo.inc</tt> we see that the + 32-bit register <tt>EAX</tt> is denoted by 43, and the MMX register + <tt>MM0</tt> is mapped to 65.</p> <p>Some architectures contain registers that share the same physical location. A notable example is the X86 platform. For instance, in the X86 architecture, @@ -1625,7 +1627,7 @@ def : Pat<(i32 imm:$imm), bits. These physical registers are marked as <i>aliased</i> in LLVM. Given a particular architecture, you can check which registers are aliased by inspecting its <tt>RegisterInfo.td</tt> file. Moreover, the method - <tt>TargetRegisterInfo::getAliasSet(p_reg)</tt> returns an array containing + <tt>MCRegisterInfo::getAliasSet(p_reg)</tt> returns an array containing all the physical registers aliased to the register <tt>p_reg</tt>.</p> <p>Physical registers, in LLVM, are grouped in <i>Register Classes</i>. diff --git a/docs/CodingStandards.html b/docs/CodingStandards.html index f00caa3..5390a7a 100644 --- a/docs/CodingStandards.html +++ b/docs/CodingStandards.html @@ -465,7 +465,7 @@ common use case of LLVM as a library linked into a larger application.</p> <p>Consider the use of LLVM as a JIT linked into another application (perhaps for <a href="http://llvm.org/Users.html">OpenGL, custom languages</a>, <a href="http://llvm.org/devmtg/2010-11/Gritz-OpenShadingLang.pdf">shaders in -movies</a>, etc</a>). Due to the design of static constructors, they must be +movies</a>, etc). Due to the design of static constructors, they must be executed at startup time of the entire application, regardless of whether or how LLVM is used in that larger application. There are two problems with this:</p> diff --git a/docs/CommandGuide/FileCheck.pod b/docs/CommandGuide/FileCheck.pod index dbd626c..2662cc0 100644 --- a/docs/CommandGuide/FileCheck.pod +++ b/docs/CommandGuide/FileCheck.pod @@ -67,20 +67,20 @@ This syntax says to pipe the current file ("%s") into llvm-as, pipe that into llc, then pipe the output of llc into FileCheck. This means that FileCheck will be verifying its standard input (the llc output) against the filename argument specified (the original .ll file specified by "%s"). To see how this works, -lets look at the rest of the .ll file (after the RUN line): +let's look at the rest of the .ll file (after the RUN line): define void @sub1(i32* %p, i32 %v) { entry: - ; <b>CHECK: sub1:</b> - ; <b>CHECK: subl</b> + ; CHECK: sub1: + ; CHECK: subl %0 = tail call i32 @llvm.atomic.load.sub.i32.p0i32(i32* %p, i32 %v) ret void } define void @inc4(i64* %p) { entry: - ; <b>CHECK: inc4:</b> - ; <b>CHECK: incq</b> + ; CHECK: inc4: + ; CHECK: incq %0 = tail call i64 @llvm.atomic.load.add.i64.p0i64(i64* %p, i64 1) ret void } @@ -111,18 +111,18 @@ driven from one .ll file. This is useful in many circumstances, for example, testing different architectural variants with llc. Here's a simple example: ; RUN: llvm-as < %s | llc -mtriple=i686-apple-darwin9 -mattr=sse41 \ - ; RUN: | <b>FileCheck %s -check-prefix=X32</b> + ; RUN: | FileCheck %s -check-prefix=X32> ; RUN: llvm-as < %s | llc -mtriple=x86_64-apple-darwin9 -mattr=sse41 \ - ; RUN: | <b>FileCheck %s -check-prefix=X64</b> + ; RUN: | FileCheck %s -check-prefix=X64> define <4 x i32> @pinsrd_1(i32 %s, <4 x i32> %tmp) nounwind { %tmp1 = insertelement <4 x i32>; %tmp, i32 %s, i32 1 ret <4 x i32> %tmp1 - ; <b>X32:</b> pinsrd_1: - ; <b>X32:</b> pinsrd $1, 4(%esp), %xmm0 + ; X32: pinsrd_1: + ; X32: pinsrd $1, 4(%esp), %xmm0 - ; <b>X64:</b> pinsrd_1: - ; <b>X64:</b> pinsrd $1, %edi, %xmm0 + ; X64: pinsrd_1: + ; X64: pinsrd $1, %edi, %xmm0 } In this case, we're testing that we get the expected code generation with @@ -147,13 +147,13 @@ example, something like this works as you'd expect: store <2 x double> %tmp9, <2 x double>* %r, align 16 ret void - ; <b>CHECK:</b> t2: - ; <b>CHECK:</b> movl 8(%esp), %eax - ; <b>CHECK-NEXT:</b> movapd (%eax), %xmm0 - ; <b>CHECK-NEXT:</b> movhpd 12(%esp), %xmm0 - ; <b>CHECK-NEXT:</b> movl 4(%esp), %eax - ; <b>CHECK-NEXT:</b> movapd %xmm0, (%eax) - ; <b>CHECK-NEXT:</b> ret + ; CHECK: t2: + ; CHECK: movl 8(%esp), %eax + ; CHECK-NEXT: movapd (%eax), %xmm0 + ; CHECK-NEXT: movhpd 12(%esp), %xmm0 + ; CHECK-NEXT: movl 4(%esp), %eax + ; CHECK-NEXT: movapd %xmm0, (%eax) + ; CHECK-NEXT: ret } CHECK-NEXT: directives reject the input unless there is exactly one newline @@ -177,9 +177,9 @@ can be used: %A = load i8* %P3 ret i8 %A - ; <b>CHECK:</b> @coerce_offset0 - ; <b>CHECK-NOT:</b> load - ; <b>CHECK:</b> ret i8 + ; CHECK: @coerce_offset0 + ; CHECK-NOT: load + ; CHECK: ret i8 } @@ -195,7 +195,7 @@ matching for a majority of what we do, FileCheck has been designed to support mixing and matching fixed string matching with regular expressions. This allows you to write things like this: - ; CHECK: movhpd <b>{{[0-9]+}}</b>(%esp), <b>{{%xmm[0-7]}}</b> + ; CHECK: movhpd {{[0-9]+}}(%esp), {{%xmm[0-7]}} In this case, any offset from the ESP register will be allowed, and any xmm register will be allowed. @@ -217,20 +217,20 @@ allows named variables to be defined and substituted into patterns. Here is a simple example: ; CHECK: test5: - ; CHECK: notw <b>[[REGISTER:%[a-z]+]]</b> - ; CHECK: andw {{.*}}<b>[[REGISTER]]</b> + ; CHECK: notw [[REGISTER:%[a-z]+]] + ; CHECK: andw {{.*}}[REGISTER]] -The first check line matches a regex (<tt>%[a-z]+</tt>) and captures it into -the variables "REGISTER". The second line verifies that whatever is in REGISTER +The first check line matches a regex (B<%[a-z]+>) and captures it into +the variable "REGISTER". The second line verifies that whatever is in REGISTER occurs later in the file after an "andw". FileCheck variable references are -always contained in <tt>[[ ]]</tt> pairs, are named, and their names can be -formed with the regex "<tt>[a-zA-Z_][a-zA-Z0-9_]*</tt>". If a colon follows the +always contained in B<[[ ]]> pairs, are named, and their names can be +formed with the regex "B<[a-zA-Z_][a-zA-Z0-9_]*>". If a colon follows the name, then it is a definition of the variable, if not, it is a use. FileCheck variables can be defined multiple times, and uses always get the latest value. Note that variables are all read at the start of a "CHECK" line and are all defined at the end. This means that if you have something like -"<tt>CHECK: [[XYZ:.*]]x[[XYZ]]<tt>" that the check line will read the previous +"B<CHECK: [[XYZ:.*]]x[[XYZ]]>", the check line will read the previous value of the XYZ variable and define a new one after the match is performed. If you need to do something like this you can probably take advantage of the fact that FileCheck is not actually line-oriented when it matches, this allows you to diff --git a/docs/CommandGuide/lit.pod b/docs/CommandGuide/lit.pod index e0b1a8c..81fc2c9 100644 --- a/docs/CommandGuide/lit.pod +++ b/docs/CommandGuide/lit.pod @@ -301,6 +301,9 @@ reported as unsupported. Used by: I<ShTest>, I<TclTest>. B<parent> The parent configuration, this is the config object for the directory containing the test suite, or None. +B<root> The root configuration. This is the top-most B<lit> configuration in +the project. + B<on_clone> The config is actually cloned for every subdirectory inside a test suite, to allow local configuration on a per-directory basis. The I<on_clone> variable can be set to a Python function which will be called whenever a @@ -338,6 +341,53 @@ define subdirectories of optional tests, or to change other configuration parameters -- for example, to change the test format, or the suffixes which identify test files. +=head2 TEST RUN OUTPUT FORMAT + +The b<lit> output for a test run conforms to the following schema, in both short +and verbose modes (although in short mode no PASS lines will be shown). This +schema has been chosen to be relatively easy to reliably parse by a machine (for +example in buildbot log scraping), and for other tools to generate. + +Each test result is expected to appear on a line that matches: + +<result code>: <test name> (<progress info>) + +where <result-code> is a standard test result such as PASS, FAIL, XFAIL, XPASS, +UNRESOLVED, or UNSUPPORTED. The performance result codes of IMPROVED and +REGRESSED are also allowed. + +The <test name> field can consist of an arbitrary string containing no newline. + +The <progress info> field can be used to report progress information such as +(1/300) or can be empty, but even when empty the parentheses are required. + +Each test result may include additional (multiline) log information in the +following format. + +<log delineator> TEST '(<test name>)' <trailing delineator> +... log message ... +<log delineator> + +where <test name> should be the name of a preceeding reported test, <log +delineator> is a string of '*' characters I<at least> four characters long (the +recommended length is 20), and <trailing delineator> is an arbitrary (unparsed) +string. + +The following is an example of a test run output which consists of four tests A, +B, C, and D, and a log message for the failing test C. + +=head3 Example Test Run Output Listing + +PASS: A (1 of 4) +PASS: B (2 of 4) +FAIL: C (3 of 4) +******************** TEST 'C' FAILED ******************** +Test 'C' failed as a result of exit code 1. +******************** +PASS: D (4 of 4) + +=back + =head2 LIT EXAMPLE TESTS The B<lit> distribution contains several example implementations of test suites diff --git a/docs/CommandGuide/llc.pod b/docs/CommandGuide/llc.pod index 50b45c8..35abdae 100644 --- a/docs/CommandGuide/llc.pod +++ b/docs/CommandGuide/llc.pod @@ -45,7 +45,7 @@ Print a summary of command line options. =item B<-O>=I<uint> Generate code at different optimization levels. These correspond to the I<-O0>, -I<-O1>, I<-O2>, I<-O3>, and I<-O4> optimization levels used by B<llvm-gcc> and +I<-O1>, I<-O2>, and I<-O3> optimization levels used by B<llvm-gcc> and B<clang>. =item B<-mtriple>=I<target triple> diff --git a/docs/DeveloperPolicy.html b/docs/DeveloperPolicy.html index 08e47a1..93eb3d3 100644 --- a/docs/DeveloperPolicy.html +++ b/docs/DeveloperPolicy.html @@ -501,6 +501,8 @@ </h2> <!--=========================================================================--> +<div> + <div class="doc_notes"> <p style="text-align:center;font-weight:bold">NOTE: This section deals with legal matters but does not provide legal advice. We are not lawyers — @@ -622,6 +624,8 @@ </div> +</div> + <!-- *********************************************************************** --> <hr> <address> diff --git a/docs/ExceptionHandling.html b/docs/ExceptionHandling.html index 42881f5..5ee1c4b 100644 --- a/docs/ExceptionHandling.html +++ b/docs/ExceptionHandling.html @@ -497,6 +497,8 @@ </div> +</div> + <!-- ======================================================================= --> <h2> <a name="asm">Asm Table Formats</a> diff --git a/docs/ExtendingLLVM.html b/docs/ExtendingLLVM.html index ca8d3e9..f8ba195 100644 --- a/docs/ExtendingLLVM.html +++ b/docs/ExtendingLLVM.html @@ -105,19 +105,6 @@ function and then be turned into an instruction if warranted.</p> support for it. Generally you must do the following steps:</p> <dl> -<dt>Add support to the C backend in <tt>lib/Target/CBackend/</tt></dt> - -<dd>Depending on the intrinsic, there are a few ways to implement this. For - most intrinsics, it makes sense to add code to lower your intrinsic in - <tt>LowerIntrinsicCall</tt> in <tt>lib/CodeGen/IntrinsicLowering.cpp</tt>. - Second, if it makes sense to lower the intrinsic to an expanded sequence of - C code in all cases, just emit the expansion in <tt>visitCallInst</tt> in - <tt>Writer.cpp</tt>. If the intrinsic has some way to express it with GCC - (or any other compiler) extensions, it can be conditionally supported based - on the compiler compiling the CBE output (see <tt>llvm.prefetch</tt> for an - example). Third, if the intrinsic really has no way to be lowered, just - have the code generator emit code that prints an error message and calls - abort if executed.</dd> <dt>Add support to the .td file for the target(s) of your choice in <tt>lib/Target/*/*.td</tt>.</dt> diff --git a/docs/FAQ.html b/docs/FAQ.html index 7294cdd..74e8534 100644 --- a/docs/FAQ.html +++ b/docs/FAQ.html @@ -140,6 +140,8 @@ </h2> <!-- *********************************************************************** --> +<div> + <div class="question"> <p>Why are the LLVM source code and the front-end distributed under different licenses?</p> @@ -185,12 +187,16 @@ GPL, as explained in the first question above.</p> </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="source">Source Code</a> </h2> <!-- *********************************************************************** --> +<div> + <div class="question"> <p>In what language is LLVM written?</p> </div> @@ -223,12 +229,16 @@ LLVM have been ported to a plethora of platforms.</p> </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="build">Build Problems</a> </h2> <!-- *********************************************************************** --> +<div> + <div class="question"> <p>When I run configure, it finds the wrong C compiler.</p> </div> @@ -435,11 +445,15 @@ Stop. <p>We regret the inconvenience.</p> </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="felangs">Source Languages</a> </h2> +<div> + <div class="question"> <p><a name="langs">What source languages are supported?</a></p> </div> @@ -540,11 +554,15 @@ Stop. Instruction</a>.</p> </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="cfe">Using the GCC Front End</a> </h2> +<div> + <div class="question"> <p>When I compile software that uses a configure script, the configure script thinks my system has all of the header files and libraries it is testing for. @@ -697,11 +715,15 @@ Stop. order to have the result conform to the platform ABI.</p> </div> +</div> + <!-- *********************************************************************** --> <h2> <a name="cfe_code">Questions about code generated by the GCC front-end</a> </h2> +<div> + <div class="question"> <p><a name="iosinit">What is this <tt>llvm.global_ctors</tt> and <tt>_GLOBAL__I__tmp_webcompile...</tt> stuff that happens when I <tt>#include @@ -907,6 +929,8 @@ F.i: </div> +</div> + <!-- *********************************************************************** --> <hr> diff --git a/docs/GettingStarted.html b/docs/GettingStarted.html index 4d41208..2bc17ea 100644 --- a/docs/GettingStarted.html +++ b/docs/GettingStarted.html @@ -155,8 +155,8 @@ also be a good place to start.</p> <li><tt>cd <i>where-you-want-to-build-llvm</i></tt></li> <li><tt>mkdir build</tt> (for building without polluting the source dir)</li> <li><tt>cd build</tt></li> - <li><tt>../llvm/configure [options]</tt></li> - Some common options: + <li><tt>../llvm/configure [options]</tt> + <br>Some common options: <ul> <li><tt>--prefix=<i>directory</i></tt> - @@ -174,7 +174,7 @@ also be a good place to start.</p> <li><tt>--enable-assertions</tt> - Compile with assertion checks enabled (default is YES).</li> </ul> - + </li> <li><tt>make [-j]</tt> - The -j specifies the number of jobs (commands) to run simultaneously. This builds both LLVM and Clang for Debug+Asserts mode. The --enabled-optimized configure option is used to specify a Release build.</li> @@ -192,7 +192,6 @@ also be a good place to start.</p> </ul> </li> - </ol> </ol> @@ -1389,7 +1388,7 @@ different <a href="#tools">tools</a>.</p> <dd> This directory contains files that describe various target architectures for code generation. For example, the <tt>llvm/lib/Target/X86</tt> directory holds the X86 machine description while - <tt>llvm/lib/Target/CBackend</tt> implements the LLVM-to-C converter.</dd> + <tt>llvm/lib/Target/ARM</tt> implements the ARM backend.</dd> <dt><tt><b>llvm/lib/CodeGen/</b></tt></dt> <dd> This directory contains the major parts of the code generator: Instruction diff --git a/docs/LLVMBuild.html b/docs/LLVMBuild.html index b069467..f39a8a6 100644 --- a/docs/LLVMBuild.html +++ b/docs/LLVMBuild.html @@ -101,7 +101,7 @@ $ROOT of project trees for things which can be checked out separately. --> <div> <p>As mentioned earlier, LLVM projects are organized into - logical <em>components</em>. Every component is typically grouped into it's + logical <em>components</em>. Every component is typically grouped into its own subdirectory. Generally, a component is organized around a coherent group of sources which have some kind of clear API separation from other parts of the code.</p> @@ -171,7 +171,7 @@ name = Linker parent = Libraries required_libraries = Archive BitReader Core Support TransformUtils </pre> - </div class="doc_code"> + </div> <p>A full description of the exact sections and properties which are allowed follows.</p> @@ -190,7 +190,7 @@ required_libraries = Archive BitReader Core Support TransformUtils number in order for files with multiple components ("component_0", "component_1", and so on).<p> - <p><b>Section names not matches this format (or the "common" section) are + <p><b>Section names not matching 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 @@ -212,7 +212,7 @@ required_libraries = Archive BitReader Core Support TransformUtils <li><i>parent</i> <b>[required]</b> <p>The name of the logical parent of the component. Components are organized into a logical tree to make it easier to navigate and organize - groups of components. The parent's have no semantics as far as the project + groups of components. The parents have no semantics as far as the project build is concerned, however. Typically, the parent will be the main component of the parent directory.</p> @@ -263,7 +263,7 @@ required_libraries = Archive BitReader Core Support TransformUtils <p>If given, a list of the names of Library or LibraryGroup components which must also be linked in whenever this library is used. That is, the link time dependencies for this component. When tools are built, - the build system will include the transitive closer of + the build system will include the transitive closure of all <i>required_libraries</i> for the components the tool needs.</p></li> <li><i>add_to_library_groups</i> <b>[optional]</b> diff --git a/docs/LangRef.html b/docs/LangRef.html index 81dabc9..9989cc8 100644 --- a/docs/LangRef.html +++ b/docs/LangRef.html @@ -103,7 +103,8 @@ <li><a href="#metadata">Metadata Nodes and Metadata Strings</a> <ol> <li><a href="#tbaa">'<tt>tbaa</tt>' Metadata</a></li> - <li><a href="#fpaccuracy">'<tt>fpaccuracy</tt>' Metadata</a></li> + <li><a href="#fpmath">'<tt>fpmath</tt>' Metadata</a></li> + <li><a href="#range">'<tt>range</tt>' Metadata</a></li> </ol> </li> </ol> @@ -2999,14 +3000,16 @@ call void @llvm.dbg.value(metadata !24, i64 0, metadata !25) <!-- _______________________________________________________________________ --> <h4> - <a name="fpaccuracy">'<tt>fpaccuracy</tt>' Metadata</a> + <a name="fpmath">'<tt>fpmath</tt>' Metadata</a> </h4> <div> -<p><tt>fpaccuracy</tt> metadata may be attached to any instruction of floating - point type. It expresses the maximum relative error of the result of - that instruction, in ULPs. ULP is defined as follows:</p> +<p><tt>fpmath</tt> metadata may be attached to any instruction of floating point + type. It can be used to express the maximum acceptable error in the result of + that instruction, in ULPs, thus potentially allowing the compiler to use a + more efficient but less accurate method of computing it. ULP is defined as + follows:</p> <blockquote> @@ -3018,18 +3021,50 @@ call void @llvm.dbg.value(metadata !24, i64 0, metadata !25) </blockquote> -<p>The maximum relative error may be any rational number. The metadata node - shall consist of a pair of unsigned integers respectively representing - the numerator and denominator. For example, 2.5 ULP:</p> +<p>The metadata node shall consist of a single positive floating point number + representing the maximum relative error, for example:</p> <div class="doc_code"> <pre> -!0 = metadata !{ i32 5, i32 2 } +!0 = metadata !{ float 2.5 } ; maximum acceptable inaccuracy is 2.5 ULPs </pre> </div> </div> +<!-- _______________________________________________________________________ --> +<h4> + <a name="range">'<tt>range</tt>' Metadata</a> +</h4> + +<div> +<p><tt>range</tt> metadata may be attached only to loads of integer types. It + expresses the possible ranges the loaded value is in. The ranges are + represented with a flattened list of integers. The loaded value is known to + be in the union of the ranges defined by each consecutive pair. Each pair + has the following properties:</p> +<ul> + <li>The type must match the type loaded by the instruction.</li> + <li>The pair <tt>a,b</tt> represents the range <tt>[a,b)</tt>.</li> + <li>Both <tt>a</tt> and <tt>b</tt> are constants.</li> + <li>The range is allowed to wrap.</li> + <li>The range should not represent the full or empty set. That is, + <tt>a!=b</tt>. </li> +</ul> + +<p>Examples:</p> +<div class="doc_code"> +<pre> + %a = load i8* %x, align 1, !range !0 ; Can only be 0 or 1 + %b = load i8* %y, align 1, !range !1 ; Can only be 255 (-1), 0 or 1 + %c = load i8* %z, align 1, !range !2 ; Can only be 0, 1, 3, 4 or 5 +... +!0 = metadata !{ i8 0, i8 2 } +!1 = metadata !{ i8 255, i8 2 } +!2 = metadata !{ i8 0, i8 2, i8 3, i8 6 } +</pre> +</div> +</div> </div> </div> diff --git a/docs/ProgrammersManual.html b/docs/ProgrammersManual.html index f4c0322..267ff92 100644 --- a/docs/ProgrammersManual.html +++ b/docs/ProgrammersManual.html @@ -1734,6 +1734,9 @@ already in the table, and each pair in the map is store in a single allocation <p>StringMap also provides query methods that take byte ranges, so it only ever copies a string if a value is inserted into the table.</p> + +<p>StringMap iteratation order, however, is not guaranteed to be deterministic, +so any uses which require that should instead use a std::map.</p> </div> <!-- _______________________________________________________________________ --> @@ -2567,7 +2570,7 @@ block but not delete it, you can use the <tt>removeFromParent()</tt> method.</p> <div> -<p><i>Replacing individual instructions</i></p> +<h5><i>Replacing individual instructions</i></h5> <p>Including "<a href="/doxygen/BasicBlockUtils_8h-source.html">llvm/Transforms/Utils/BasicBlockUtils.h</a>" permits use of two very useful replace functions: <tt>ReplaceInstWithValue</tt> @@ -2575,6 +2578,7 @@ and <tt>ReplaceInstWithInst</tt>.</p> <h5><a name="schanges_deleting">Deleting <tt>Instruction</tt>s</a></h5> +<div> <ul> <li><tt>ReplaceInstWithValue</tt> @@ -2611,7 +2615,9 @@ ReplaceInstWithInst(instToReplace->getParent()->getInstList(), ii, </pre></div></li> </ul> -<p><i>Replacing multiple uses of <tt>User</tt>s and <tt>Value</tt>s</i></p> +</div> + +<h5><i>Replacing multiple uses of <tt>User</tt>s and <tt>Value</tt>s</i></h5> <p>You can use <tt>Value::replaceAllUsesWith</tt> and <tt>User::replaceUsesOfWith</tt> to change more than one use at a time. See the @@ -3305,13 +3311,12 @@ helpful member functions that try to make common operations easy.</p> <div> <ul> - <li><tt>Module::Module(std::string name = "")</tt></li> -</ul> + <li><tt>Module::Module(std::string name = "")</tt> -<p>Constructing a <a href="#Module">Module</a> is easy. You can optionally + <p>Constructing a <a href="#Module">Module</a> is easy. You can optionally provide a name for it (probably based on the name of the translation unit).</p> + </li> -<ul> <li><tt>Module::iterator</tt> - Typedef for function list iterator<br> <tt>Module::const_iterator</tt> - Typedef for const_iterator.<br> diff --git a/docs/ReleaseNotes.html b/docs/ReleaseNotes.html index c1b1f41..54cfa20 100644 --- a/docs/ReleaseNotes.html +++ b/docs/ReleaseNotes.html @@ -206,6 +206,36 @@ Release Notes</a>.</h1> </div> + +<!--=========================================================================--> +<h3> +<a name="Polly">Polly: Polyhedral Optimizer</a> +</h3> + +<div> + + <p><a href="http://polly.llvm.org/">Polly</a> is an <em>experimental</em> + optimizer for data locality and parallelism. It currently provides high-level + loop optimizations and automatic parallelisation (using the OpenMP run time). + Work in the area of automatic SIMD and accelerator code generation was + started. + + <p>Within the LLVM 3.1 time-frame there were the following highlights:</p> + + <ul> + <li>Polly became an official LLVM project</li> + <li>Polly can be loaded directly into clang (Enabled by '-O3 -mllvm -polly' + )</li> + <li>An automatic scheduling optimizer (derived from <a + href="http://pluto-compiler.sourceforge.net/">Pluto</a>) was integrated. It + performs loop transformations to optimize for data-locality and parallelism. + The transformations include, but are not limited to interchange, fusion, + fission, skewing and tiling. + </li> + </ul> + +</div> + </div> <!-- *********************************************************************** --> @@ -269,6 +299,8 @@ Release Notes</a>.</h1> Support to model instruction bundling / packing.</li> <li><a href="#armintegratedassembler">ARM Integrated Assembler</a>, A full featured assembler and direct-to-object support for ARM.</li> + <li><a href="#blockplacement">Basic Block Placement</a> + Probability driven basic block placement.</li> <li>....</li> </ul> @@ -290,6 +322,11 @@ Release Notes</a>.</h1> <li>IR support for vectors of pointers, including vector GEPs.</li> <li>Module flags have been introduced. They convey information about the module as a whole to LLVM subsystems.</li> + <li>Loads can now have range metadata attached to them to describe the + possible values being loaded.</li> + <li>Inline cost heuristics have been completely overhauled and now closely + model constant propagation through call sites, disregard trivially dead + code costs, and can model C++ STL iterator patterns.</li> <li>....</li> </ul> </div> @@ -306,6 +343,14 @@ Release Notes</a>.</h1> optimizers:</p> <ul> + <li>The loop unroll pass now is able to unroll loops with run-time trip counts. + This feature is turned off by default, and is enabled with the + <code>-unroll-runtime</code> flag.</li> + <li>A new basic-block autovectorization pass is available. Pass + <code>-vectorize</code> to run this pass along with some associated + post-vectorization cleanup passes. For more information, see the EuroLLVM + 2012 slides: <a href="http://llvm.org/devmtg/2012-04-12/Slides/Hal_Finkel.pdf"> + Autovectorization with LLVM</a>.</li> <li>....</li> </ul> @@ -365,6 +410,25 @@ Release Notes</a>.</h1> is clobbered.</li> </ul> +<p> We added new TableGen infrastructure to support bundling for + Very Long Instruction Word (VLIW) architectures. TableGen can now + automatically generate a deterministic finite automaton from a VLIW + target's schedule description which can be queried to determine + legal groupings of instructions in a bundle.</p> + +<p> We have added a new target independent VLIW packetizer based on the + DFA infrastructure to group machine instructions into bundles.</p> + +</div> + +<h4> +<a name="blockplacement">Basic Block Placement</a> +</h4> +<div> +<p>A probability based block placement and code layout algorithm was added to +LLVM's code generator. This layout pass supports probabilities derived from +static heuristics as well as source code annotations such as +<code>__builtin_expect</code>.</p> </div> <!--=========================================================================--> @@ -382,6 +446,8 @@ Release Notes</a>.</h1> <li>Call instructions use the new register mask operands for faster compile times and better support for different calling conventions. The old WINCALL instructions are no longer needed.</li> + <li>DW2 Exception Handling is enabled on Cygwin and MinGW.</li> + <li>Support for implicit TLS model used with MS VC runtime</li> </ul> </div> @@ -401,7 +467,6 @@ Release Notes</a>.</h1> <li>On Darwin, the ARM target now has a full-featured integrated assembler. </li> </ul> -</div> <h4> <a name="armintegratedassembler">ARM Integrated Assembler</a> @@ -419,6 +484,8 @@ subtarget and CPU specific extensions for VFP2, VFP3 and NEON.</p> for details). While there is some, and growing, support for pre-unfied (divided) syntax, there are still significant gaps in that support.</p> </div> + +</div> <!--=========================================================================--> <h3> <a name="MIPS">MIPS Target Improvements</a> @@ -441,6 +508,8 @@ syntax, there are still significant gaps in that support.</p> <div> +<p>Support for Qualcomm's Hexagon VLIW processor has been added.</p> + <ul> <li>....</li> @@ -488,39 +557,39 @@ syntax, there are still significant gaps in that support.</p> <code>TargetMachine</code>. As a consequence, the associated flags will no longer be accepted by <tt>clang -mllvm</tt>. This includes: <ul> -<li><code>llvm::PrintMachineCode</code> -<li><code>llvm::NoFramePointerElim</code> -<li><code>llvm::NoFramePointerElimNonLeaf</code> -<li><code>llvm::DisableFramePointerElim(const MachineFunction &)</code> -<li><code>llvm::LessPreciseFPMADOption</code> -<li><code>llvm::LessPrecideFPMAD()</code> -<li><code>llvm::NoExcessFPPrecision</code> -<li><code>llvm::UnsafeFPMath</code> -<li><code>llvm::NoInfsFPMath</code> -<li><code>llvm::NoNaNsFPMath</code> -<li><code>llvm::HonorSignDependentRoundingFPMathOption</code> -<li><code>llvm::HonorSignDependentRoundingFPMath()</code> -<li><code>llvm::UseSoftFloat</code> -<li><code>llvm::FloatABIType</code> -<li><code>llvm::NoZerosInBSS</code> -<li><code>llvm::JITExceptionHandling</code> -<li><code>llvm::JITEmitDebugInfo</code> -<li><code>llvm::JITEmitDebugInfoToDisk</code> -<li><code>llvm::GuaranteedTailCallOpt</code> -<li><code>llvm::StackAlignmentOverride</code> -<li><code>llvm::RealignStack</code> -<li><code>llvm::DisableJumpTables</code> -<li><code>llvm::EnableFastISel</code> -<li><code>llvm::getTrapFunctionName()</code> -<li><code>llvm::EnableSegmentedStacks</code> +<li><code>llvm::PrintMachineCode</code></li> +<li><code>llvm::NoFramePointerElim</code></li> +<li><code>llvm::NoFramePointerElimNonLeaf</code></li> +<li><code>llvm::DisableFramePointerElim(const MachineFunction &)</code></li> +<li><code>llvm::LessPreciseFPMADOption</code></li> +<li><code>llvm::LessPrecideFPMAD()</code></li> +<li><code>llvm::NoExcessFPPrecision</code></li> +<li><code>llvm::UnsafeFPMath</code></li> +<li><code>llvm::NoInfsFPMath</code></li> +<li><code>llvm::NoNaNsFPMath</code></li> +<li><code>llvm::HonorSignDependentRoundingFPMathOption</code></li> +<li><code>llvm::HonorSignDependentRoundingFPMath()</code></li> +<li><code>llvm::UseSoftFloat</code></li> +<li><code>llvm::FloatABIType</code></li> +<li><code>llvm::NoZerosInBSS</code></li> +<li><code>llvm::JITExceptionHandling</code></li> +<li><code>llvm::JITEmitDebugInfo</code></li> +<li><code>llvm::JITEmitDebugInfoToDisk</code></li> +<li><code>llvm::GuaranteedTailCallOpt</code></li> +<li><code>llvm::StackAlignmentOverride</code></li> +<li><code>llvm::RealignStack</code></li> +<li><code>llvm::DisableJumpTables</code></li> +<li><code>llvm::EnableFastISel</code></li> +<li><code>llvm::getTrapFunctionName()</code></li> +<li><code>llvm::EnableSegmentedStacks</code></li> </ul></li> + <li>The MDBuilder class has been added to simplify the creation of + metadata.</li> <li>....</li> </ul> </div> -</div> - <!--=========================================================================--> <h3> <a name="tools_changes">Tools Changes</a> diff --git a/docs/SourceLevelDebugging.html b/docs/SourceLevelDebugging.html index 8072749..4f6e73a 100644 --- a/docs/SourceLevelDebugging.html +++ b/docs/SourceLevelDebugging.html @@ -425,7 +425,8 @@ height="369"> <p>These descriptors provide debug information about globals variables. The provide details such as name, type and where the variable is defined. All -global variables are collected by named metadata <tt>!llvm.dbg.gv</tt>.</p> +global variables are collected inside the named metadata +<tt>!llvm.dbg.cu</tt>.</p> </div> @@ -451,6 +452,7 @@ global variables are collected by named metadata <tt>!llvm.dbg.gv</tt>.</p> metadata, ;; Reference to type descriptor i1, ;; True if the global is local to compile unit (static) i1, ;; True if the global is defined in the compile unit (not extern) + i32, ;; Line number where the scope of the subprogram begins i32, ;; Virtuality, e.g. dwarf::DW_VIRTUALITY__virtual i32, ;; Index into a virtual function metadata, ;; indicates which base type contains the vtable pointer for the @@ -688,7 +690,8 @@ DW_TAG_inheritance = 28 <p>The members of enumeration types (tag = <tt>DW_TAG_enumeration_type</tt>) are <a href="#format_enumeration">enumerator descriptors</a>, each representing the definition of enumeration value for the set. All enumeration type - descriptors are collected by named metadata <tt>!llvm.dbg.enum</tt>.</p> + descriptors are collected inside the named metadata + <tt>!llvm.dbg.cu</tt>.</p> <p>The members of structure (tag = <tt>DW_TAG_structure_type</tt>) or union (tag = <tt>DW_TAG_union_type</tt>) types are any one of @@ -1162,44 +1165,79 @@ int MyGlobal = 100; ;; ;; List of debug info of globals ;; -!llvm.dbg.gv = !{!0} +!llvm.dbg.cu = !{!0} -;; -;; Define the global variable descriptor. Note the reference to the global -;; variable anchor and the global variable itself. -;; +;; Define the compile unit. !0 = metadata !{ - i32 524340, ;; Tag - i32 0, ;; Unused - metadata !1, ;; Context - metadata !"MyGlobal", ;; Name - metadata !"MyGlobal", ;; Display Name - metadata !"MyGlobal", ;; Linkage Name - metadata !3, ;; Compile Unit - i32 1, ;; Line Number - metadata !4, ;; Type - i1 false, ;; Is a local variable - i1 true, ;; Is this a definition - i32* @MyGlobal ;; The global variable + i32 786449, ;; Tag + i32 0, ;; Context + i32 4, ;; Language + metadata !"foo.cpp", ;; File + metadata !"/Volumes/Data/tmp", ;; Directory + metadata !"clang version 3.1 ", ;; Producer + i1 true, ;; Deprecated field + i1 false, ;; "isOptimized"? + metadata !"", ;; Flags + i32 0, ;; Runtime Version + metadata !1, ;; Enum Types + metadata !1, ;; Retained Types + metadata !1, ;; Subprograms + metadata !3 ;; Global Variables +} ; [ DW_TAG_compile_unit ] + +;; The Array of Global Variables +!3 = metadata !{ + metadata !4 } -;; -;; Define the basic type of 32 bit signed integer. Note that since int is an -;; intrinsic type the source file is NULL and line 0. -;; !4 = metadata !{ - i32 524324, ;; Tag - metadata !1, ;; Context - metadata !"int", ;; Name - metadata !1, ;; File - i32 0, ;; Line number - i64 32, ;; Size in Bits - i64 32, ;; Align in Bits - i64 0, ;; Offset in Bits - i32 0, ;; Flags - i32 5 ;; Encoding + metadata !5 } +;; +;; Define the global variable itself. +;; +!5 = metadata !{ + i32 786484, ;; Tag + i32 0, ;; Unused + null, ;; Unused + metadata !"MyGlobal", ;; Name + metadata !"MyGlobal", ;; Display Name + metadata !"", ;; Linkage Name + metadata !6, ;; File + i32 1, ;; Line + metadata !7, ;; Type + i32 0, ;; IsLocalToUnit + i32 1, ;; IsDefinition + i32* @MyGlobal ;; LLVM-IR Value +} ; [ DW_TAG_variable ] + +;; +;; Define the file +;; +!6 = metadata !{ + i32 786473, ;; Tag + metadata !"foo.cpp", ;; File + metadata !"/Volumes/Data/tmp", ;; Directory + null ;; Unused +} ; [ DW_TAG_file_type ] + +;; +;; Define the type +;; +!7 = metadata !{ + i32 786468, ;; Tag + null, ;; Unused + metadata !"int", ;; Name + null, ;; Unused + i32 0, ;; Line + i64 32, ;; Size in Bits + i64 32, ;; Align in Bits + i64 0, ;; Offset + i32 0, ;; Flags + i32 5 ;; Encoding +} ; [ DW_TAG_base_type ] + </pre> </div> @@ -2129,14 +2167,13 @@ The DWARF for this would be: </div> </div> -</div> -<div> <!-- ======================================================================= --> <h3> <a name="acceltable">Name Accelerator Tables</a> </h3> <!-- ======================================================================= --> +<div> <!-- ======================================================================= --> <h4> <a name="acceltableintroduction">Introduction</a> @@ -2805,6 +2842,7 @@ int main () </ul> </div> </div> +</div> <!-- *********************************************************************** --> diff --git a/docs/TableGenFundamentals.html b/docs/TableGenFundamentals.html index 45baf19..b401c7a 100644 --- a/docs/TableGenFundamentals.html +++ b/docs/TableGenFundamentals.html @@ -420,7 +420,7 @@ which case the user must specify it explicitly.</dd> <dt><tt>str1#str2</tt></dt> <dd>"#" (paste) is a shorthand for !strconcat. It may concatenate things that are not quoted strings, in which case an implicit - !cast<string> is done on the operand of the paste.</dd> + !cast<string> is done on the operand of the paste.</dd> <dt><tt>!cast<type>(a)</tt></dt> <dd>A symbol of type <em>type</em> obtained by looking up the string 'a' in the symbol table. If the type of 'a' does not match <em>type</em>, TableGen diff --git a/docs/TestingGuide.html b/docs/TestingGuide.html index fe5d836..233a157 100644 --- a/docs/TestingGuide.html +++ b/docs/TestingGuide.html @@ -299,15 +299,15 @@ clang/test directory. </p> you.</p> <p>In order for the regression tests to work, each directory of tests must - have a <tt>dg.exp</tt> file. Lit looks for this file to determine how to - run the tests. This file is just a Tcl script and it can do anything you want, + have a <tt>lit.local.cfg</tt> file. Lit looks for this file to determine how + to run the tests. This file is just Python code and thus is very flexible, but we've standardized it for the LLVM regression tests. If you're adding a - directory of tests, just copy <tt>dg.exp</tt> from another directory to get - running. The standard <tt>dg.exp</tt> simply loads a Tcl library - (<tt>test/lib/llvm.exp</tt>) and calls the <tt>llvm_runtests</tt> function - defined in that library with a list of file names to run. The names are - obtained by using Tcl's glob command. Any directory that contains only - directories does not need the <tt>dg.exp</tt> file.</p> + directory of tests, just copy <tt>lit.local.cfg</tt> from another directory to + get running. The standard <tt>lit.local.cfg</tt> simply specifies which files + to look in for tests. Any directory that contains only directories does not + need the <tt>lit.local.cfg</tt> file. Read the + <a href="http://llvm.org/cmds/lit.html">Lit documentation</a> for more + information. </p> <p>The <tt>llvm-runtests</tt> function looks at each file that is passed to it and gathers any lines together that match "RUN:". These are the "RUN" lines @@ -473,7 +473,7 @@ negatives).</p> llc, then pipe the output of llc into FileCheck. This means that FileCheck will be verifying its standard input (the llc output) against the filename argument specified (the original .ll file specified by "%s"). To see how this works, -lets look at the rest of the .ll file (after the RUN line):</p> +let's look at the rest of the .ll file (after the RUN line):</p> <div class="doc_code"> <pre> @@ -889,8 +889,6 @@ understand the Makefile based setup.</p> the <a href="TestSuiteMakefileGuide.html">Test Suite Makefile Guide.</a></p> </div> -</div> - <!-- *********************************************************************** --> <hr> diff --git a/docs/WritingAnLLVMPass.html b/docs/WritingAnLLVMPass.html index 66b98b6..c7cad4b 100644 --- a/docs/WritingAnLLVMPass.html +++ b/docs/WritingAnLLVMPass.html @@ -417,17 +417,17 @@ USAGE: opt [options] <input bitcode> OPTIONS: Optimizations available: ... - -funcresolve - Resolve Functions - -gcse - Global Common Subexpression Elimination - -globaldce - Dead Global Elimination - <b>-hello - Hello World Pass</b> - -indvars - Canonicalize Induction Variables - -inline - Function Integration/Inlining - -instcombine - Combine redundant instructions + -globalopt - Global Variable Optimizer + -globalsmodref-aa - Simple mod/ref analysis for globals + -gvn - Global Value Numbering + <b>-hello - Hello World Pass</b> + -indvars - Induction Variable Simplification + -inline - Function Integration/Inlining + -insert-edge-profiling - Insert instrumentation for edge profiling ... </pre></div> -<p>The pass name get added as the information string for your pass, giving some +<p>The pass name gets added as the information string for your pass, giving some documentation to users of <tt>opt</tt>. Now that you have a working pass, you would go ahead and make it do the cool transformations you want. Once you get it all working and tested, it may become useful to find out how fast your pass @@ -545,7 +545,7 @@ following signature:</p> <div> <div class="doc_code"><pre> - <b>virtual bool</b> runOnModule(Module &M) = 0; +<b>virtual bool</b> runOnModule(Module &M) = 0; </pre></div> <p>The <tt>runOnModule</tt> method performs the interesting work of the pass. @@ -612,7 +612,7 @@ false if they didn't.</p> <div> <div class="doc_code"><pre> - <b>virtual bool</b> doInitialization(CallGraph &CG); +<b>virtual bool</b> doInitialization(CallGraph &CG); </pre></div> <p>The <tt>doIninitialize</tt> method is allowed to do most of the things that @@ -633,7 +633,7 @@ fast).</p> <div> <div class="doc_code"><pre> - <b>virtual bool</b> runOnSCC(CallGraphSCC &SCC) = 0; +<b>virtual bool</b> runOnSCC(CallGraphSCC &SCC) = 0; </pre></div> <p>The <tt>runOnSCC</tt> method performs the interesting work of the pass, and @@ -652,7 +652,7 @@ otherwise.</p> <div> <div class="doc_code"><pre> - <b>virtual bool</b> doFinalization(CallGraph &CG); +<b>virtual bool</b> doFinalization(CallGraph &CG); </pre></div> <p>The <tt>doFinalization</tt> method is an infrequently used method that is @@ -704,7 +704,7 @@ should return true if they modified the program, or false if they didn't.</p> <div> <div class="doc_code"><pre> - <b>virtual bool</b> doInitialization(Module &M); +<b>virtual bool</b> doInitialization(Module &M); </pre></div> <p>The <tt>doIninitialize</tt> method is allowed to do most of the things that @@ -732,7 +732,7 @@ free functions that it needs, adding prototypes to the module if necessary.</p> <div> <div class="doc_code"><pre> - <b>virtual bool</b> runOnFunction(Function &F) = 0; +<b>virtual bool</b> runOnFunction(Function &F) = 0; </pre></div><p> <p>The <tt>runOnFunction</tt> method must be implemented by your subclass to do @@ -751,7 +751,7 @@ be returned if the function is modified.</p> <div> <div class="doc_code"><pre> - <b>virtual bool</b> doFinalization(Module &M); +<b>virtual bool</b> doFinalization(Module &M); </pre></div> <p>The <tt>doFinalization</tt> method is an infrequently used method that is @@ -790,7 +790,7 @@ program, or false if they didn't. </p> <div> <div class="doc_code"><pre> - <b>virtual bool</b> doInitialization(Loop *, LPPassManager &LPM); +<b>virtual bool</b> doInitialization(Loop *, LPPassManager &LPM); </pre></div> <p>The <tt>doInitialization</tt> method is designed to do simple initialization @@ -811,7 +811,7 @@ information.</p> <div> <div class="doc_code"><pre> - <b>virtual bool</b> runOnLoop(Loop *, LPPassManager &LPM) = 0; +<b>virtual bool</b> runOnLoop(Loop *, LPPassManager &LPM) = 0; </pre></div><p> <p>The <tt>runOnLoop</tt> method must be implemented by your subclass to do @@ -829,7 +829,7 @@ should be used to update loop nest.</p> <div> <div class="doc_code"><pre> - <b>virtual bool</b> doFinalization(); +<b>virtual bool</b> doFinalization(); </pre></div> <p>The <tt>doFinalization</tt> method is an infrequently used method that is @@ -869,7 +869,7 @@ methods should return true if they modified the program, or false if they didn n <div> <div class="doc_code"><pre> - <b>virtual bool</b> doInitialization(Region *, RGPassManager &RGM); +<b>virtual bool</b> doInitialization(Region *, RGPassManager &RGM); </pre></div> <p>The <tt>doInitialization</tt> method is designed to do simple initialization @@ -890,7 +890,7 @@ information.</p> <div> <div class="doc_code"><pre> - <b>virtual bool</b> runOnRegion(Region *, RGPassManager &RGM) = 0; +<b>virtual bool</b> runOnRegion(Region *, RGPassManager &RGM) = 0; </pre></div><p> <p>The <tt>runOnRegion</tt> method must be implemented by your subclass to do @@ -908,7 +908,7 @@ should be used to update region tree.</p> <div> <div class="doc_code"><pre> - <b>virtual bool</b> doFinalization(); +<b>virtual bool</b> doFinalization(); </pre></div> <p>The <tt>doFinalization</tt> method is an infrequently used method that is @@ -957,7 +957,7 @@ href="#FunctionPass"><tt>FunctionPass</tt></a>'s have, but also have the followi <div> <div class="doc_code"><pre> - <b>virtual bool</b> doInitialization(Function &F); +<b>virtual bool</b> doInitialization(Function &F); </pre></div> <p>The <tt>doIninitialize</tt> method is allowed to do most of the things that @@ -978,7 +978,7 @@ fast).</p> <div> <div class="doc_code"><pre> - <b>virtual bool</b> runOnBasicBlock(BasicBlock &BB) = 0; +<b>virtual bool</b> runOnBasicBlock(BasicBlock &BB) = 0; </pre></div> <p>Override this function to do the work of the <tt>BasicBlockPass</tt>. This @@ -998,7 +998,7 @@ if the basic block is modified.</p> <div> <div class="doc_code"><pre> - <b>virtual bool</b> doFinalization(Function &F); +<b>virtual bool</b> doFinalization(Function &F); </pre></div> <p>The <tt>doFinalization</tt> method is an infrequently used method that is @@ -1051,7 +1051,7 @@ data)</li> <div> <div class="doc_code"><pre> - <b>virtual bool</b> runOnMachineFunction(MachineFunction &MF) = 0; +<b>virtual bool</b> runOnMachineFunction(MachineFunction &MF) = 0; </pre></div> <p><tt>runOnMachineFunction</tt> can be considered the main entry point of a @@ -1104,7 +1104,7 @@ implement the virtual <tt>print</tt> method:</p> <div> <div class="doc_code"><pre> - <b>virtual void</b> print(std::ostream &O, <b>const</b> Module *M) <b>const</b>; +<b>virtual void</b> print(std::ostream &O, <b>const</b> Module *M) <b>const</b>; </pre></div> <p>The <tt>print</tt> method must be implemented by "analyses" in order to print @@ -1154,7 +1154,7 @@ having any prerequisite passes, and invalidating <b>all</b> other passes.</p> <div> <div class="doc_code"><pre> - <b>virtual void</b> getAnalysisUsage(AnalysisUsage &Info) <b>const</b>; +<b>virtual void</b> getAnalysisUsage(AnalysisUsage &Info) <b>const</b>; </pre></div> <p>By implementing the <tt>getAnalysisUsage</tt> method, the required and @@ -1242,11 +1242,11 @@ the fact that it hacks on the CFG. <div> <div class="doc_code"><pre> - <i>// This example modifies the program, but does not modify the CFG</i> - <b>void</b> <a href="http://llvm.org/doxygen/structLICM.html">LICM</a>::getAnalysisUsage(AnalysisUsage &AU) <b>const</b> { - AU.setPreservesCFG(); - AU.addRequired<<a href="http://llvm.org/doxygen/classllvm_1_1LoopInfo.html">LoopInfo</a>>(); - } +<i>// This example modifies the program, but does not modify the CFG</i> +<b>void</b> <a href="http://llvm.org/doxygen/structLICM.html">LICM</a>::getAnalysisUsage(AnalysisUsage &AU) <b>const</b> { + AU.setPreservesCFG(); + AU.addRequired<<a href="http://llvm.org/doxygen/classllvm_1_1LoopInfo.html">LoopInfo</a>>(); +} </pre></div> </div> @@ -1268,10 +1268,10 @@ method. It takes a single template argument that specifies which pass class you want, and returns a reference to that pass. For example:</p> <div class="doc_code"><pre> - bool LICM::runOnFunction(Function &F) { - LoopInfo &LI = getAnalysis<LoopInfo>(); - ... - } +bool LICM::runOnFunction(Function &F) { + LoopInfo &LI = getAnalysis<LoopInfo>(); + ... +} </pre></div> <p>This method call returns a reference to the pass desired. You may get a @@ -1285,11 +1285,11 @@ A module level pass can use function level analysis info using this interface. For example:</p> <div class="doc_code"><pre> - bool ModuleLevelPass::runOnModule(Module &M) { - ... - DominatorTree &DT = getAnalysis<DominatorTree>(Func); - ... - } +bool ModuleLevelPass::runOnModule(Module &M) { + ... + DominatorTree &DT = getAnalysis<DominatorTree>(Func); + ... +} </pre></div> <p>In above example, runOnFunction for DominatorTree is called by pass manager @@ -1302,11 +1302,11 @@ If your pass is capable of updating analyses if they exist (e.g., if it is active. For example:</p> <div class="doc_code"><pre> - ... - if (DominatorSet *DS = getAnalysisIfAvailable<DominatorSet>()) { - <i>// A DominatorSet is active. This code will update it.</i> - } - ... +... +if (DominatorSet *DS = getAnalysisIfAvailable<DominatorSet>()) { + <i>// A DominatorSet is active. This code will update it.</i> +} +... </pre></div> </div> @@ -1405,7 +1405,7 @@ Unlike registration of passes, there is no command line argument to be specified for the Analysis Group Interface itself, because it is "abstract":</p> <div class="doc_code"><pre> - <b>static</b> RegisterAnalysisGroup<<a href="http://llvm.org/doxygen/classllvm_1_1AliasAnalysis.html">AliasAnalysis</a>> A("<i>Alias Analysis</i>"); +<b>static</b> RegisterAnalysisGroup<<a href="http://llvm.org/doxygen/classllvm_1_1AliasAnalysis.html">AliasAnalysis</a>> A("<i>Alias Analysis</i>"); </pre></div> <p>Once the analysis is registered, passes can declare that they are valid @@ -1416,10 +1416,9 @@ implementations of the interface by using the following code:</p> //<i> Declare that we implement the AliasAnalysis interface</i> INITIALIZE_AG_PASS(FancyAA, <a href="http://llvm.org/doxygen/classllvm_1_1AliasAnalysis.html">AliasAnalysis</a>, "<i>somefancyaa</i>", "<i>A more complex alias analysis implementation</i>", - false, // <i>Is CFG Only?</i> - true, // <i>Is Analysis?</i> - false, // <i>Is default Analysis Group implementation?</i> - ); + false, // <i>Is CFG Only?</i> + true, // <i>Is Analysis?</i> + false); // <i>Is default Analysis Group implementation?</i> } </pre></div> @@ -1436,8 +1435,7 @@ this macro.</p> "<i>Basic Alias Analysis (default AA impl)</i>", false, // <i>Is CFG Only?</i> true, // <i>Is Analysis?</i> - true, // <i>Is default Analysis Group implementation?</i> - ); + true); // <i>Is default Analysis Group implementation?</i> } </pre></div> @@ -1606,10 +1604,10 @@ we need to add the following <a href="#getAnalysisUsage"><tt>getAnalysisUsage</tt></a> method to our pass:</p> <div class="doc_code"><pre> - <i>// We don't modify the program, so we preserve all analyses</i> - <b>virtual void</b> getAnalysisUsage(AnalysisUsage &AU) <b>const</b> { - AU.setPreservesAll(); - } +<i>// We don't modify the program, so we preserve all analyses</i> +<b>virtual void</b> getAnalysisUsage(AnalysisUsage &AU) <b>const</b> { + AU.setPreservesAll(); +} </pre></div> <p>Now when we run our pass, we get this output:</p> @@ -1717,19 +1715,19 @@ machine passes. Here we will describe how to <i>register</i> a register allocator machine pass.</p> <p>Implement your register allocator machine pass. In your register allocator -.cpp file add the following include;</p> +<tt>.cpp</tt> file add the following include;</p> <div class="doc_code"><pre> - #include "llvm/CodeGen/RegAllocRegistry.h" +#include "llvm/CodeGen/RegAllocRegistry.h" </pre></div> <p>Also in your register allocator .cpp file, define a creator function in the form; </p> <div class="doc_code"><pre> - FunctionPass *createMyRegisterAllocator() { - return new MyRegisterAllocator(); - } +FunctionPass *createMyRegisterAllocator() { + return new MyRegisterAllocator(); +} </pre></div> <p>Note that the signature of this function should match the type of @@ -1737,9 +1735,9 @@ form; </p> "installing" declaration, in the form;</p> <div class="doc_code"><pre> - static RegisterRegAlloc myRegAlloc("myregalloc", - " my register allocator help string", - createMyRegisterAllocator); +static RegisterRegAlloc myRegAlloc("myregalloc", + "my register allocator help string", + createMyRegisterAllocator); </pre></div> <p>Note the two spaces prior to the help string produces a tidy result on the @@ -1790,11 +1788,11 @@ MachinePassRegistry RegisterMyPasses::Registry; <p>And finally, declare the command line option for your passes. Example:</p> <div class="doc_code"><pre> - cl::opt<RegisterMyPasses::FunctionPassCtor, false, - RegisterPassParser<RegisterMyPasses> > - MyPassOpt("mypass", - cl::init(&createDefaultMyPass), - cl::desc("my pass option help")); +cl::opt<RegisterMyPasses::FunctionPassCtor, false, + RegisterPassParser<RegisterMyPasses> > +MyPassOpt("mypass", + cl::init(&createDefaultMyPass), + cl::desc("my pass option help")); </pre></div> <p>Here the command option is "mypass", with createDefaultMyPass as the default |