From: Daniel Dunbar Date: Tue, 8 May 2012 17:48:21 +0000 (+0000) Subject: [docs] Remove POD based man page docs (and build system support). X-Git-Url: http://demsky.eecs.uci.edu/git/?a=commitdiff_plain;h=a5d2435409858728970202226d0bbbee508fe408;p=oota-llvm.git [docs] Remove POD based man page docs (and build system support). - Currently this leaves us with less build system support (e.g., installing man pages) for the docs than is desired. I'm working on fixing this, but it may take a while. If someone finds this particularly egregious let me know and I will prioritize it. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156389 91177308-0d34-0410-b5e6-96231b3b80d8 --- diff --git a/autoconf/configure.ac b/autoconf/configure.ac index 9d066ff1d74..0f488ab5994 100644 --- a/autoconf/configure.ac +++ b/autoconf/configure.ac @@ -1028,8 +1028,6 @@ AC_PATH_PROG(CAT, [cat]) AC_PATH_PROG(DOXYGEN, [doxygen]) AC_PATH_PROG(GROFF, [groff]) AC_PATH_PROG(GZIPBIN, [gzip]) -AC_PATH_PROG(POD2HTML, [pod2html]) -AC_PATH_PROG(POD2MAN, [pod2man]) AC_PATH_PROG(PDFROFF, [pdfroff]) AC_PATH_PROG(RUNTEST, [runtest]) DJ_AC_PATH_TCLSH diff --git a/docs/CommandGuide/FileCheck.pod b/docs/CommandGuide/FileCheck.pod deleted file mode 100644 index 2662cc01288..00000000000 --- a/docs/CommandGuide/FileCheck.pod +++ /dev/null @@ -1,245 +0,0 @@ - -=pod - -=head1 NAME - -FileCheck - Flexible pattern matching file verifier - -=head1 SYNOPSIS - -B I [I<--check-prefix=XXX>] [I<--strict-whitespace>] - -=head1 DESCRIPTION - -B reads two files (one from standard input, and one specified on the -command line) and uses one to verify the other. This behavior is particularly -useful for the testsuite, which wants to verify that the output of some tool -(e.g. llc) contains the expected information (for example, a movsd from esp or -whatever is interesting). This is similar to using grep, but it is optimized -for matching multiple different inputs in one file in a specific order. - -The I file specifies the file that contains the patterns to -match. The file to verify is always read from standard input. - -=head1 OPTIONS - -=over - -=item B<-help> - -Print a summary of command line options. - -=item B<--check-prefix> I - -FileCheck searches the contents of I for patterns to match. By -default, these patterns are prefixed with "CHECK:". If you'd like to use a -different prefix (e.g. because the same input file is checking multiple -different tool or options), the B<--check-prefix> argument allows you to specify -a specific prefix to match. - -=item B<--strict-whitespace> - -By default, FileCheck canonicalizes input horizontal whitespace (spaces and -tabs) which causes it to ignore these differences (a space will match a tab). -The --strict-whitespace argument disables this behavior. - -=item B<-version> - -Show the version number of this program. - -=back - -=head1 EXIT STATUS - -If B verifies that the file matches the expected contents, it exits -with 0. Otherwise, if not, or if an error occurs, it will exit with a non-zero -value. - -=head1 TUTORIAL - -FileCheck is typically used from LLVM regression tests, being invoked on the RUN -line of the test. A simple example of using FileCheck from a RUN line looks -like this: - - ; RUN: llvm-as < %s | llc -march=x86-64 | FileCheck %s - -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, -let's look at the rest of the .ll file (after the RUN line): - - define void @sub1(i32* %p, i32 %v) { - entry: - ; 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: - ; CHECK: inc4: - ; CHECK: incq - %0 = tail call i64 @llvm.atomic.load.add.i64.p0i64(i64* %p, i64 1) - ret void - } - -Here you can see some "CHECK:" lines specified in comments. Now you can see -how the file is piped into llvm-as, then llc, and the machine code output is -what we are verifying. FileCheck checks the machine code output to verify that -it matches what the "CHECK:" lines specify. - -The syntax of the CHECK: lines is very simple: they are fixed strings that -must occur in order. FileCheck defaults to ignoring horizontal whitespace -differences (e.g. a space is allowed to match a tab) but otherwise, the contents -of the CHECK: line is required to match some thing in the test file exactly. - -One nice thing about FileCheck (compared to grep) is that it allows merging -test cases together into logical groups. For example, because the test above -is checking for the "sub1:" and "inc4:" labels, it will not match unless there -is a "subl" in between those labels. If it existed somewhere else in the file, -that would not count: "grep subl" matches if subl exists anywhere in the -file. - - - -=head2 The FileCheck -check-prefix option - -The FileCheck -check-prefix option allows multiple test configurations to be -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: | FileCheck %s -check-prefix=X32> - ; RUN: llvm-as < %s | llc -mtriple=x86_64-apple-darwin9 -mattr=sse41 \ - ; 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 - ; X32: pinsrd_1: - ; X32: pinsrd $1, 4(%esp), %xmm0 - - ; X64: pinsrd_1: - ; X64: pinsrd $1, %edi, %xmm0 - } - -In this case, we're testing that we get the expected code generation with -both 32-bit and 64-bit code generation. - - - -=head2 The "CHECK-NEXT:" directive - -Sometimes you want to match lines and would like to verify that matches -happen on exactly consecutive lines with no other lines in between them. In -this case, you can use CHECK: and CHECK-NEXT: directives to specify this. If -you specified a custom check prefix, just use "-NEXT:". For -example, something like this works as you'd expect: - - define void @t2(<2 x double>* %r, <2 x double>* %A, double %B) { - %tmp3 = load <2 x double>* %A, align 16 - %tmp7 = insertelement <2 x double> undef, double %B, i32 0 - %tmp9 = shufflevector <2 x double> %tmp3, - <2 x double> %tmp7, - <2 x i32> < i32 0, i32 2 > - store <2 x double> %tmp9, <2 x double>* %r, align 16 - ret void - - ; 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 -between it an the previous directive. A CHECK-NEXT cannot be the first -directive in a file. - - - -=head2 The "CHECK-NOT:" directive - -The CHECK-NOT: directive is used to verify that a string doesn't occur -between two matches (or before the first match, or after the last match). For -example, to verify that a load is removed by a transformation, a test like this -can be used: - - define i8 @coerce_offset0(i32 %V, i32* %P) { - store i32 %V, i32* %P - - %P2 = bitcast i32* %P to i8* - %P3 = getelementptr i8* %P2, i32 2 - - %A = load i8* %P3 - ret i8 %A - ; CHECK: @coerce_offset0 - ; CHECK-NOT: load - ; CHECK: ret i8 - } - - - -=head2 FileCheck Pattern Matching Syntax - -The CHECK: and CHECK-NOT: directives both take a pattern to match. For most -uses of FileCheck, fixed string matching is perfectly sufficient. For some -things, a more flexible form of matching is desired. To support this, FileCheck -allows you to specify regular expressions in matching strings, surrounded by -double braces: B<{{yourregex}}>. Because we want to use fixed string -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 {{[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. - -Because regular expressions are enclosed with double braces, they are -visually distinct, and you don't need to use escape characters within the double -braces like you would in C. In the rare case that you want to match double -braces explicitly from the input, you can use something ugly like -B<{{[{][{]}}> as your pattern. - - - -=head2 FileCheck Variables - -It is often useful to match a pattern and then verify that it occurs again -later in the file. For codegen tests, this can be useful to allow any register, -but verify that that register is used consistently later. To do this, FileCheck -allows named variables to be defined and substituted into patterns. Here is a -simple example: - - ; CHECK: test5: - ; CHECK: notw [[REGISTER:%[a-z]+]] - ; CHECK: andw {{.*}}[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 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 -"B", 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 -define two separate CHECK lines that match on the same line. - - - -=head1 AUTHORS - -Maintained by The LLVM Team (L). - -=cut diff --git a/docs/CommandGuide/Makefile b/docs/CommandGuide/Makefile deleted file mode 100644 index 3f9f60b8e7f..00000000000 --- a/docs/CommandGuide/Makefile +++ /dev/null @@ -1,103 +0,0 @@ -##===- docs/CommandGuide/Makefile --------------------------*- Makefile -*-===## -# -# The LLVM Compiler Infrastructure -# -# This file is distributed under the University of Illinois Open Source -# License. See LICENSE.TXT for details. -# -##===----------------------------------------------------------------------===## - -ifdef BUILD_FOR_WEBSITE -# This special case is for keeping the CommandGuide on the LLVM web site -# up to date automatically as the documents are checked in. It must build -# the POD files to HTML only and keep them in the src directories. It must also -# build in an unconfigured tree, hence the ifdef. To use this, run -# make -s BUILD_FOR_WEBSITE=1 inside the cvs commit script. -SRC_DOC_DIR= -DST_HTML_DIR=html/ -DST_MAN_DIR=man/man1/ -DST_PS_DIR=ps/ - -# If we are in BUILD_FOR_WEBSITE mode, default to the all target. -all:: html man ps - -clean: - rm -f pod2htm*.*~~ $(HTML) $(MAN) $(PS) - -# To create other directories, as needed, and timestamp their creation -%/.dir: - -mkdir $* > /dev/null - date > $@ - -else - -# Otherwise, if not in BUILD_FOR_WEBSITE mode, use the project info. -LEVEL := ../.. -include $(LEVEL)/Makefile.common - -SRC_DOC_DIR=$(PROJ_SRC_DIR)/ -DST_HTML_DIR=$(PROJ_OBJ_DIR)/ -DST_MAN_DIR=$(PROJ_OBJ_DIR)/ -DST_PS_DIR=$(PROJ_OBJ_DIR)/ - -endif - - -POD := $(wildcard $(SRC_DOC_DIR)*.pod) -HTML := $(patsubst $(SRC_DOC_DIR)%.pod, $(DST_HTML_DIR)%.html, $(POD)) -MAN := $(patsubst $(SRC_DOC_DIR)%.pod, $(DST_MAN_DIR)%.1, $(POD)) -PS := $(patsubst $(SRC_DOC_DIR)%.pod, $(DST_PS_DIR)%.ps, $(POD)) - -# The set of man pages we will not install -NO_INSTALL_MANS = $(DST_MAN_DIR)FileCheck.1 $(DST_MAN_DIR)llvm-build.1 - -# The set of man pages that we will install -INSTALL_MANS = $(filter-out $(NO_INSTALL_MANS), $(MAN)) - -.SUFFIXES: -.SUFFIXES: .html .pod .1 .ps - -$(DST_HTML_DIR)%.html: %.pod $(DST_HTML_DIR)/.dir - pod2html --css=manpage.css --htmlroot=. \ - --podpath=. --noindex --infile=$< --outfile=$@ --title=$* - -$(DST_MAN_DIR)%.1: %.pod $(DST_MAN_DIR)/.dir - pod2man --release=CVS --center="LLVM Command Guide" $< $@ - -$(DST_PS_DIR)%.ps: $(DST_MAN_DIR)%.1 $(DST_PS_DIR)/.dir - groff -Tps -man $< > $@ - - -html: $(HTML) -man: $(MAN) -ps: $(PS) - -EXTRA_DIST := $(POD) index.html - -clean-local:: - $(Verb) $(RM) -f pod2htm*.*~~ $(HTML) $(MAN) $(PS) - -HTML_DIR := $(DESTDIR)$(PROJ_docsdir)/html/CommandGuide -MAN_DIR := $(DESTDIR)$(PROJ_mandir)/man1 -PS_DIR := $(DESTDIR)$(PROJ_docsdir)/ps - -install-local:: $(HTML) $(INSTALL_MANS) $(PS) - $(Echo) Installing HTML CommandGuide Documentation - $(Verb) $(MKDIR) $(HTML_DIR) - $(Verb) $(DataInstall) $(HTML) $(HTML_DIR) - $(Verb) $(DataInstall) $(PROJ_SRC_DIR)/index.html $(HTML_DIR) - $(Verb) $(DataInstall) $(PROJ_SRC_DIR)/manpage.css $(HTML_DIR) - $(Echo) Installing MAN CommandGuide Documentation - $(Verb) $(MKDIR) $(MAN_DIR) - $(Verb) $(DataInstall) $(INSTALL_MANS) $(MAN_DIR) - $(Echo) Installing PS CommandGuide Documentation - $(Verb) $(MKDIR) $(PS_DIR) - $(Verb) $(DataInstall) $(PS) $(PS_DIR) - -uninstall-local:: - $(Echo) Uninstalling CommandGuide Documentation - $(Verb) $(RM) -rf $(HTML_DIR) $(MAN_DIR) $(PS_DIR) - -printvars:: - $(Echo) "POD : " '$(POD)' - $(Echo) "HTML : " '$(HTML)' diff --git a/docs/CommandGuide/bugpoint.pod b/docs/CommandGuide/bugpoint.pod deleted file mode 100644 index f7a3ec7624a..00000000000 --- a/docs/CommandGuide/bugpoint.pod +++ /dev/null @@ -1,186 +0,0 @@ -=pod - -=head1 NAME - -bugpoint - automatic test case reduction tool - -=head1 SYNOPSIS - -B [I] [I] [I] B<--args> -I - -=head1 DESCRIPTION - -B narrows down the source of problems in LLVM tools and passes. It -can be used to debug three types of failures: optimizer crashes, miscompilations -by optimizers, or bad native code generation (including problems in the static -and JIT compilers). It aims to reduce large test cases to small, useful ones. -For more information on the design and inner workings of B, as well as -advice for using bugpoint, see F in the LLVM -distribution. - -=head1 OPTIONS - -=over - -=item B<--additional-so> F - -Load the dynamic shared object F into the test program whenever it is -run. This is useful if you are debugging programs which depend on non-LLVM -libraries (such as the X or curses libraries) to run. - -=item B<--append-exit-code>=I<{true,false}> - -Append the test programs exit code to the output file so that a change in exit -code is considered a test failure. Defaults to false. - -=item B<--args> I - -Pass all arguments specified after -args to the test program whenever it runs. -Note that if any of the I start with a '-', you should use: - - bugpoint [bugpoint args] --args -- [program args] - -The "--" right after the B<--args> option tells B to consider any -options starting with C<-> to be part of the B<--args> option, not as options to -B itself. - -=item B<--tool-args> I - -Pass all arguments specified after --tool-args to the LLVM tool under test -(B, B, etc.) whenever it runs. You should use this option in the -following way: - - bugpoint [bugpoint args] --tool-args -- [tool args] - -The "--" right after the B<--tool-args> option tells B to consider any -options starting with C<-> to be part of the B<--tool-args> option, not as -options to B itself. (See B<--args>, above.) - -=item B<--safe-tool-args> I - -Pass all arguments specified after B<--safe-tool-args> to the "safe" execution -tool. - -=item B<--gcc-tool-args> I - -Pass all arguments specified after B<--gcc-tool-args> to the invocation of -B. - -=item B<--opt-args> I - -Pass all arguments specified after B<--opt-args> to the invocation of B. - -=item B<--disable-{dce,simplifycfg}> - -Do not run the specified passes to clean up and reduce the size of the test -program. By default, B uses these passes internally when attempting to -reduce test programs. If you're trying to find a bug in one of these passes, -B may crash. - -=item B<--enable-valgrind> - -Use valgrind to find faults in the optimization phase. This will allow -bugpoint to find otherwise asymptomatic problems caused by memory -mis-management. - -=item B<-find-bugs> - -Continually randomize the specified passes and run them on the test program -until a bug is found or the user kills B. - -=item B<-help> - -Print a summary of command line options. - -=item B<--input> F - -Open F and redirect the standard input of the test program, whenever -it runs, to come from that file. - -=item B<--load> F - -Load the dynamic object F into B itself. This object should -register new optimization passes. Once loaded, the object will add new command -line options to enable various optimizations. To see the new complete list of -optimizations, use the B<-help> and B<--load> options together; for example: - - bugpoint --load myNewPass.so -help - -=item B<--mlimit> F - -Specifies an upper limit on memory usage of the optimization and codegen. Set -to zero to disable the limit. - -=item B<--output> F - -Whenever the test program produces output on its standard output stream, it -should match the contents of F (the "reference output"). If you -do not use this option, B will attempt to generate a reference output -by compiling the program with the "safe" backend and running it. - -=item B<--profile-info-file> F - -Profile file loaded by B<--profile-loader>. - -=item B<--run-{int,jit,llc,custom}> - -Whenever the test program is compiled, B should generate code for it -using the specified code generator. These options allow you to choose the -interpreter, the JIT compiler, the static native code compiler, or a -custom command (see B<--exec-command>) respectively. - -=item B<--safe-{llc,custom}> - -When debugging a code generator, B should use the specified code -generator as the "safe" code generator. This is a known-good code generator -used to generate the "reference output" if it has not been provided, and to -compile portions of the program that as they are excluded from the testcase. -These options allow you to choose the -static native code compiler, or a custom command, (see B<--exec-command>) -respectively. The interpreter and the JIT backends cannot currently -be used as the "safe" backends. - -=item B<--exec-command> I - -This option defines the command to use with the B<--run-custom> and -B<--safe-custom> options to execute the bitcode testcase. This can -be useful for cross-compilation. - -=item B<--compile-command> I - -This option defines the command to use with the B<--compile-custom> -option to compile the bitcode testcase. This can be useful for -testing compiler output without running any link or execute stages. To -generate a reduced unit test, you may add CHECK directives to the -testcase and pass the name of an executable compile-command script in this form: - - #!/bin/sh - llc "$@" - not FileCheck [bugpoint input file].ll < bugpoint-test-program.s - -This script will "fail" as long as FileCheck passes. So the result -will be the minimum bitcode that passes FileCheck. - -=item B<--safe-path> I - -This option defines the path to the command to execute with the -B<--safe-{int,jit,llc,custom}> -option. - -=back - -=head1 EXIT STATUS - -If B succeeds in finding a problem, it will exit with 0. Otherwise, -if an error occurs, it will exit with a non-zero value. - -=head1 SEE ALSO - -L - -=head1 AUTHOR - -Maintained by the LLVM Team (L). - -=cut diff --git a/docs/CommandGuide/html/manpage.css b/docs/CommandGuide/html/manpage.css deleted file mode 100644 index b2003434901..00000000000 --- a/docs/CommandGuide/html/manpage.css +++ /dev/null @@ -1,256 +0,0 @@ -/* Based on http://www.perldoc.com/css/perldoc.css */ - -@import url("../llvm.css"); - -body { font-family: Arial,Helvetica; } - -blockquote { margin: 10pt; } - -h1, a { color: #336699; } - - -/*** Top menu style ****/ -.mmenuon { - font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; - color: #ff6600; font-size: 10pt; - } -.mmenuoff { - font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; - color: #ffffff; font-size: 10pt; -} -.cpyright { - font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; - color: #ffffff; font-size: xx-small; -} -.cpyrightText { - font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; - color: #ffffff; font-size: xx-small; -} -.sections { - font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; - color: #336699; font-size: 11pt; -} -.dsections { - font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; - color: #336699; font-size: 12pt; -} -.slink { - font-family: Arial,Helvetica; font-weight: normal; text-decoration: none; - color: #000000; font-size: 9pt; -} - -.slink2 { font-family: Arial,Helvetica; text-decoration: none; color: #336699; } - -.maintitle { - font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; - color: #336699; font-size: 18pt; -} -.dblArrow { - font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; - color: #336699; font-size: small; -} -.menuSec { - font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; - color: #336699; font-size: small; -} - -.newstext { - font-family: Arial,Helvetica; font-size: small; -} - -.linkmenu { - font-family: Arial,Helvetica; color: #000000; font-weight: bold; - text-decoration: none; -} - -P { - font-family: Arial,Helvetica; -} - -PRE { - font-size: 10pt; -} -.quote { - font-family: Times; text-decoration: none; - color: #000000; font-size: 9pt; font-style: italic; -} -.smstd { font-family: Arial,Helvetica; color: #000000; font-size: x-small; } -.std { font-family: Arial,Helvetica; color: #000000; } -.meerkatTitle { - font-family: sans-serif; font-size: x-small; color: black; } - -.meerkatDescription { font-family: sans-serif; font-size: 10pt; color: black } -.meerkatCategory { - font-family: sans-serif; font-size: 9pt; font-weight: bold; font-style: italic; - color: brown; } -.meerkatChannel { - font-family: sans-serif; font-size: 9pt; font-style: italic; color: brown; } -.meerkatDate { font-family: sans-serif; font-size: xx-small; color: #336699; } - -.tocTitle { - font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; - color: #333333; font-size: 10pt; -} - -.toc-item { - font-family: Arial,Helvetica; font-weight: bold; - color: #336699; font-size: 10pt; text-decoration: underline; -} - -.perlVersion { - font-family: Arial,Helvetica; font-weight: bold; - color: #336699; font-size: 10pt; text-decoration: none; -} - -.podTitle { - font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; - color: #000000; -} - -.docTitle { - font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; - color: #000000; font-size: 10pt; -} -.dotDot { - font-family: Arial,Helvetica; font-weight: bold; - color: #000000; font-size: 9pt; -} - -.docSec { - font-family: Arial,Helvetica; font-weight: normal; - color: #333333; font-size: 9pt; -} -.docVersion { - font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; - color: #336699; font-size: 10pt; -} - -.docSecs-on { - font-family: Arial,Helvetica; font-weight: normal; text-decoration: none; - color: #ff0000; font-size: 10pt; -} -.docSecs-off { - font-family: Arial,Helvetica; font-weight: normal; text-decoration: none; - color: #333333; font-size: 10pt; -} - -h2 { - font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; - color: #336699; font-size: medium; -} -h1 { - font-family: Verdana,Arial,Helvetica; font-weight: bold; text-decoration: none; - color: #336699; font-size: large; -} - -DL { - font-family: Arial,Helvetica; font-weight: normal; text-decoration: none; - color: #333333; font-size: 10pt; -} - -UL > LI > A { - font-family: Arial,Helvetica; font-weight: bold; - color: #336699; font-size: 10pt; -} - -.moduleInfo { - font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; - color: #333333; font-size: 11pt; -} - -.moduleInfoSec { - font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; - color: #336699; font-size: 10pt; -} - -.moduleInfoVal { - font-family: Arial,Helvetica; font-weight: normal; text-decoration: underline; - color: #000000; font-size: 10pt; -} - -.cpanNavTitle { - font-family: Arial,Helvetica; font-weight: bold; - color: #ffffff; font-size: 10pt; -} -.cpanNavLetter { - font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; - color: #333333; font-size: 9pt; -} -.cpanCat { - font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; - color: #336699; font-size: 9pt; -} - -.bttndrkblue-bkgd-top { - background-color: #225688; - background-image: url(/global/mvc_objects/images/bttndrkblue_bgtop.gif); -} -.bttndrkblue-bkgd-left { - background-color: #225688; - background-image: url(/global/mvc_objects/images/bttndrkblue_bgleft.gif); -} -.bttndrkblue-bkgd { - padding-top: 0px; - padding-bottom: 0px; - margin-bottom: 0px; - margin-top: 0px; - background-repeat: no-repeat; - background-color: #225688; - background-image: url(/global/mvc_objects/images/bttndrkblue_bgmiddle.gif); - vertical-align: top; -} -.bttndrkblue-bkgd-right { - background-color: #225688; - background-image: url(/global/mvc_objects/images/bttndrkblue_bgright.gif); -} -.bttndrkblue-bkgd-bottom { - background-color: #225688; - background-image: url(/global/mvc_objects/images/bttndrkblue_bgbottom.gif); -} -.bttndrkblue-text a { - color: #ffffff; - text-decoration: none; -} -a.bttndrkblue-text:hover { - color: #ffDD3C; - text-decoration: none; -} -.bg-ltblue { - background-color: #f0f5fa; -} - -.border-left-b { - background: #f0f5fa url(/i/corner-leftline.gif) repeat-y; -} - -.border-right-b { - background: #f0f5fa url(/i/corner-rightline.gif) repeat-y; -} - -.border-top-b { - background: #f0f5fa url(/i/corner-topline.gif) repeat-x; -} - -.border-bottom-b { - background: #f0f5fa url(/i/corner-botline.gif) repeat-x; -} - -.border-right-w { - background: #ffffff url(/i/corner-rightline.gif) repeat-y; -} - -.border-top-w { - background: #ffffff url(/i/corner-topline.gif) repeat-x; -} - -.border-bottom-w { - background: #ffffff url(/i/corner-botline.gif) repeat-x; -} - -.bg-white { - background-color: #ffffff; -} - -.border-left-w { - background: #ffffff url(/i/corner-leftline.gif) repeat-y; -} diff --git a/docs/CommandGuide/index.html b/docs/CommandGuide/index.html deleted file mode 100644 index 772a59f40e5..00000000000 --- a/docs/CommandGuide/index.html +++ /dev/null @@ -1,139 +0,0 @@ - - - - LLVM Command Guide - - - - -

- LLVM Command Guide -

- -

These documents are HTML versions of the man pages -for all of the LLVM tools. These pages describe how to use the LLVM commands -and what their options are. Note that these pages do not describe all of the -options available for all tools. To get a complete listing, pass the --help (general options) or -help-hidden (general+debugging -options) arguments to the tool you are interested in.

- -

- - -

- Basic Commands -

- - -

- -

llvm-as - - assemble a human-readable .ll file into bytecode
llvm-dis - - disassemble a bytecode file into a human-readable .ll file
opt - - run a series of LLVM-to-LLVM optimizations on a bytecode file
llc - - generate native machine code for a bytecode file
lli - - directly run a program compiled to bytecode using a JIT compiler or - interpreter
llvm-link - - link several bytecode files into one
llvm-ar - - archive bytecode files
llvm-ranlib - - create an index for archives made with llvm-ar
llvm-nm - - print out the names and types of symbols in a bytecode file
llvm-prof - - format raw `llvmprof.out' data into a human-readable report
llvm-config - - print out LLVM compilation options, libraries, etc. as configured
llvm-diff - - structurally compare two modules
llvm-cov - - emit coverage information
llvm-stress - - generate random .ll files to fuzz different llvm components

- -

- - -

- Debugging Tools -

- - - -

- -

bugpoint - - automatic test-case reducer
llvm-extract - - extract a function from an LLVM bytecode file
llvm-bcanalyzer - - bytecode analyzer (analyzes the binary encoding itself, not the program it - represents)

- - -

- Internal Tools -

- - -

FileCheck - - Flexible file verifier used extensively by the testing harness
tblgen - - target description reader and generator
lit - - LLVM Integrated Tester, for running tests

- - - -

- - LLVM Compiler Infrastructure
- Last modified: $Date$ -

- - - diff --git a/docs/CommandGuide/lit.pod b/docs/CommandGuide/lit.pod deleted file mode 100644 index 81fc2c91804..00000000000 --- a/docs/CommandGuide/lit.pod +++ /dev/null @@ -1,404 +0,0 @@ -=pod - -=head1 NAME - -lit - LLVM Integrated Tester - -=head1 SYNOPSIS - -B [I] [I] - -=head1 DESCRIPTION - -B is a portable tool for executing LLVM and Clang style test suites, -summarizing their results, and providing indication of failures. B is -designed to be a lightweight testing tool with as simple a user interface as -possible. - -B should be run with one or more I to run specified on the command -line. Tests can be either individual test files or directories to search for -tests (see L<"TEST DISCOVERY">). - -Each specified test will be executed (potentially in parallel) and once all -tests have been run B will print summary information on the number of tests -which passed or failed (see L<"TEST STATUS RESULTS">). The B program will -execute with a non-zero exit code if any tests fail. - -By default B will use a succinct progress display and will only print -summary information for test failures. See L<"OUTPUT OPTIONS"> for options -controlling the B progress display and output. - -B also includes a number of options for controlling how tests are executed -(specific features may depend on the particular test format). See L<"EXECUTION -OPTIONS"> for more information. - -Finally, B also supports additional options for only running a subset of -the options specified on the command line, see L<"SELECTION OPTIONS"> for -more information. - -Users interested in the B architecture or designing a B testing -implementation should see L<"LIT INFRASTRUCTURE"> - -=head1 GENERAL OPTIONS - -=over - -=item B<-h>, B<--help> - -Show the B help message. - -=item B<-j> I, B<--threads>=I - -Run I tests in parallel. By default, this is automatically chosen to match -the number of detected available CPUs. - -=item B<--config-prefix>=I - -Search for I and I when searching for test suites, -instead of I and I. - -=item B<--param> I, B<--param> I=I - -Add a user defined parameter I with the given I (or the empty -string if not given). The meaning and use of these parameters is test suite -dependent. - -=back - -=head1 OUTPUT OPTIONS - -=over - -=item B<-q>, B<--quiet> - -Suppress any output except for test failures. - -=item B<-s>, B<--succinct> - -Show less output, for example don't show information on tests that pass. - -=item B<-v>, B<--verbose> - -Show more information on test failures, for example the entire test output -instead of just the test result. - -=item B<--no-progress-bar> - -Do not use curses based progress bar. - -=back - -=head1 EXECUTION OPTIONS - -=over - -=item B<--path>=I - -Specify an addition I to use when searching for executables in tests. - -=item B<--vg> - -Run individual tests under valgrind (using the memcheck tool). The -I<--error-exitcode> argument for valgrind is used so that valgrind failures will -cause the program to exit with a non-zero status. - -=item B<--vg-arg>=I - -When I<--vg> is used, specify an additional argument to pass to valgrind itself. - -=item B<--time-tests> - -Track the wall time individual tests take to execute and includes the results in -the summary output. This is useful for determining which tests in a test suite -take the most time to execute. Note that this option is most useful with I<-j -1>. - -=back - -=head1 SELECTION OPTIONS - -=over - -=item B<--max-tests>=I - -Run at most I tests and then terminate. - -=item B<--max-time>=I - -Spend at most I seconds (approximately) running tests and then terminate. - -=item B<--shuffle> - -Run the tests in a random order. - -=back - -=head1 ADDITIONAL OPTIONS - -=over - -=item B<--debug> - -Run B in debug mode, for debugging configuration issues and B itself. - -=item B<--show-suites> - -List the discovered test suites as part of the standard output. - -=item B<--no-tcl-as-sh> - -Run Tcl scripts internally (instead of converting to shell scripts). - -=item B<--repeat>=I - -Run each test I times. Currently this is primarily useful for timing tests, -other results are not collated in any reasonable fashion. - -=back - -=head1 EXIT STATUS - -B will exit with an exit code of 1 if there are any FAIL or XPASS -results. Otherwise, it will exit with the status 0. Other exit codes are used -for non-test related failures (for example a user error or an internal program -error). - -=head1 TEST DISCOVERY - -The inputs passed to B can be either individual tests, or entire -directories or hierarchies of tests to run. When B starts up, the first -thing it does is convert the inputs into a complete list of tests to run as part -of I. - -In the B model, every test must exist inside some I. B -resolves the inputs specified on the command line to test suites by searching -upwards from the input path until it finds a I or I -file. These files serve as both a marker of test suites and as configuration -files which B loads in order to understand how to find and run the tests -inside the test suite. - -Once B has mapped the inputs into test suites it traverses the list of -inputs adding tests for individual files and recursively searching for tests in -directories. - -This behavior makes it easy to specify a subset of tests to run, while still -allowing the test suite configuration to control exactly how tests are -interpreted. In addition, B always identifies tests by the test suite they -are in, and their relative path inside the test suite. For appropriately -configured projects, this allows B to provide convenient and flexible -support for out-of-tree builds. - -=head1 TEST STATUS RESULTS - -Each test ultimately produces one of the following six results: - -=over - -=item B - -The test succeeded. - -=item B - -The test failed, but that is expected. This is used for test formats which allow -specifying that a test does not currently work, but wish to leave it in the test -suite. - -=item B - -The test succeeded, but it was expected to fail. This is used for tests which -were specified as expected to fail, but are now succeeding (generally because -the feature they test was broken and has been fixed). - -=item B - -The test failed. - -=item B - -The test result could not be determined. For example, this occurs when the test -could not be run, the test itself is invalid, or the test was interrupted. - -=item B - -The test is not supported in this environment. This is used by test formats -which can report unsupported tests. - -=back - -Depending on the test format tests may produce additional information about -their status (generally only for failures). See the L -section for more information. - -=head1 LIT INFRASTRUCTURE - -This section describes the B testing architecture for users interested in -creating a new B testing implementation, or extending an existing one. - -B proper is primarily an infrastructure for discovering and running -arbitrary tests, and to expose a single convenient interface to these -tests. B itself doesn't know how to run tests, rather this logic is -defined by I. - -=head2 TEST SUITES - -As described in L<"TEST DISCOVERY">, tests are always located inside a I. Test suites serve to define the format of the tests they contain, the -logic for finding those tests, and any additional information to run the tests. - -B identifies test suites as directories containing I or -I files (see also B<--config-prefix>). Test suites are initially -discovered by recursively searching up the directory hierarchy for all the input -files passed on the command line. You can use B<--show-suites> to display the -discovered test suites at startup. - -Once a test suite is discovered, its config file is loaded. Config files -themselves are Python modules which will be executed. When the config file is -executed, two important global variables are predefined: - -=over - -=item B - -The global B configuration object (a I instance), which defines -the builtin test formats, global configuration parameters, and other helper -routines for implementing test configurations. - -=item B - -This is the config object (a I instance) for the test suite, -which the config file is expected to populate. The following variables are also -available on the I object, some of which must be set by the config and -others are optional or predefined: - -B I<[required]> The name of the test suite, for use in reports and -diagnostics. - -B I<[required]> The test format object which will be used to -discover and run tests in the test suite. Generally this will be a builtin test -format available from the I module. - -B The filesystem path to the test suite root. For out-of-dir -builds this is the directory that will be scanned for tests. - -B For out-of-dir builds, the path to the test suite root inside -the object directory. This is where tests will be run and temporary output files -placed. - -B A dictionary representing the environment to use when executing -tests in the suite. - -B For B test formats which scan directories for tests, this -variable is a list of suffixes to identify test files. Used by: I, -I. - -B For B test formats which substitute variables into a test -script, the list of substitutions to perform. Used by: I, I. - -B Mark an unsupported directory, all tests within it will be -reported as unsupported. Used by: I, I. - -B The parent configuration, this is the config object for the directory -containing the test suite, or None. - -B The root configuration. This is the top-most B configuration in -the project. - -B The config is actually cloned for every subdirectory inside a test -suite, to allow local configuration on a per-directory basis. The I -variable can be set to a Python function which will be called whenever a -configuration is cloned (for a subdirectory). The function should takes three -arguments: (1) the parent configuration, (2) the new configuration (which the -I function will generally modify), and (3) the test path to the new -directory being scanned. - -=back - -=head2 TEST DISCOVERY - -Once test suites are located, B recursively traverses the source directory -(following I) looking for tests. When B enters a -sub-directory, it first checks to see if a nested test suite is defined in that -directory. If so, it loads that test suite recursively, otherwise it -instantiates a local test config for the directory (see L<"LOCAL CONFIGURATION -FILES">). - -Tests are identified by the test suite they are contained within, and the -relative path inside that suite. Note that the relative path may not refer to an -actual file on disk; some test formats (such as I) define "virtual -tests" which have a path that contains both the path to the actual test file and -a subpath to identify the virtual test. - -=head2 LOCAL CONFIGURATION FILES - -When B loads a subdirectory in a test suite, it instantiates a local test -configuration by cloning the configuration for the parent direction -- the root -of this configuration chain will always be a test suite. Once the test -configuration is cloned B checks for a I file in the -subdirectory. If present, this file will be loaded and can be used to specialize -the configuration for each individual directory. This facility can be used to -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 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: - -: () - -where 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 field can consist of an arbitrary string containing no newline. - -The 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. - - TEST '()' -... log message ... - - -where should be the name of a preceeding reported test, is a string of '*' characters I four characters long (the -recommended length is 20), and 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 distribution contains several example implementations of test suites -in the I directory. - -=head1 SEE ALSO - -L - -=head1 AUTHOR - -Written by Daniel Dunbar and maintained by the LLVM Team (L). - -=cut diff --git a/docs/CommandGuide/llc.pod b/docs/CommandGuide/llc.pod deleted file mode 100644 index 35abdaeb2b1..00000000000 --- a/docs/CommandGuide/llc.pod +++ /dev/null @@ -1,201 +0,0 @@ -=pod - -=head1 NAME - -llc - LLVM static compiler - -=head1 SYNOPSIS - -B [I] [I] - -=head1 DESCRIPTION - -The B command compiles LLVM source inputs into assembly language for a -specified architecture. The assembly language output can then be passed through -a native assembler and linker to generate a native executable. - -The choice of architecture for the output assembly code is automatically -determined from the input file, unless the B<-march> option is used to override -the default. - -=head1 OPTIONS - -If I is - or omitted, B reads from standard input. Otherwise, it -will from I. Inputs can be in either the LLVM assembly language -format (.ll) or the LLVM bitcode format (.bc). - -If the B<-o> option is omitted, then B will send its output to standard -output if the input is from standard input. If the B<-o> option specifies -, -then the output will also be sent to standard output. - -If no B<-o> option is specified and an input file other than - is specified, -then B creates the output filename by taking the input filename, -removing any existing F<.bc> extension, and adding a F<.s> suffix. - -Other B options are as follows: - -=head2 End-user Options - -=over - -=item B<-help> - -Print a summary of command line options. - -=item B<-O>=I - -Generate code at different optimization levels. These correspond to the I<-O0>, -I<-O1>, I<-O2>, and I<-O3> optimization levels used by B and -B. - -=item B<-mtriple>=I - -Override the target triple specified in the input file with the specified -string. - -=item B<-march>=I - -Specify the architecture for which to generate assembly, overriding the target -encoded in the input file. See the output of B for a list of -valid architectures. By default this is inferred from the target triple or -autodetected to the current architecture. - -=item B<-mcpu>=I - -Specify a specific chip in the current architecture to generate code for. -By default this is inferred from the target triple and autodetected to -the current architecture. For a list of available CPUs, use: -B /dev/null | llc -march=xyz -mcpu=help> - -=item B<-mattr>=I - -Override or control specific attributes of the target, such as whether SIMD -operations are enabled or not. The default set of attributes is set by the -current CPU. For a list of available attributes, use: -B /dev/null | llc -march=xyz -mattr=help> - -=item B<--disable-fp-elim> - -Disable frame pointer elimination optimization. - -=item B<--disable-excess-fp-precision> - -Disable optimizations that may produce excess precision for floating point. -Note that this option can dramatically slow down code on some systems -(e.g. X86). - -=item B<--enable-no-infs-fp-math> - -Enable optimizations that assume no Inf values. - -=item B<--enable-no-nans-fp-math> - -Enable optimizations that assume no NAN values. - -=item B<--enable-unsafe-fp-math> - -Enable optimizations that make unsafe assumptions about IEEE math (e.g. that -addition is associative) or may not work for all input ranges. These -optimizations allow the code generator to make use of some instructions which -would otherwise not be usable (such as fsin on X86). - -=item B<--enable-correct-eh-support> - -Instruct the B pass to insert code for correct exception handling -support. This is expensive and is by default omitted for efficiency. - -=item B<--stats> - -Print statistics recorded by code-generation passes. - -=item B<--time-passes> - -Record the amount of time needed for each pass and print a report to standard -error. - -=item B<--load>=F - -Dynamically load F (a path to a dynamically shared object) that -implements an LLVM target. This will permit the target name to be used with the -B<-march> option so that code can be generated for that target. - -=back - -=head2 Tuning/Configuration Options - -=over - -=item B<--print-machineinstrs> - -Print generated machine code between compilation phases (useful for debugging). - -=item B<--regalloc>=I - -Specify the register allocator to use. The default I is I. -Valid register allocators are: - -=over - -=item I - -Very simple "always spill" register allocator - -=item I - -Local register allocator - -=item I - -Linear scan global register allocator - -=item I - -Iterative scan global register allocator - -=back - -=item B<--spiller>=I - -Specify the spiller to use for register allocators that support it. Currently -this option is used only by the linear scan register allocator. The default -I is I. Valid spillers are: - -=over - -=item I - -Simple spiller - -=item I - -Local spiller - -=back - -=back - -=head2 Intel IA-32-specific Options - -=over - -=item B<--x86-asm-syntax=att|intel> - -Specify whether to emit assembly code in AT&T syntax (the default) or intel -syntax. - -=back - -=head1 EXIT STATUS - -If B succeeds, it will exit with 0. Otherwise, if an error occurs, -it will exit with a non-zero value. - -=head1 SEE ALSO - -L - -=head1 AUTHORS - -Maintained by the LLVM Team (L). - -=cut diff --git a/docs/CommandGuide/lli.pod b/docs/CommandGuide/lli.pod deleted file mode 100644 index a313a31718c..00000000000 --- a/docs/CommandGuide/lli.pod +++ /dev/null @@ -1,219 +0,0 @@ -=pod - -=head1 NAME - -lli - directly execute programs from LLVM bitcode - -=head1 SYNOPSIS - -B [I] [I] [I] - -=head1 DESCRIPTION - -B directly executes programs in LLVM bitcode format. It takes a program -in LLVM bitcode format and executes it using a just-in-time compiler, if one is -available for the current architecture, or an interpreter. B takes all of -the same code generator options as L, but they are only effective when -B is using the just-in-time compiler. - -If I is not specified, then B reads the LLVM bitcode for the -program from standard input. - -The optional I specified on the command line are passed to the program as -arguments. - -=head1 GENERAL OPTIONS - -=over - -=item B<-fake-argv0>=I - -Override the C value passed into the executing program. - -=item B<-force-interpreter>=I<{false,true}> - -If set to true, use the interpreter even if a just-in-time compiler is available -for this architecture. Defaults to false. - -=item B<-help> - -Print a summary of command line options. - -=item B<-load>=I - -Causes B to load the plugin (shared object) named I and use -it for optimization. - -=item B<-stats> - -Print statistics from the code-generation passes. This is only meaningful for -the just-in-time compiler, at present. - -=item B<-time-passes> - -Record the amount of time needed for each code-generation pass and print it to -standard error. - -=item B<-version> - -Print out the version of B and exit without doing anything else. - -=back - -=head1 TARGET OPTIONS - -=over - -=item B<-mtriple>=I - -Override the target triple specified in the input bitcode file with the -specified string. This may result in a crash if you pick an -architecture which is not compatible with the current system. - -=item B<-march>=I - -Specify the architecture for which to generate assembly, overriding the target -encoded in the bitcode file. See the output of B for a list of -valid architectures. By default this is inferred from the target triple or -autodetected to the current architecture. - -=item B<-mcpu>=I - -Specify a specific chip in the current architecture to generate code for. -By default this is inferred from the target triple and autodetected to -the current architecture. For a list of available CPUs, use: -B /dev/null | llc -march=xyz -mcpu=help> - -=item B<-mattr>=I - -Override or control specific attributes of the target, such as whether SIMD -operations are enabled or not. The default set of attributes is set by the -current CPU. For a list of available attributes, use: -B /dev/null | llc -march=xyz -mattr=help> - -=back - - -=head1 FLOATING POINT OPTIONS - -=over - -=item B<-disable-excess-fp-precision> - -Disable optimizations that may increase floating point precision. - -=item B<-enable-no-infs-fp-math> - -Enable optimizations that assume no Inf values. - -=item B<-enable-no-nans-fp-math> - -Enable optimizations that assume no NAN values. - -=item B<-enable-unsafe-fp-math> - -Causes B to enable optimizations that may decrease floating point -precision. - -=item B<-soft-float> - -Causes B to generate software floating point library calls instead of -equivalent hardware instructions. - -=back - -=head1 CODE GENERATION OPTIONS - -=over - -=item B<-code-model>=I - -Choose the code model from: - - default: Target default code model - small: Small code model - kernel: Kernel code model - medium: Medium code model - large: Large code model - -=item B<-disable-post-RA-scheduler> - -Disable scheduling after register allocation. - -=item B<-disable-spill-fusing> - -Disable fusing of spill code into instructions. - -=item B<-enable-correct-eh-support> - -Make the -lowerinvoke pass insert expensive, but correct, EH code. - -=item B<-jit-enable-eh> - -Exception handling should be enabled in the just-in-time compiler. - -=item B<-join-liveintervals> - -Coalesce copies (default=true). - -=item B<-nozero-initialized-in-bss> -Don't place zero-initialized symbols into the BSS section. - -=item B<-pre-RA-sched>=I - -Instruction schedulers available (before register allocation): - - =default: Best scheduler for the target - =none: No scheduling: breadth first sequencing - =simple: Simple two pass scheduling: minimize critical path and maximize processor utilization - =simple-noitin: Simple two pass scheduling: Same as simple except using generic latency - =list-burr: Bottom-up register reduction list scheduling - =list-tdrr: Top-down register reduction list scheduling - =list-td: Top-down list scheduler -print-machineinstrs - Print generated machine code - -=item B<-regalloc>=I - -Register allocator to use (default=linearscan) - - =bigblock: Big-block register allocator - =linearscan: linear scan register allocator =local - local register allocator - =simple: simple register allocator - -=item B<-relocation-model>=I - -Choose relocation model from: - - =default: Target default relocation model - =static: Non-relocatable code =pic - Fully relocatable, position independent code - =dynamic-no-pic: Relocatable external references, non-relocatable code - -=item B<-spiller> - -Spiller to use (default=local) - - =simple: simple spiller - =local: local spiller - -=item B<-x86-asm-syntax>=I - -Choose style of code to emit from X86 backend: - - =att: Emit AT&T-style assembly - =intel: Emit Intel-style assembly - -=back - -=head1 EXIT STATUS - -If B fails to load the program, it will exit with an exit code of 1. -Otherwise, it will return the exit code of the program it executes. - -=head1 SEE ALSO - -L - -=head1 AUTHOR - -Maintained by the LLVM Team (L). - -=cut diff --git a/docs/CommandGuide/llvm-ar.pod b/docs/CommandGuide/llvm-ar.pod deleted file mode 100644 index a8f01b0319a..00000000000 --- a/docs/CommandGuide/llvm-ar.pod +++ /dev/null @@ -1,406 +0,0 @@ -=pod - -=head1 NAME - -llvm-ar - LLVM archiver - -=head1 SYNOPSIS - -B [-]{dmpqrtx}[Rabfikouz] [relpos] [count] [files...] - - -=head1 DESCRIPTION - -The B command is similar to the common Unix utility, C. It -archives several files together into a single file. The intent for this is -to produce archive libraries by LLVM bitcode that can be linked into an -LLVM program. However, the archive can contain any kind of file. By default, -B generates a symbol table that makes linking faster because -only the symbol table needs to be consulted, not each individual file member -of the archive. - -The B command can be used to I both SVR4 and BSD style archive -files. However, it cannot be used to write them. While the B command -produces files that are I identical to the format used by other C -implementations, it has two significant departures in order to make the -archive appropriate for LLVM. The first departure is that B only -uses BSD4.4 style long path names (stored immediately after the header) and -never contains a string table for long names. The second departure is that the -symbol table is formated for efficient construction of an in-memory data -structure that permits rapid (red-black tree) lookups. Consequently, archives -produced with B usually won't be readable or editable with any -C implementation or useful for linking. Using the C modifier to flatten -file names will make the archive readable by other C implementations -but not for linking because the symbol table format for LLVM is unique. If an -SVR4 or BSD style archive is used with the C (replace) or C (quick -update) operations, the archive will be reconstructed in LLVM format. This -means that the string table will be dropped (in deference to BSD 4.4 long names) -and an LLVM symbol table will be added (by default). The system symbol table -will be retained. - -Here's where B departs from previous C implementations: - -=over - -=item I - -Since B is intended to archive bitcode files, the symbol table -won't make much sense to anything but LLVM. Consequently, the symbol table's -format has been simplified. It consists simply of a sequence of pairs -of a file member index number as an LSB 4byte integer and a null-terminated -string. - -=item I - -Some C implementations (SVR4) use a separate file member to record long -path names (> 15 characters). B takes the BSD 4.4 and Mac OS X -approach which is to simply store the full path name immediately preceding -the data for the file. The path name is null terminated and may contain the -slash (/) character. - -=item I - -B can compress the members of an archive to save space. The -compression used depends on what's available on the platform and what choices -the LLVM Compressor utility makes. It generally favors bzip2 but will select -between "no compression" or bzip2 depending on what makes sense for the -file's content. - -=item I - -Most C implementations do not recurse through directories but simply -ignore directories if they are presented to the program in the F -option. B, however, can recurse through directory structures and -add all the files under a directory, if requested. - -=item I - -When B prints out the verbose table of contents (C option), it -precedes the usual output with a character indicating the basic kind of -content in the file. A blank means the file is a regular file. A 'Z' means -the file is compressed. A 'B' means the file is an LLVM bitcode file. An -'S' means the file is the symbol table. - -=back - -=head1 OPTIONS - -The options to B are compatible with other C implementations. -However, there are a few modifiers (F) that are not found in other -Cs. The options to B specify a single basic operation to -perform on the archive, a variety of modifiers for that operation, the -name of the archive file, and an optional list of file names. These options -are used to determine how B should process the archive file. - -The Operations and Modifiers are explained in the sections below. The minimal -set of options is at least one operator and the name of the archive. Typically -archive files end with a C<.a> suffix, but this is not required. Following -the F comes a list of F that indicate the specific members -of the archive to operate on. If the F option is not specified, it -generally means either "none" or "all" members, depending on the operation. - -=head2 Operations - -=over - -=item d - -Delete files from the archive. No modifiers are applicable to this operation. -The F options specify which members should be removed from the -archive. It is not an error if a specified file does not appear in the archive. -If no F are specified, the archive is not modified. - -=item m[abi] - -Move files from one location in the archive to another. The F, F, and -F modifiers apply to this operation. The F will all be moved -to the location given by the modifiers. If no modifiers are used, the files -will be moved to the end of the archive. If no F are specified, the -archive is not modified. - -=item p[k] - -Print files to the standard output. The F modifier applies to this -operation. This operation simply prints the F indicated to the -standard output. If no F are specified, the entire archive is printed. -Printing bitcode files is ill-advised as they might confuse your terminal -settings. The F

operation never modifies the archive. - -=item q[Rfz] - -Quickly append files to the end of the archive. The F, F, and F -modifiers apply to this operation. This operation quickly adds the -F to the archive without checking for duplicates that should be -removed first. If no F are specified, the archive is not modified. -Because of the way that B constructs the archive file, its dubious -whether the F operation is any faster than the F operation. - -=item r[Rabfuz] - -Replace or insert file members. The F, F , F, F, F, and F -modifiers apply to this operation. This operation will replace existing -F or insert them at the end of the archive if they do not exist. If no -F are specified, the archive is not modified. - -=item t[v] - -Print the table of contents. Without any modifiers, this operation just prints -the names of the members to the standard output. With the F modifier, -B also prints out the file type (B=bitcode, Z=compressed, S=symbol -table, blank=regular file), the permission mode, the owner and group, the -size, and the date. If any F are specified, the listing is only for -those files. If no F are specified, the table of contents for the -whole archive is printed. - -=item x[oP] - -Extract archive members back to files. The F modifier applies to this -operation. This operation retrieves the indicated F from the archive -and writes them back to the operating system's file system. If no -F are specified, the entire archive is extract. - -=back - -=head2 Modifiers (operation specific) - -The modifiers below are specific to certain operations. See the Operations -section (above) to determine which modifiers are applicable to which operations. - -=over - -=item [a] - -When inserting or moving member files, this option specifies the destination of -the new files as being Cfter the F member. If F is not found, -the files are placed at the end of the archive. - -=item [b] - -When inserting or moving member files, this option specifies the destination of -the new files as being Cefore the F member. If F is not -found, the files are placed at the end of the archive. This modifier is -identical to the the F modifier. - -=item [f] - -Normally, B stores the full path name to a file as presented to it on -the command line. With this option, truncated (15 characters max) names are -used. This ensures name compatibility with older versions of C but may also -thwart correct extraction of the files (duplicates may overwrite). If used with -the F option, the directory recursion will be performed but the file names -will all be Clattened to simple file names. - -=item [i] - -A synonym for the F option. - -=item [k] - -Normally, B will not print the contents of bitcode files when the -F