llvm.org GIT mirror llvm / a5d2435
[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 Daniel Dunbar 8 years ago
27 changed file(s) with 1 addition(s) and 3904 deletion(s). Raw diff Collapse all Expand all
10271027 AC_PATH_PROG(DOXYGEN, [doxygen])
10281028 AC_PATH_PROG(GROFF, [groff])
10291029 AC_PATH_PROG(GZIPBIN, [gzip])
1030 AC_PATH_PROG(POD2HTML, [pod2html])
1031 AC_PATH_PROG(POD2MAN, [pod2man])
10321030 AC_PATH_PROG(PDFROFF, [pdfroff])
10331031 AC_PATH_PROG(RUNTEST, [runtest])
10341032 DJ_AC_PATH_TCLSH
+0
-245
docs/CommandGuide/FileCheck.pod less more
None
1 =pod
2
3 =head1 NAME
4
5 FileCheck - Flexible pattern matching file verifier
6
7 =head1 SYNOPSIS
8
9 B I [I<--check-prefix=XXX>] [I<--strict-whitespace>]
10
11 =head1 DESCRIPTION
12
13 B reads two files (one from standard input, and one specified on the
14 command line) and uses one to verify the other. This behavior is particularly
15 useful for the testsuite, which wants to verify that the output of some tool
16 (e.g. llc) contains the expected information (for example, a movsd from esp or
17 whatever is interesting). This is similar to using grep, but it is optimized
18 for matching multiple different inputs in one file in a specific order.
19
20 The I file specifies the file that contains the patterns to
21 match. The file to verify is always read from standard input.
22
23 =head1 OPTIONS
24
25 =over
26
27 =item B<-help>
28
29 Print a summary of command line options.
30
31 =item B<--check-prefix> I
32
33 FileCheck searches the contents of I for patterns to match. By
34 default, these patterns are prefixed with "CHECK:". If you'd like to use a
35 different prefix (e.g. because the same input file is checking multiple
36 different tool or options), the B<--check-prefix> argument allows you to specify
37 a specific prefix to match.
38
39 =item B<--strict-whitespace>
40
41 By default, FileCheck canonicalizes input horizontal whitespace (spaces and
42 tabs) which causes it to ignore these differences (a space will match a tab).
43 The --strict-whitespace argument disables this behavior.
44
45 =item B<-version>
46
47 Show the version number of this program.
48
49 =back
50
51 =head1 EXIT STATUS
52
53 If B verifies that the file matches the expected contents, it exits
54 with 0. Otherwise, if not, or if an error occurs, it will exit with a non-zero
55 value.
56
57 =head1 TUTORIAL
58
59 FileCheck is typically used from LLVM regression tests, being invoked on the RUN
60 line of the test. A simple example of using FileCheck from a RUN line looks
61 like this:
62
63 ; RUN: llvm-as < %s | llc -march=x86-64 | FileCheck %s
64
65 This syntax says to pipe the current file ("%s") into llvm-as, pipe that into
66 llc, then pipe the output of llc into FileCheck. This means that FileCheck will
67 be verifying its standard input (the llc output) against the filename argument
68 specified (the original .ll file specified by "%s"). To see how this works,
69 let's look at the rest of the .ll file (after the RUN line):
70
71 define void @sub1(i32* %p, i32 %v) {
72 entry:
73 ; CHECK: sub1:
74 ; CHECK: subl
75 %0 = tail call i32 @llvm.atomic.load.sub.i32.p0i32(i32* %p, i32 %v)
76 ret void
77 }
78
79 define void @inc4(i64* %p) {
80 entry:
81 ; CHECK: inc4:
82 ; CHECK: incq
83 %0 = tail call i64 @llvm.atomic.load.add.i64.p0i64(i64* %p, i64 1)
84 ret void
85 }
86
87 Here you can see some "CHECK:" lines specified in comments. Now you can see
88 how the file is piped into llvm-as, then llc, and the machine code output is
89 what we are verifying. FileCheck checks the machine code output to verify that
90 it matches what the "CHECK:" lines specify.
91
92 The syntax of the CHECK: lines is very simple: they are fixed strings that
93 must occur in order. FileCheck defaults to ignoring horizontal whitespace
94 differences (e.g. a space is allowed to match a tab) but otherwise, the contents
95 of the CHECK: line is required to match some thing in the test file exactly.
96
97 One nice thing about FileCheck (compared to grep) is that it allows merging
98 test cases together into logical groups. For example, because the test above
99 is checking for the "sub1:" and "inc4:" labels, it will not match unless there
100 is a "subl" in between those labels. If it existed somewhere else in the file,
101 that would not count: "grep subl" matches if subl exists anywhere in the
102 file.
103
104
105
106 =head2 The FileCheck -check-prefix option
107
108 The FileCheck -check-prefix option allows multiple test configurations to be
109 driven from one .ll file. This is useful in many circumstances, for example,
110 testing different architectural variants with llc. Here's a simple example:
111
112 ; RUN: llvm-as < %s | llc -mtriple=i686-apple-darwin9 -mattr=sse41 \
113 ; RUN: | FileCheck %s -check-prefix=X32>
114 ; RUN: llvm-as < %s | llc -mtriple=x86_64-apple-darwin9 -mattr=sse41 \
115 ; RUN: | FileCheck %s -check-prefix=X64>
116
117 define <4 x i32> @pinsrd_1(i32 %s, <4 x i32> %tmp) nounwind {
118 %tmp1 = insertelement <4 x i32>; %tmp, i32 %s, i32 1
119 ret <4 x i32> %tmp1
120 ; X32: pinsrd_1:
121 ; X32: pinsrd $1, 4(%esp), %xmm0
122
123 ; X64: pinsrd_1:
124 ; X64: pinsrd $1, %edi, %xmm0
125 }
126
127 In this case, we're testing that we get the expected code generation with
128 both 32-bit and 64-bit code generation.
129
130
131
132 =head2 The "CHECK-NEXT:" directive
133
134 Sometimes you want to match lines and would like to verify that matches
135 happen on exactly consecutive lines with no other lines in between them. In
136 this case, you can use CHECK: and CHECK-NEXT: directives to specify this. If
137 you specified a custom check prefix, just use "-NEXT:". For
138 example, something like this works as you'd expect:
139
140 define void @t2(<2 x double>* %r, <2 x double>* %A, double %B) {
141 %tmp3 = load <2 x double>* %A, align 16
142 %tmp7 = insertelement <2 x double> undef, double %B, i32 0
143 %tmp9 = shufflevector <2 x double> %tmp3,
144 <2 x double> %tmp7,
145 <2 x i32> < i32 0, i32 2 >
146 store <2 x double> %tmp9, <2 x double>* %r, align 16
147 ret void
148
149 ; CHECK: t2:
150 ; CHECK: movl 8(%esp), %eax
151 ; CHECK-NEXT: movapd (%eax), %xmm0
152 ; CHECK-NEXT: movhpd 12(%esp), %xmm0
153 ; CHECK-NEXT: movl 4(%esp), %eax
154 ; CHECK-NEXT: movapd %xmm0, (%eax)
155 ; CHECK-NEXT: ret
156 }
157
158 CHECK-NEXT: directives reject the input unless there is exactly one newline
159 between it an the previous directive. A CHECK-NEXT cannot be the first
160 directive in a file.
161
162
163
164 =head2 The "CHECK-NOT:" directive
165
166 The CHECK-NOT: directive is used to verify that a string doesn't occur
167 between two matches (or before the first match, or after the last match). For
168 example, to verify that a load is removed by a transformation, a test like this
169 can be used:
170
171 define i8 @coerce_offset0(i32 %V, i32* %P) {
172 store i32 %V, i32* %P
173
174 %P2 = bitcast i32* %P to i8*
175 %P3 = getelementptr i8* %P2, i32 2
176
177 %A = load i8* %P3
178 ret i8 %A
179 ; CHECK: @coerce_offset0
180 ; CHECK-NOT: load
181 ; CHECK: ret i8
182 }
183
184
185
186 =head2 FileCheck Pattern Matching Syntax
187
188 The CHECK: and CHECK-NOT: directives both take a pattern to match. For most
189 uses of FileCheck, fixed string matching is perfectly sufficient. For some
190 things, a more flexible form of matching is desired. To support this, FileCheck
191 allows you to specify regular expressions in matching strings, surrounded by
192 double braces: B<{{yourregex}}>. Because we want to use fixed string
193 matching for a majority of what we do, FileCheck has been designed to support
194 mixing and matching fixed string matching with regular expressions. This allows
195 you to write things like this:
196
197 ; CHECK: movhpd {{[0-9]+}}(%esp), {{%xmm[0-7]}}
198
199 In this case, any offset from the ESP register will be allowed, and any xmm
200 register will be allowed.
201
202 Because regular expressions are enclosed with double braces, they are
203 visually distinct, and you don't need to use escape characters within the double
204 braces like you would in C. In the rare case that you want to match double
205 braces explicitly from the input, you can use something ugly like
206 B<{{[{][{]}}> as your pattern.
207
208
209
210 =head2 FileCheck Variables
211
212 It is often useful to match a pattern and then verify that it occurs again
213 later in the file. For codegen tests, this can be useful to allow any register,
214 but verify that that register is used consistently later. To do this, FileCheck
215 allows named variables to be defined and substituted into patterns. Here is a
216 simple example:
217
218 ; CHECK: test5:
219 ; CHECK: notw [[REGISTER:%[a-z]+]]
220 ; CHECK: andw {{.*}}[REGISTER]]
221
222 The first check line matches a regex (B<%[a-z]+>) and captures it into
223 the variable "REGISTER". The second line verifies that whatever is in REGISTER
224 occurs later in the file after an "andw". FileCheck variable references are
225 always contained in B<[[ ]]> pairs, are named, and their names can be
226 formed with the regex "B<[a-zA-Z_][a-zA-Z0-9_]*>". If a colon follows the
227 name, then it is a definition of the variable, if not, it is a use.
228
229 FileCheck variables can be defined multiple times, and uses always get the
230 latest value. Note that variables are all read at the start of a "CHECK" line
231 and are all defined at the end. This means that if you have something like
232 "B", the check line will read the previous
233 value of the XYZ variable and define a new one after the match is performed. If
234 you need to do something like this you can probably take advantage of the fact
235 that FileCheck is not actually line-oriented when it matches, this allows you to
236 define two separate CHECK lines that match on the same line.
237
238
239
240 =head1 AUTHORS
241
242 Maintained by The LLVM Team (L).
243
244 =cut
+0
-103
docs/CommandGuide/Makefile less more
None ##===- docs/CommandGuide/Makefile --------------------------*- Makefile -*-===##
1 #
2 # The LLVM Compiler Infrastructure
3 #
4 # This file is distributed under the University of Illinois Open Source
5 # License. See LICENSE.TXT for details.
6 #
7 ##===----------------------------------------------------------------------===##
8
9 ifdef BUILD_FOR_WEBSITE
10 # This special case is for keeping the CommandGuide on the LLVM web site
11 # up to date automatically as the documents are checked in. It must build
12 # the POD files to HTML only and keep them in the src directories. It must also
13 # build in an unconfigured tree, hence the ifdef. To use this, run
14 # make -s BUILD_FOR_WEBSITE=1 inside the cvs commit script.
15 SRC_DOC_DIR=
16 DST_HTML_DIR=html/
17 DST_MAN_DIR=man/man1/
18 DST_PS_DIR=ps/
19
20 # If we are in BUILD_FOR_WEBSITE mode, default to the all target.
21 all:: html man ps
22
23 clean:
24 rm -f pod2htm*.*~~ $(HTML) $(MAN) $(PS)
25
26 # To create other directories, as needed, and timestamp their creation
27 %/.dir:
28 -mkdir $* > /dev/null
29 date > $@
30
31 else
32
33 # Otherwise, if not in BUILD_FOR_WEBSITE mode, use the project info.
34 LEVEL := ../..
35 include $(LEVEL)/Makefile.common
36
37 SRC_DOC_DIR=$(PROJ_SRC_DIR)/
38 DST_HTML_DIR=$(PROJ_OBJ_DIR)/
39 DST_MAN_DIR=$(PROJ_OBJ_DIR)/
40 DST_PS_DIR=$(PROJ_OBJ_DIR)/
41
42 endif
43
44
45 POD := $(wildcard $(SRC_DOC_DIR)*.pod)
46 HTML := $(patsubst $(SRC_DOC_DIR)%.pod, $(DST_HTML_DIR)%.html, $(POD))
47 MAN := $(patsubst $(SRC_DOC_DIR)%.pod, $(DST_MAN_DIR)%.1, $(POD))
48 PS := $(patsubst $(SRC_DOC_DIR)%.pod, $(DST_PS_DIR)%.ps, $(POD))
49
50 # The set of man pages we will not install
51 NO_INSTALL_MANS = $(DST_MAN_DIR)FileCheck.1 $(DST_MAN_DIR)llvm-build.1
52
53 # The set of man pages that we will install
54 INSTALL_MANS = $(filter-out $(NO_INSTALL_MANS), $(MAN))
55
56 .SUFFIXES:
57 .SUFFIXES: .html .pod .1 .ps
58
59 $(DST_HTML_DIR)%.html: %.pod $(DST_HTML_DIR)/.dir
60 pod2html --css=manpage.css --htmlroot=. \
61 --podpath=. --noindex --infile=$< --outfile=$@ --title=$*
62
63 $(DST_MAN_DIR)%.1: %.pod $(DST_MAN_DIR)/.dir
64 pod2man --release=CVS --center="LLVM Command Guide" $< $@
65
66 $(DST_PS_DIR)%.ps: $(DST_MAN_DIR)%.1 $(DST_PS_DIR)/.dir
67 groff -Tps -man $< > $@
68
69
70 html: $(HTML)
71 man: $(MAN)
72 ps: $(PS)
73
74 EXTRA_DIST := $(POD) index.html
75
76 clean-local::
77 $(Verb) $(RM) -f pod2htm*.*~~ $(HTML) $(MAN) $(PS)
78
79 HTML_DIR := $(DESTDIR)$(PROJ_docsdir)/html/CommandGuide
80 MAN_DIR := $(DESTDIR)$(PROJ_mandir)/man1
81 PS_DIR := $(DESTDIR)$(PROJ_docsdir)/ps
82
83 install-local:: $(HTML) $(INSTALL_MANS) $(PS)
84 $(Echo) Installing HTML CommandGuide Documentation
85 $(Verb) $(MKDIR) $(HTML_DIR)
86 $(Verb) $(DataInstall) $(HTML) $(HTML_DIR)
87 $(Verb) $(DataInstall) $(PROJ_SRC_DIR)/index.html $(HTML_DIR)
88 $(Verb) $(DataInstall) $(PROJ_SRC_DIR)/manpage.css $(HTML_DIR)
89 $(Echo) Installing MAN CommandGuide Documentation
90 $(Verb) $(MKDIR) $(MAN_DIR)
91 $(Verb) $(DataInstall) $(INSTALL_MANS) $(MAN_DIR)
92 $(Echo) Installing PS CommandGuide Documentation
93 $(Verb) $(MKDIR) $(PS_DIR)
94 $(Verb) $(DataInstall) $(PS) $(PS_DIR)
95
96 uninstall-local::
97 $(Echo) Uninstalling CommandGuide Documentation
98 $(Verb) $(RM) -rf $(HTML_DIR) $(MAN_DIR) $(PS_DIR)
99
100 printvars::
101 $(Echo) "POD : " '$(POD)'
102 $(Echo) "HTML : " '$(HTML)'
+0
-186
docs/CommandGuide/bugpoint.pod less more
None =pod
1
2 =head1 NAME
3
4 bugpoint - automatic test case reduction tool
5
6 =head1 SYNOPSIS
7
8 B [I] [I] [I] B<--args>
9 I
10
11 =head1 DESCRIPTION
12
13 B narrows down the source of problems in LLVM tools and passes. It
14 can be used to debug three types of failures: optimizer crashes, miscompilations
15 by optimizers, or bad native code generation (including problems in the static
16 and JIT compilers). It aims to reduce large test cases to small, useful ones.
17 For more information on the design and inner workings of B, as well as
18 advice for using bugpoint, see F in the LLVM
19 distribution.
20
21 =head1 OPTIONS
22
23 =over
24
25 =item B<--additional-so> F
26
27 Load the dynamic shared object F into the test program whenever it is
28 run. This is useful if you are debugging programs which depend on non-LLVM
29 libraries (such as the X or curses libraries) to run.
30
31 =item B<--append-exit-code>=I<{true,false}>
32
33 Append the test programs exit code to the output file so that a change in exit
34 code is considered a test failure. Defaults to false.
35
36 =item B<--args> I
37
38 Pass all arguments specified after -args to the test program whenever it runs.
39 Note that if any of the I start with a '-', you should use:
40
41 bugpoint [bugpoint args] --args -- [program args]
42
43 The "--" right after the B<--args> option tells B to consider any
44 options starting with C<-> to be part of the B<--args> option, not as options to
45 B itself.
46
47 =item B<--tool-args> I
48
49 Pass all arguments specified after --tool-args to the LLVM tool under test
50 (B, B, etc.) whenever it runs. You should use this option in the
51 following way:
52
53 bugpoint [bugpoint args] --tool-args -- [tool args]
54
55 The "--" right after the B<--tool-args> option tells B to consider any
56 options starting with C<-> to be part of the B<--tool-args> option, not as
57 options to B itself. (See B<--args>, above.)
58
59 =item B<--safe-tool-args> I
60
61 Pass all arguments specified after B<--safe-tool-args> to the "safe" execution
62 tool.
63
64 =item B<--gcc-tool-args> I
65
66 Pass all arguments specified after B<--gcc-tool-args> to the invocation of
67 B.
68
69 =item B<--opt-args> I
70
71 Pass all arguments specified after B<--opt-args> to the invocation of B.
72
73 =item B<--disable-{dce,simplifycfg}>
74
75 Do not run the specified passes to clean up and reduce the size of the test
76 program. By default, B uses these passes internally when attempting to
77 reduce test programs. If you're trying to find a bug in one of these passes,
78 B may crash.
79
80 =item B<--enable-valgrind>
81
82 Use valgrind to find faults in the optimization phase. This will allow
83 bugpoint to find otherwise asymptomatic problems caused by memory
84 mis-management.
85
86 =item B<-find-bugs>
87
88 Continually randomize the specified passes and run them on the test program
89 until a bug is found or the user kills B.
90
91 =item B<-help>
92
93 Print a summary of command line options.
94
95 =item B<--input> F
96
97 Open F and redirect the standard input of the test program, whenever
98 it runs, to come from that file.
99
100 =item B<--load> F
101
102 Load the dynamic object F into B itself. This object should
103 register new optimization passes. Once loaded, the object will add new command
104 line options to enable various optimizations. To see the new complete list of
105 optimizations, use the B<-help> and B<--load> options together; for example:
106
107 bugpoint --load myNewPass.so -help
108
109 =item B<--mlimit> F
110
111 Specifies an upper limit on memory usage of the optimization and codegen. Set
112 to zero to disable the limit.
113
114 =item B<--output> F
115
116 Whenever the test program produces output on its standard output stream, it
117 should match the contents of F (the "reference output"). If you
118 do not use this option, B will attempt to generate a reference output
119 by compiling the program with the "safe" backend and running it.
120
121 =item B<--profile-info-file> F
122
123 Profile file loaded by B<--profile-loader>.
124
125 =item B<--run-{int,jit,llc,custom}>
126
127 Whenever the test program is compiled, B should generate code for it
128 using the specified code generator. These options allow you to choose the
129 interpreter, the JIT compiler, the static native code compiler, or a
130 custom command (see B<--exec-command>) respectively.
131
132 =item B<--safe-{llc,custom}>
133
134 When debugging a code generator, B should use the specified code
135 generator as the "safe" code generator. This is a known-good code generator
136 used to generate the "reference output" if it has not been provided, and to
137 compile portions of the program that as they are excluded from the testcase.
138 These options allow you to choose the
139 static native code compiler, or a custom command, (see B<--exec-command>)
140 respectively. The interpreter and the JIT backends cannot currently
141 be used as the "safe" backends.
142
143 =item B<--exec-command> I
144
145 This option defines the command to use with the B<--run-custom> and
146 B<--safe-custom> options to execute the bitcode testcase. This can
147 be useful for cross-compilation.
148
149 =item B<--compile-command> I
150
151 This option defines the command to use with the B<--compile-custom>
152 option to compile the bitcode testcase. This can be useful for
153 testing compiler output without running any link or execute stages. To
154 generate a reduced unit test, you may add CHECK directives to the
155 testcase and pass the name of an executable compile-command script in this form:
156
157 #!/bin/sh
158 llc "$@"
159 not FileCheck [bugpoint input file].ll < bugpoint-test-program.s
160
161 This script will "fail" as long as FileCheck passes. So the result
162 will be the minimum bitcode that passes FileCheck.
163
164 =item B<--safe-path> I
165
166 This option defines the path to the command to execute with the
167 B<--safe-{int,jit,llc,custom}>
168 option.
169
170 =back
171
172 =head1 EXIT STATUS
173
174 If B succeeds in finding a problem, it will exit with 0. Otherwise,
175 if an error occurs, it will exit with a non-zero value.
176
177 =head1 SEE ALSO
178
179 L
180
181 =head1 AUTHOR
182
183 Maintained by the LLVM Team (L).
184
185 =cut
+0
-256
docs/CommandGuide/html/manpage.css less more
None /* Based on http://www.perldoc.com/css/perldoc.css */
1
2 @import url("../llvm.css");
3
4 body { font-family: Arial,Helvetica; }
5
6 blockquote { margin: 10pt; }
7
8 h1, a { color: #336699; }
9
10
11 /*** Top menu style ****/
12 .mmenuon {
13 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
14 color: #ff6600; font-size: 10pt;
15 }
16 .mmenuoff {
17 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
18 color: #ffffff; font-size: 10pt;
19 }
20 .cpyright {
21 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
22 color: #ffffff; font-size: xx-small;
23 }
24 .cpyrightText {
25 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
26 color: #ffffff; font-size: xx-small;
27 }
28 .sections {
29 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
30 color: #336699; font-size: 11pt;
31 }
32 .dsections {
33 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
34 color: #336699; font-size: 12pt;
35 }
36 .slink {
37 font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
38 color: #000000; font-size: 9pt;
39 }
40
41 .slink2 { font-family: Arial,Helvetica; text-decoration: none; color: #336699; }
42
43 .maintitle {
44 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
45 color: #336699; font-size: 18pt;
46 }
47 .dblArrow {
48 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
49 color: #336699; font-size: small;
50 }
51 .menuSec {
52 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
53 color: #336699; font-size: small;
54 }
55
56 .newstext {
57 font-family: Arial,Helvetica; font-size: small;
58 }
59
60 .linkmenu {
61 font-family: Arial,Helvetica; color: #000000; font-weight: bold;
62 text-decoration: none;
63 }
64
65 P {
66 font-family: Arial,Helvetica;
67 }
68
69 PRE {
70 font-size: 10pt;
71 }
72 .quote {
73 font-family: Times; text-decoration: none;
74 color: #000000; font-size: 9pt; font-style: italic;
75 }
76 .smstd { font-family: Arial,Helvetica; color: #000000; font-size: x-small; }
77 .std { font-family: Arial,Helvetica; color: #000000; }
78 .meerkatTitle {
79 font-family: sans-serif; font-size: x-small; color: black; }
80
81 .meerkatDescription { font-family: sans-serif; font-size: 10pt; color: black }
82 .meerkatCategory {
83 font-family: sans-serif; font-size: 9pt; font-weight: bold; font-style: italic;
84 color: brown; }
85 .meerkatChannel {
86 font-family: sans-serif; font-size: 9pt; font-style: italic; color: brown; }
87 .meerkatDate { font-family: sans-serif; font-size: xx-small; color: #336699; }
88
89 .tocTitle {
90 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
91 color: #333333; font-size: 10pt;
92 }
93
94 .toc-item {
95 font-family: Arial,Helvetica; font-weight: bold;
96 color: #336699; font-size: 10pt; text-decoration: underline;
97 }
98
99 .perlVersion {
100 font-family: Arial,Helvetica; font-weight: bold;
101 color: #336699; font-size: 10pt; text-decoration: none;
102 }
103
104 .podTitle {
105 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
106 color: #000000;
107 }
108
109 .docTitle {
110 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
111 color: #000000; font-size: 10pt;
112 }
113 .dotDot {
114 font-family: Arial,Helvetica; font-weight: bold;
115 color: #000000; font-size: 9pt;
116 }
117
118 .docSec {
119 font-family: Arial,Helvetica; font-weight: normal;
120 color: #333333; font-size: 9pt;
121 }
122 .docVersion {
123 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
124 color: #336699; font-size: 10pt;
125 }
126
127 .docSecs-on {
128 font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
129 color: #ff0000; font-size: 10pt;
130 }
131 .docSecs-off {
132 font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
133 color: #333333; font-size: 10pt;
134 }
135
136 h2 {
137 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
138 color: #336699; font-size: medium;
139 }
140 h1 {
141 font-family: Verdana,Arial,Helvetica; font-weight: bold; text-decoration: none;
142 color: #336699; font-size: large;
143 }
144
145 DL {
146 font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
147 color: #333333; font-size: 10pt;
148 }
149
150 UL > LI > A {
151 font-family: Arial,Helvetica; font-weight: bold;
152 color: #336699; font-size: 10pt;
153 }
154
155 .moduleInfo {
156 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
157 color: #333333; font-size: 11pt;
158 }
159
160 .moduleInfoSec {
161 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
162 color: #336699; font-size: 10pt;
163 }
164
165 .moduleInfoVal {
166 font-family: Arial,Helvetica; font-weight: normal; text-decoration: underline;
167 color: #000000; font-size: 10pt;
168 }
169
170 .cpanNavTitle {
171 font-family: Arial,Helvetica; font-weight: bold;
172 color: #ffffff; font-size: 10pt;
173 }
174 .cpanNavLetter {
175 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
176 color: #333333; font-size: 9pt;
177 }
178 .cpanCat {
179 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
180 color: #336699; font-size: 9pt;
181 }
182
183 .bttndrkblue-bkgd-top {
184 background-color: #225688;
185 background-image: url(/global/mvc_objects/images/bttndrkblue_bgtop.gif);
186 }
187 .bttndrkblue-bkgd-left {
188 background-color: #225688;
189 background-image: url(/global/mvc_objects/images/bttndrkblue_bgleft.gif);
190 }
191 .bttndrkblue-bkgd {
192 padding-top: 0px;
193 padding-bottom: 0px;
194 margin-bottom: 0px;
195 margin-top: 0px;
196 background-repeat: no-repeat;
197 background-color: #225688;
198 background-image: url(/global/mvc_objects/images/bttndrkblue_bgmiddle.gif);
199 vertical-align: top;
200 }
201 .bttndrkblue-bkgd-right {
202 background-color: #225688;
203 background-image: url(/global/mvc_objects/images/bttndrkblue_bgright.gif);
204 }
205 .bttndrkblue-bkgd-bottom {
206 background-color: #225688;
207 background-image: url(/global/mvc_objects/images/bttndrkblue_bgbottom.gif);
208 }
209 .bttndrkblue-text a {
210 color: #ffffff;
211 text-decoration: none;
212 }
213 a.bttndrkblue-text:hover {
214 color: #ffDD3C;
215 text-decoration: none;
216 }
217 .bg-ltblue {
218 background-color: #f0f5fa;
219 }
220
221 .border-left-b {
222 background: #f0f5fa url(/i/corner-leftline.gif) repeat-y;
223 }
224
225 .border-right-b {
226 background: #f0f5fa url(/i/corner-rightline.gif) repeat-y;
227 }
228
229 .border-top-b {
230 background: #f0f5fa url(/i/corner-topline.gif) repeat-x;
231 }
232
233 .border-bottom-b {
234 background: #f0f5fa url(/i/corner-botline.gif) repeat-x;
235 }
236
237 .border-right-w {
238 background: #ffffff url(/i/corner-rightline.gif) repeat-y;
239 }
240
241 .border-top-w {
242 background: #ffffff url(/i/corner-topline.gif) repeat-x;
243 }
244
245 .border-bottom-w {
246 background: #ffffff url(/i/corner-botline.gif) repeat-x;
247 }
248
249 .bg-white {
250 background-color: #ffffff;
251 }
252
253 .border-left-w {
254 background: #ffffff url(/i/corner-leftline.gif) repeat-y;
255 }
+0
-139
docs/CommandGuide/index.html less more
None
1 "http://www.w3.org/TR/html4/strict.dtd">
2
3
4 LLVM Command Guide
5
6
7
8
9

10 LLVM Command Guide
11
12
13
14
15

These documents are HTML versions of the man pages

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

21
22
23
24
25

26 Basic Commands
27
28
29
30
31
32
33
34
  • llvm-as -
  • 35 assemble a human-readable .ll file into bytecode
    36
    37
  • llvm-dis -
  • 38 disassemble a bytecode file into a human-readable .ll file
    39
    40
  • opt -
  • 41 run a series of LLVM-to-LLVM optimizations on a bytecode file
    42
    43
  • llc -
  • 44 generate native machine code for a bytecode file
    45
    46
  • lli -
  • 47 directly run a program compiled to bytecode using a JIT compiler or
    48 interpreter
    49
    50
  • llvm-link -
  • 51 link several bytecode files into one
    52
    53
  • llvm-ar -
  • 54 archive bytecode files
    55
    56
  • llvm-ranlib -
  • 57 create an index for archives made with llvm-ar
    58
    59
  • llvm-nm -
  • 60 print out the names and types of symbols in a bytecode file
    61
    62
  • llvm-prof -
  • 63 format raw `llvmprof.out' data into a human-readable report
    64
    65
  • llvm-config -
  • 66 print out LLVM compilation options, libraries, etc. as configured
    67
    68
  • llvm-diff -
  • 69 structurally compare two modules
    70
    71
  • llvm-cov -
  • 72 emit coverage information
    73
    74
  • llvm-stress -
  • 75 generate random .ll files to fuzz different llvm components
    76
    77
    78
    79
    80
    81
    82

    83 Debugging Tools
    84
    85
    86
    87
    88
    89
    90
    91
    92
  • bugpoint -
  • 93 automatic test-case reducer
    94
    95
  • llvm-extract -
  • 96 extract a function from an LLVM bytecode file
    97
    98
  • llvm-bcanalyzer -
  • 99 bytecode analyzer (analyzes the binary encoding itself, not the program it
    100 represents)
    101
    102
    103
    104
    105
    106

    107 Internal Tools
    108
    109
    110
    111
    112
    113
    114
  • FileCheck -
  • 115 Flexible file verifier used extensively by the testing harness
    116
  • tblgen -
  • 117 target description reader and generator
    118
  • lit -
  • 119 LLVM Integrated Tester, for running tests
    120
    121
    122
    123
    124
    125
    126
    127
    128
    129 src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS">
    130
    131 src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01">
    132
    133 LLVM Compiler Infrastructure
    134 Last modified: $Date$
    135
    136
    137
    138
    +0
    -404
    docs/CommandGuide/lit.pod less more
    None =pod
    1
    2 =head1 NAME
    3
    4 lit - LLVM Integrated Tester
    5
    6 =head1 SYNOPSIS
    7
    8 B [I] [I]
    9
    10 =head1 DESCRIPTION
    11
    12 B is a portable tool for executing LLVM and Clang style test suites,
    13 summarizing their results, and providing indication of failures. B is
    14 designed to be a lightweight testing tool with as simple a user interface as
    15 possible.
    16
    17 B should be run with one or more I to run specified on the command
    18 line. Tests can be either individual test files or directories to search for
    19 tests (see L<"TEST DISCOVERY">).
    20
    21 Each specified test will be executed (potentially in parallel) and once all
    22 tests have been run B will print summary information on the number of tests
    23 which passed or failed (see L<"TEST STATUS RESULTS">). The B program will
    24 execute with a non-zero exit code if any tests fail.
    25
    26 By default B will use a succinct progress display and will only print
    27 summary information for test failures. See L<"OUTPUT OPTIONS"> for options
    28 controlling the B progress display and output.
    29
    30 B also includes a number of options for controlling how tests are executed
    31 (specific features may depend on the particular test format). See L<"EXECUTION
    32 OPTIONS"> for more information.
    33
    34 Finally, B also supports additional options for only running a subset of
    35 the options specified on the command line, see L<"SELECTION OPTIONS"> for
    36 more information.
    37
    38 Users interested in the B architecture or designing a B testing
    39 implementation should see L<"LIT INFRASTRUCTURE">
    40
    41 =head1 GENERAL OPTIONS
    42
    43 =over
    44
    45 =item B<-h>, B<--help>
    46
    47 Show the B help message.
    48
    49 =item B<-j> I, B<--threads>=I
    50
    51 Run I tests in parallel. By default, this is automatically chosen to match
    52 the number of detected available CPUs.
    53
    54 =item B<--config-prefix>=I
    55
    56 Search for I and I when searching for test suites,
    57 instead of I and I.
    58
    59 =item B<--param> I, B<--param> I=I
    60
    61 Add a user defined parameter I with the given I (or the empty
    62 string if not given). The meaning and use of these parameters is test suite
    63 dependent.
    64
    65 =back
    66
    67 =head1 OUTPUT OPTIONS
    68
    69 =over
    70
    71 =item B<-q>, B<--quiet>
    72
    73 Suppress any output except for test failures.
    74
    75 =item B<-s>, B<--succinct>
    76
    77 Show less output, for example don't show information on tests that pass.
    78
    79 =item B<-v>, B<--verbose>
    80
    81 Show more information on test failures, for example the entire test output
    82 instead of just the test result.
    83
    84 =item B<--no-progress-bar>
    85
    86 Do not use curses based progress bar.
    87
    88 =back
    89
    90 =head1 EXECUTION OPTIONS
    91
    92 =over
    93
    94 =item B<--path>=I
    95
    96 Specify an addition I to use when searching for executables in tests.
    97
    98 =item B<--vg>
    99
    100 Run individual tests under valgrind (using the memcheck tool). The
    101 I<--error-exitcode> argument for valgrind is used so that valgrind failures will
    102 cause the program to exit with a non-zero status.
    103
    104 =item B<--vg-arg>=I
    105
    106 When I<--vg> is used, specify an additional argument to pass to valgrind itself.
    107
    108 =item B<--time-tests>
    109
    110 Track the wall time individual tests take to execute and includes the results in
    111 the summary output. This is useful for determining which tests in a test suite
    112 take the most time to execute. Note that this option is most useful with I<-j
    113 1>.
    114
    115 =back
    116
    117 =head1 SELECTION OPTIONS
    118
    119 =over
    120
    121 =item B<--max-tests>=I
    122
    123 Run at most I tests and then terminate.
    124
    125 =item B<--max-time>=I
    126
    127 Spend at most I seconds (approximately) running tests and then terminate.
    128
    129 =item B<--shuffle>
    130
    131 Run the tests in a random order.
    132
    133 =back
    134
    135 =head1 ADDITIONAL OPTIONS
    136
    137 =over
    138
    139 =item B<--debug>
    140
    141 Run B in debug mode, for debugging configuration issues and B itself.
    142
    143 =item B<--show-suites>
    144
    145 List the discovered test suites as part of the standard output.
    146
    147 =item B<--no-tcl-as-sh>
    148
    149 Run Tcl scripts internally (instead of converting to shell scripts).
    150
    151 =item B<--repeat>=I
    152
    153 Run each test I times. Currently this is primarily useful for timing tests,
    154 other results are not collated in any reasonable fashion.
    155
    156 =back
    157
    158 =head1 EXIT STATUS
    159
    160 B will exit with an exit code of 1 if there are any FAIL or XPASS
    161 results. Otherwise, it will exit with the status 0. Other exit codes are used
    162 for non-test related failures (for example a user error or an internal program
    163 error).
    164
    165 =head1 TEST DISCOVERY
    166
    167 The inputs passed to B can be either individual tests, or entire
    168 directories or hierarchies of tests to run. When B starts up, the first
    169 thing it does is convert the inputs into a complete list of tests to run as part
    170 of I.
    171
    172 In the B model, every test must exist inside some I. B
    173 resolves the inputs specified on the command line to test suites by searching
    174 upwards from the input path until it finds a I or I
    175 file. These files serve as both a marker of test suites and as configuration
    176 files which B loads in order to understand how to find and run the tests
    177 inside the test suite.
    178
    179 Once B has mapped the inputs into test suites it traverses the list of
    180 inputs adding tests for individual files and recursively searching for tests in
    181 directories.
    182
    183 This behavior makes it easy to specify a subset of tests to run, while still
    184 allowing the test suite configuration to control exactly how tests are
    185 interpreted. In addition, B always identifies tests by the test suite they
    186 are in, and their relative path inside the test suite. For appropriately
    187 configured projects, this allows B to provide convenient and flexible
    188 support for out-of-tree builds.
    189
    190 =head1 TEST STATUS RESULTS
    191
    192 Each test ultimately produces one of the following six results:
    193
    194 =over
    195
    196 =item B
    197
    198 The test succeeded.
    199
    200 =item B
    201
    202 The test failed, but that is expected. This is used for test formats which allow
    203 specifying that a test does not currently work, but wish to leave it in the test
    204 suite.
    205
    206 =item B
    207
    208 The test succeeded, but it was expected to fail. This is used for tests which
    209 were specified as expected to fail, but are now succeeding (generally because
    210 the feature they test was broken and has been fixed).
    211
    212 =item B
    213
    214 The test failed.
    215
    216 =item B
    217
    218 The test result could not be determined. For example, this occurs when the test
    219 could not be run, the test itself is invalid, or the test was interrupted.
    220
    221 =item B
    222
    223 The test is not supported in this environment. This is used by test formats
    224 which can report unsupported tests.
    225
    226 =back
    227
    228 Depending on the test format tests may produce additional information about
    229 their status (generally only for failures). See the L
    230 section for more information.
    231
    232 =head1 LIT INFRASTRUCTURE
    233
    234 This section describes the B testing architecture for users interested in
    235 creating a new B testing implementation, or extending an existing one.
    236
    237 B proper is primarily an infrastructure for discovering and running
    238 arbitrary tests, and to expose a single convenient interface to these
    239 tests. B itself doesn't know how to run tests, rather this logic is
    240 defined by I.
    241
    242 =head2 TEST SUITES
    243
    244 As described in L<"TEST DISCOVERY">, tests are always located inside a I
    245 suite>. Test suites serve to define the format of the tests they contain, the
    246 logic for finding those tests, and any additional information to run the tests.
    247
    248 B identifies test suites as directories containing I or
    249 I files (see also B<--config-prefix>). Test suites are initially
    250 discovered by recursively searching up the directory hierarchy for all the input
    251 files passed on the command line. You can use B<--show-suites> to display the
    252 discovered test suites at startup.
    253
    254 Once a test suite is discovered, its config file is loaded. Config files
    255 themselves are Python modules which will be executed. When the config file is
    256 executed, two important global variables are predefined:
    257
    258 =over
    259
    260 =item B
    261
    262 The global B configuration object (a I instance), which defines
    263 the builtin test formats, global configuration parameters, and other helper
    264 routines for implementing test configurations.
    265
    266 =item B
    267
    268 This is the config object (a I instance) for the test suite,
    269 which the config file is expected to populate. The following variables are also
    270 available on the I object, some of which must be set by the config and
    271 others are optional or predefined:
    272
    273 B I<[required]> The name of the test suite, for use in reports and
    274 diagnostics.
    275
    276 B I<[required]> The test format object which will be used to
    277 discover and run tests in the test suite. Generally this will be a builtin test
    278 format available from the I module.
    279
    280 B The filesystem path to the test suite root. For out-of-dir
    281 builds this is the directory that will be scanned for tests.
    282
    283 B For out-of-dir builds, the path to the test suite root inside
    284 the object directory. This is where tests will be run and temporary output files
    285 placed.
    286
    287 B A dictionary representing the environment to use when executing
    288 tests in the suite.
    289
    290 B For B test formats which scan directories for tests, this
    291 variable is a list of suffixes to identify test files. Used by: I,
    292 I.
    293
    294 B For B test formats which substitute variables into a test
    295 script, the list of substitutions to perform. Used by: I, I.
    296
    297 B Mark an unsupported directory, all tests within it will be
    298 reported as unsupported. Used by: I, I.
    299
    300 B The parent configuration, this is the config object for the directory
    301 containing the test suite, or None.
    302
    303 B The root configuration. This is the top-most B configuration in
    304 the project.
    305
    306 B The config is actually cloned for every subdirectory inside a test
    307 suite, to allow local configuration on a per-directory basis. The I
    308 variable can be set to a Python function which will be called whenever a
    309 configuration is cloned (for a subdirectory). The function should takes three
    310 arguments: (1) the parent configuration, (2) the new configuration (which the
    311 I function will generally modify), and (3) the test path to the new
    312 directory being scanned.
    313
    314 =back
    315
    316 =head2 TEST DISCOVERY
    317
    318 Once test suites are located, B recursively traverses the source directory
    319 (following I) looking for tests. When B enters a
    320 sub-directory, it first checks to see if a nested test suite is defined in that
    321 directory. If so, it loads that test suite recursively, otherwise it
    322 instantiates a local test config for the directory (see L<"LOCAL CONFIGURATION
    323 FILES">).
    324
    325 Tests are identified by the test suite they are contained within, and the
    326 relative path inside that suite. Note that the relative path may not refer to an
    327 actual file on disk; some test formats (such as I) define "virtual
    328 tests" which have a path that contains both the path to the actual test file and
    329 a subpath to identify the virtual test.
    330
    331 =head2 LOCAL CONFIGURATION FILES
    332
    333 When B loads a subdirectory in a test suite, it instantiates a local test
    334 configuration by cloning the configuration for the parent direction -- the root
    335 of this configuration chain will always be a test suite. Once the test
    336 configuration is cloned B checks for a I file in the
    337 subdirectory. If present, this file will be loaded and can be used to specialize
    338 the configuration for each individual directory. This facility can be used to
    339 define subdirectories of optional tests, or to change other configuration
    340 parameters -- for example, to change the test format, or the suffixes which
    341 identify test files.
    342
    343 =head2 TEST RUN OUTPUT FORMAT
    344
    345 The b output for a test run conforms to the following schema, in both short
    346 and verbose modes (although in short mode no PASS lines will be shown). This
    347 schema has been chosen to be relatively easy to reliably parse by a machine (for
    348 example in buildbot log scraping), and for other tools to generate.
    349
    350 Each test result is expected to appear on a line that matches:
    351
    352 : ()
    353
    354 where is a standard test result such as PASS, FAIL, XFAIL, XPASS,
    355 UNRESOLVED, or UNSUPPORTED. The performance result codes of IMPROVED and
    356 REGRESSED are also allowed.
    357
    358 The field can consist of an arbitrary string containing no newline.
    359
    360 The field can be used to report progress information such as
    361 (1/300) or can be empty, but even when empty the parentheses are required.
    362
    363 Each test result may include additional (multiline) log information in the
    364 following format.
    365
    366 TEST '()'
    367 ... log message ...
    368
    369
    370 where should be the name of a preceeding reported test,
    371 delineator> is a string of '*' characters I four characters long (the
    372 recommended length is 20), and is an arbitrary (unparsed)
    373 string.
    374
    375 The following is an example of a test run output which consists of four tests A,
    376 B, C, and D, and a log message for the failing test C.
    377
    378 =head3 Example Test Run Output Listing
    379
    380 PASS: A (1 of 4)
    381 PASS: B (2 of 4)
    382 FAIL: C (3 of 4)
    383 ******************** TEST 'C' FAILED ********************
    384 Test 'C' failed as a result of exit code 1.
    385 ********************
    386 PASS: D (4 of 4)
    387
    388 =back
    389
    390 =head2 LIT EXAMPLE TESTS
    391
    392 The B distribution contains several example implementations of test suites
    393 in the I directory.
    394
    395 =head1 SEE ALSO
    396
    397 L
    398
    399 =head1 AUTHOR
    400
    401 Written by Daniel Dunbar and maintained by the LLVM Team (L).
    402
    403 =cut
    +0
    -201
    docs/CommandGuide/llc.pod less more
    None =pod
    1
    2 =head1 NAME
    3
    4 llc - LLVM static compiler
    5
    6 =head1 SYNOPSIS
    7
    8 B [I] [I]
    9
    10 =head1 DESCRIPTION
    11
    12 The B command compiles LLVM source inputs into assembly language for a
    13 specified architecture. The assembly language output can then be passed through
    14 a native assembler and linker to generate a native executable.
    15
    16 The choice of architecture for the output assembly code is automatically
    17 determined from the input file, unless the B<-march> option is used to override
    18 the default.
    19
    20 =head1 OPTIONS
    21
    22 If I is - or omitted, B reads from standard input. Otherwise, it
    23 will from I. Inputs can be in either the LLVM assembly language
    24 format (.ll) or the LLVM bitcode format (.bc).
    25
    26 If the B<-o> option is omitted, then B will send its output to standard
    27 output if the input is from standard input. If the B<-o> option specifies -,
    28 then the output will also be sent to standard output.
    29
    30 If no B<-o> option is specified and an input file other than - is specified,
    31 then B creates the output filename by taking the input filename,
    32 removing any existing F<.bc> extension, and adding a F<.s> suffix.
    33
    34 Other B options are as follows:
    35
    36 =head2 End-user Options
    37
    38 =over
    39
    40 =item B<-help>
    41
    42 Print a summary of command line options.
    43
    44 =item B<-O>=I
    45
    46 Generate code at different optimization levels. These correspond to the I<-O0>,
    47 I<-O1>, I<-O2>, and I<-O3> optimization levels used by B and
    48 B.
    49
    50 =item B<-mtriple>=I
    51
    52 Override the target triple specified in the input file with the specified
    53 string.
    54
    55 =item B<-march>=I
    56
    57 Specify the architecture for which to generate assembly, overriding the target
    58 encoded in the input file. See the output of B for a list of
    59 valid architectures. By default this is inferred from the target triple or
    60 autodetected to the current architecture.
    61
    62 =item B<-mcpu>=I
    63
    64 Specify a specific chip in the current architecture to generate code for.
    65 By default this is inferred from the target triple and autodetected to
    66 the current architecture. For a list of available CPUs, use:
    67 B /dev/null | llc -march=xyz -mcpu=help>
    68
    69 =item B<-mattr>=I
    70
    71 Override or control specific attributes of the target, such as whether SIMD
    72 operations are enabled or not. The default set of attributes is set by the
    73 current CPU. For a list of available attributes, use:
    74 B /dev/null | llc -march=xyz -mattr=help>
    75
    76 =item B<--disable-fp-elim>
    77
    78 Disable frame pointer elimination optimization.
    79
    80 =item B<--disable-excess-fp-precision>
    81
    82 Disable optimizations that may produce excess precision for floating point.
    83 Note that this option can dramatically slow down code on some systems
    84 (e.g. X86).
    85
    86 =item B<--enable-no-infs-fp-math>
    87
    88 Enable optimizations that assume no Inf values.
    89
    90 =item B<--enable-no-nans-fp-math>
    91
    92 Enable optimizations that assume no NAN values.
    93
    94 =item B<--enable-unsafe-fp-math>
    95
    96 Enable optimizations that make unsafe assumptions about IEEE math (e.g. that
    97 addition is associative) or may not work for all input ranges. These
    98 optimizations allow the code generator to make use of some instructions which
    99 would otherwise not be usable (such as fsin on X86).
    100
    101 =item B<--enable-correct-eh-support>
    102
    103 Instruct the B pass to insert code for correct exception handling
    104 support. This is expensive and is by default omitted for efficiency.
    105
    106 =item B<--stats>
    107
    108 Print statistics recorded by code-generation passes.
    109
    110 =item B<--time-passes>
    111
    112 Record the amount of time needed for each pass and print a report to standard
    113 error.
    114
    115 =item B<--load>=F
    116
    117 Dynamically load F (a path to a dynamically shared object) that
    118 implements an LLVM target. This will permit the target name to be used with the
    119 B<-march> option so that code can be generated for that target.
    120
    121 =back
    122
    123 =head2 Tuning/Configuration Options
    124
    125 =over
    126
    127 =item B<--print-machineinstrs>
    128
    129 Print generated machine code between compilation phases (useful for debugging).
    130
    131 =item B<--regalloc>=I
    132
    133 Specify the register allocator to use. The default I is I.
    134 Valid register allocators are:
    135
    136 =over
    137
    138 =item I
    139
    140 Very simple "always spill" register allocator
    141
    142 =item I
    143
    144 Local register allocator
    145
    146 =item I
    147
    148 Linear scan global register allocator
    149
    150 =item I
    151
    152 Iterative scan global register allocator
    153
    154 =back
    155
    156 =item B<--spiller>=I
    157
    158 Specify the spiller to use for register allocators that support it. Currently
    159 this option is used only by the linear scan register allocator. The default
    160 I is I. Valid spillers are:
    161
    162 =over
    163
    164 =item I
    165
    166 Simple spiller
    167
    168 =item I
    169
    170 Local spiller
    171
    172 =back
    173
    174 =back
    175
    176 =head2 Intel IA-32-specific Options
    177
    178 =over
    179
    180 =item B<--x86-asm-syntax=att|intel>
    181
    182 Specify whether to emit assembly code in AT&T syntax (the default) or intel
    183 syntax.
    184
    185 =back
    186
    187 =head1 EXIT STATUS
    188
    189 If B succeeds, it will exit with 0. Otherwise, if an error occurs,
    190 it will exit with a non-zero value.
    191
    192 =head1 SEE ALSO
    193
    194 L
    195
    196 =head1 AUTHORS
    197
    198 Maintained by the LLVM Team (L).
    199
    200 =cut
    +0
    -219
    docs/CommandGuide/lli.pod less more
    None =pod
    1
    2 =head1 NAME
    3
    4 lli - directly execute programs from LLVM bitcode
    5
    6 =head1 SYNOPSIS
    7
    8 B [I] [I] [I]
    9
    10 =head1 DESCRIPTION
    11
    12 B directly executes programs in LLVM bitcode format. It takes a program
    13 in LLVM bitcode format and executes it using a just-in-time compiler, if one is
    14 available for the current architecture, or an interpreter. B takes all of
    15 the same code generator options as L, but they are only effective when
    16 B is using the just-in-time compiler.
    17
    18 If I is not specified, then B reads the LLVM bitcode for the
    19 program from standard input.
    20
    21 The optional I specified on the command line are passed to the program as
    22 arguments.
    23
    24 =head1 GENERAL OPTIONS
    25
    26 =over
    27
    28 =item B<-fake-argv0>=I
    29
    30 Override the C value passed into the executing program.
    31
    32 =item B<-force-interpreter>=I<{false,true}>
    33
    34 If set to true, use the interpreter even if a just-in-time compiler is available
    35 for this architecture. Defaults to false.
    36
    37 =item B<-help>
    38
    39 Print a summary of command line options.
    40
    41 =item B<-load>=I
    42
    43 Causes B to load the plugin (shared object) named I and use
    44 it for optimization.
    45
    46 =item B<-stats>
    47
    48 Print statistics from the code-generation passes. This is only meaningful for
    49 the just-in-time compiler, at present.
    50
    51 =item B<-time-passes>
    52
    53 Record the amount of time needed for each code-generation pass and print it to
    54 standard error.
    55
    56 =item B<-version>
    57
    58 Print out the version of B and exit without doing anything else.
    59
    60 =back
    61
    62 =head1 TARGET OPTIONS
    63
    64 =over
    65
    66 =item B<-mtriple>=I
    67
    68 Override the target triple specified in the input bitcode file with the
    69 specified string. This may result in a crash if you pick an
    70 architecture which is not compatible with the current system.
    71
    72 =item B<-march>=I
    73
    74 Specify the architecture for which to generate assembly, overriding the target
    75 encoded in the bitcode file. See the output of B for a list of
    76 valid architectures. By default this is inferred from the target triple or
    77 autodetected to the current architecture.
    78
    79 =item B<-mcpu>=I
    80
    81 Specify a specific chip in the current architecture to generate code for.
    82 By default this is inferred from the target triple and autodetected to
    83 the current architecture. For a list of available CPUs, use:
    84 B /dev/null | llc -march=xyz -mcpu=help>
    85
    86 =item B<-mattr>=I
    87
    88 Override or control specific attributes of the target, such as whether SIMD
    89 operations are enabled or not. The default set of attributes is set by the
    90 current CPU. For a list of available attributes, use:
    91 B /dev/null | llc -march=xyz -mattr=help>
    92
    93 =back
    94
    95
    96 =head1 FLOATING POINT OPTIONS
    97
    98 =over
    99
    100 =item B<-disable-excess-fp-precision>
    101
    102 Disable optimizations that may increase floating point precision.
    103
    104 =item B<-enable-no-infs-fp-math>
    105
    106 Enable optimizations that assume no Inf values.
    107
    108 =item B<-enable-no-nans-fp-math>
    109
    110 Enable optimizations that assume no NAN values.
    111
    112 =item B<-enable-unsafe-fp-math>
    113
    114 Causes B to enable optimizations that may decrease floating point
    115 precision.
    116
    117 =item B<-soft-float>
    118
    119 Causes B to generate software floating point library calls instead of
    120 equivalent hardware instructions.
    121
    122 =back
    123
    124 =head1 CODE GENERATION OPTIONS
    125
    126 =over
    127
    128 =item B<-code-model>=I
    129
    130 Choose the code model from:
    131
    132 default: Target default code model
    133 small: Small code model
    134 kernel: Kernel code model
    135 medium: Medium code model
    136 large: Large code model
    137
    138 =item B<-disable-post-RA-scheduler>
    139
    140 Disable scheduling after register allocation.
    141
    142 =item B<-disable-spill-fusing>
    143
    144 Disable fusing of spill code into instructions.
    145
    146 =item B<-enable-correct-eh-support>
    147
    148 Make the -lowerinvoke pass insert expensive, but correct, EH code.
    149
    150 =item B<-jit-enable-eh>
    151
    152 Exception handling should be enabled in the just-in-time compiler.
    153
    154 =item B<-join-liveintervals>
    155
    156 Coalesce copies (default=true).
    157
    158 =item B<-nozero-initialized-in-bss>
    159 Don't place zero-initialized symbols into the BSS section.
    160
    161 =item B<-pre-RA-sched>=I
    162
    163 Instruction schedulers available (before register allocation):
    164
    165 =default: Best scheduler for the target
    166 =none: No scheduling: breadth first sequencing
    167 =simple: Simple two pass scheduling: minimize critical path and maximize processor utilization
    168 =simple-noitin: Simple two pass scheduling: Same as simple except using generic latency
    169 =list-burr: Bottom-up register reduction list scheduling
    170 =list-tdrr: Top-down register reduction list scheduling
    171 =list-td: Top-down list scheduler -print-machineinstrs - Print generated machine code
    172
    173 =item B<-regalloc>=I
    174
    175 Register allocator to use (default=linearscan)
    176
    177 =bigblock: Big-block register allocator
    178 =linearscan: linear scan register allocator =local - local register allocator
    179 =simple: simple register allocator
    180
    181 =item B<-relocation-model>=I
    182
    183 Choose relocation model from:
    184
    185 =default: Target default relocation model
    186 =static: Non-relocatable code =pic - Fully relocatable, position independent code
    187 =dynamic-no-pic: Relocatable external references, non-relocatable code
    188
    189 =item B<-spiller>
    190
    191 Spiller to use (default=local)
    192
    193 =simple: simple spiller
    194 =local: local spiller
    195
    196 =item B<-x86-asm-syntax>=I
    197
    198 Choose style of code to emit from X86 backend:
    199
    200 =att: Emit AT&T-style assembly
    201 =intel: Emit Intel-style assembly
    202
    203 =back
    204
    205 =head1 EXIT STATUS
    206
    207 If B fails to load the program, it will exit with an exit code of 1.
    208 Otherwise, it will return the exit code of the program it executes.
    209
    210 =head1 SEE ALSO
    211
    212 L
    213
    214 =head1 AUTHOR
    215
    216 Maintained by the LLVM Team (L).
    217
    218 =cut
    +0
    -406
    docs/CommandGuide/llvm-ar.pod less more
    None =pod
    1
    2 =head1 NAME
    3
    4 llvm-ar - LLVM archiver
    5
    6 =head1 SYNOPSIS
    7
    8 B [-]{dmpqrtx}[Rabfikouz] [relpos] [count] [files...]
    9
    10
    11 =head1 DESCRIPTION
    12
    13 The B command is similar to the common Unix utility, C. It
    14 archives several files together into a single file. The intent for this is
    15 to produce archive libraries by LLVM bitcode that can be linked into an
    16 LLVM program. However, the archive can contain any kind of file. By default,
    17 B generates a symbol table that makes linking faster because
    18 only the symbol table needs to be consulted, not each individual file member
    19 of the archive.
    20
    21 The B command can be used to I both SVR4 and BSD style archive
    22 files. However, it cannot be used to write them. While the B command
    23 produces files that are I identical to the format used by other C
    24 implementations, it has two significant departures in order to make the
    25 archive appropriate for LLVM. The first departure is that B only
    26 uses BSD4.4 style long path names (stored immediately after the header) and
    27 never contains a string table for long names. The second departure is that the
    28 symbol table is formated for efficient construction of an in-memory data
    29 structure that permits rapid (red-black tree) lookups. Consequently, archives
    30 produced with B usually won't be readable or editable with any
    31 C implementation or useful for linking. Using the C modifier to flatten
    32 file names will make the archive readable by other C implementations
    33 but not for linking because the symbol table format for LLVM is unique. If an
    34 SVR4 or BSD style archive is used with the C (replace) or C (quick
    35 update) operations, the archive will be reconstructed in LLVM format. This
    36 means that the string table will be dropped (in deference to BSD 4.4 long names)
    37 and an LLVM symbol table will be added (by default). The system symbol table
    38 will be retained.
    39
    40 Here's where B departs from previous C implementations:
    41
    42 =over
    43
    44 =item I
    45
    46 Since B is intended to archive bitcode files, the symbol table
    47 won't make much sense to anything but LLVM. Consequently, the symbol table's
    48 format has been simplified. It consists simply of a sequence of pairs
    49 of a file member index number as an LSB 4byte integer and a null-terminated
    50 string.
    51
    52 =item I
    53
    54 Some C implementations (SVR4) use a separate file member to record long
    55 path names (> 15 characters). B takes the BSD 4.4 and Mac OS X
    56 approach which is to simply store the full path name immediately preceding
    57 the data for the file. The path name is null terminated and may contain the
    58 slash (/) character.
    59
    60 =item I
    61
    62 B can compress the members of an archive to save space. The
    63 compression used depends on what's available on the platform and what choices
    64 the LLVM Compressor utility makes. It generally favors bzip2 but will select
    65 between "no compression" or bzip2 depending on what makes sense for the
    66 file's content.
    67
    68 =item I
    69
    70 Most C implementations do not recurse through directories but simply
    71 ignore directories if they are presented to the program in the F
    72 option. B, however, can recurse through directory structures and
    73 add all the files under a directory, if requested.
    74
    75 =item I
    76
    77 When B prints out the verbose table of contents (C option), it
    78 precedes the usual output with a character indicating the basic kind of
    79 content in the file. A blank means the file is a regular file. A 'Z' means
    80 the file is compressed. A 'B' means the file is an LLVM bitcode file. An
    81 'S' means the file is the symbol table.
    82
    83 =back
    84
    85 =head1 OPTIONS
    86
    87 The options to B are compatible with other C implementations.
    88 However, there are a few modifiers (F) that are not found in other
    89 Cs. The options to B specify a single basic operation to
    90 perform on the archive, a variety of modifiers for that operation, the
    91 name of the archive file, and an optional list of file names. These options
    92 are used to determine how B should process the archive file.
    93
    94 The Operations and Modifiers are explained in the sections below. The minimal
    95 set of options is at least one operator and the name of the archive. Typically
    96 archive files end with a C<.a> suffix, but this is not required. Following
    97 the F comes a list of F that indicate the specific members
    98 of the archive to operate on. If the F option is not specified, it
    99 generally means either "none" or "all" members, depending on the operation.
    100
    101 =head2 Operations
    102
    103 =over
    104
    105 =item d
    106
    107 Delete files from the archive. No modifiers are applicable to this operation.
    108 The F options specify which members should be removed from the
    109 archive. It is not an error if a specified file does not appear in the archive.
    110 If no F are specified, the archive is not modified.
    111
    112 =item m[abi]
    113
    114 Move files from one location in the archive to another. The F, F, and
    115 F modifiers apply to this operation. The F will all be moved
    116 to the location given by the modifiers. If no modifiers are used, the files
    117 will be moved to the end of the archive. If no F are specified, the
    118 archive is not modified.
    119
    120 =item p[k]
    121
    122 Print files to the standard output. The F modifier applies to this
    123 operation. This operation simply prints the F indicated to the
    124 standard output. If no F are specified, the entire archive is printed.
    125 Printing bitcode files is ill-advised as they might confuse your terminal
    126 settings. The F

    operation never modifies the archive.

    127
    128 =item q[Rfz]
    129
    130 Quickly append files to the end of the archive. The F, F, and F
    131 modifiers apply to this operation. This operation quickly adds the
    132 F to the archive without checking for duplicates that should be
    133 removed first. If no F are specified, the archive is not modified.
    134 Because of the way that B constructs the archive file, its dubious
    135 whether the F operation is any faster than the F operation.
    136
    137 =item r[Rabfuz]
    138
    139 Replace or insert file members. The F, F, F, F, F, and F
    140 modifiers apply to this operation. This operation will replace existing
    141 F or insert them at the end of the archive if they do not exist. If no
    142 F are specified, the archive is not modified.
    143
    144 =item t[v]
    145
    146 Print the table of contents. Without any modifiers, this operation just prints
    147 the names of the members to the standard output. With the F modifier,
    148 B also prints out the file type (B=bitcode, Z=compressed, S=symbol
    149 table, blank=regular file), the permission mode, the owner and group, the
    150 size, and the date. If any F are specified, the listing is only for
    151 those files. If no F are specified, the table of contents for the
    152 whole archive is printed.
    153
    154 =item x[oP]
    155
    156 Extract archive members back to files. The F modifier applies to this
    157 operation. This operation retrieves the indicated F from the archive
    158 and writes them back to the operating system's file system. If no
    159 F are specified, the entire archive is extract.
    160
    161 =back
    162
    163 =head2 Modifiers (operation specific)
    164
    165 The modifiers below are specific to certain operations. See the Operations
    166 section (above) to determine which modifiers are applicable to which operations.
    167
    168 =over
    169
    170 =item [a]
    171
    172 When inserting or moving member files, this option specifies the destination of
    173 the new files as being Cfter the F member. If F is not found,
    174 the files are placed at the end of the archive.
    175
    176 =item [b]
    177
    178 When inserting or moving member files, this option specifies the destination of
    179 the new files as being Cefore the F member. If F is not
    180 found, the files are placed at the end of the archive. This modifier is
    181 identical to the the F modifier.
    182
    183 =item [f]
    184
    185 Normally, B stores the full path name to a file as presented to it on
    186 the command line. With this option, truncated (15 characters max) names are
    187 used. This ensures name compatibility with older versions of C but may also
    188 thwart correct extraction of the files (duplicates may overwrite). If used with
    189 the F option, the directory recursion will be performed but the file names
    190 will all be Clattened to simple file names.
    191
    192 =item [i]
    193
    194 A synonym for the F option.
    195
    196 =item [k]
    197
    198 Normally, B will not print the contents of bitcode files when the
    199 F

    operation is used. This modifier defeats the default and allows the

    200 bitcode members to be printed.
    201
    202 =item [N]
    203
    204 This option is ignored by B but provided for compatibility.
    205
    206 =item [o]
    207
    208 When extracting files, this option will cause B to preserve the
    209 original modification times of the files it writes.
    210
    211 =item [P]
    212
    213 use full path names when matching
    214
    215 =item [R]
    216
    217 This modifier instructions the F option to recursively process directories.
    218 Without F, directories are ignored and only those F that refer to
    219 files will be added to the archive. When F is used, any directories specified
    220 with F will be scanned (recursively) to find files to be added to the
    221 archive. Any file whose name begins with a dot will not be added.
    222
    223 =item [u]
    224
    225 When replacing existing files in the archive, only replace those files that have
    226 a time stamp than the time stamp of the member in the archive.
    227
    228 =item [z]
    229
    230 When inserting or replacing any file in the archive, compress the file first.
    231 This
    232 modifier is safe to use when (previously) compressed bitcode files are added to
    233 the archive; the compressed bitcode files will not be doubly compressed.
    234
    235 =back
    236
    237 =head2 Modifiers (generic)
    238
    239 The modifiers below may be applied to any operation.
    240
    241 =over
    242
    243 =item [c]
    244
    245 For all operations, B will always create the archive if it doesn't
    246 exist. Normally, B will print a warning message indicating that the
    247 archive is being created. Using this modifier turns off that warning.
    248
    249 =item [s]
    250
    251 This modifier requests that an archive index (or symbol table) be added to the
    252 archive. This is the default mode of operation. The symbol table will contain
    253 all the externally visible functions and global variables defined by all the
    254 bitcode files in the archive. Using this modifier is more efficient that using
    255 L which also creates the symbol table.
    256
    257 =item [S]
    258
    259 This modifier is the opposite of the F modifier. It instructs B to
    260 not build the symbol table. If both F and F are used, the last modifier to
    261 occur in the options will prevail.
    262
    263 =item [v]
    264
    265 This modifier instructs B to be verbose about what it is doing. Each
    266 editing operation taken against the archive will produce a line of output saying
    267 what is being done.
    268
    269 =back
    270
    271 =head1 STANDARDS
    272
    273 The B utility is intended to provide a superset of the IEEE Std 1003.2
    274 (POSIX.2) functionality for C. B can read both SVR4 and BSD4.4 (or
    275 Mac OS X) archives. If the C modifier is given to the C or C operations
    276 then B will write SVR4 compatible archives. Without this modifier,
    277 B will write BSD4.4 compatible archives that have long names
    278 immediately after the header and indicated using the "#1/ddd" notation for the
    279 name in the header.
    280
    281 =head1 FILE FORMAT
    282
    283 The file format for LLVM Archive files is similar to that of BSD 4.4 or Mac OSX
    284 archive files. In fact, except for the symbol table, the C commands on those
    285 operating systems should be able to read LLVM archive files. The details of the
    286 file format follow.
    287
    288 Each archive begins with the archive magic number which is the eight printable
    289 characters "!\n" where \n represents the newline character (0x0A).
    290 Following the magic number, the file is composed of even length members that
    291 begin with an archive header and end with a \n padding character if necessary
    292 (to make the length even). Each file member is composed of a header (defined
    293 below), an optional newline-terminated "long file name" and the contents of
    294 the file.
    295
    296 The fields of the header are described in the items below. All fields of the
    297 header contain only ASCII characters, are left justified and are right padded
    298 with space characters.
    299
    300 =over
    301
    302 =item name - char[16]
    303
    304 This field of the header provides the name of the archive member. If the name is
    305 longer than 15 characters or contains a slash (/) character, then this field
    306 contains C<#1/nnn> where C provides the length of the name and the C<#1/>
    307 is literal. In this case, the actual name of the file is provided in the C
    308 bytes immediately following the header. If the name is 15 characters or less, it
    309 is contained directly in this field and terminated with a slash (/) character.
    310
    311 =item date - char[12]
    312
    313 This field provides the date of modification of the file in the form of a
    314 decimal encoded number that provides the number of seconds since the epoch
    315 (since 00:00:00 Jan 1, 1970) per Posix specifications.
    316
    317 =item uid - char[6]
    318
    319 This field provides the user id of the file encoded as a decimal ASCII string.
    320 This field might not make much sense on non-Unix systems. On Unix, it is the
    321 same value as the st_uid field of the stat structure returned by the stat(2)
    322 operating system call.
    323
    324 =item gid - char[6]
    325
    326 This field provides the group id of the file encoded as a decimal ASCII string.
    327 This field might not make much sense on non-Unix systems. On Unix, it is the
    328 same value as the st_gid field of the stat structure returned by the stat(2)
    329 operating system call.
    330
    331 =item mode - char[8]
    332
    333 This field provides the access mode of the file encoded as an octal ASCII
    334 string. This field might not make much sense on non-Unix systems. On Unix, it
    335 is the same value as the st_mode field of the stat structure returned by the
    336 stat(2) operating system call.
    337
    338 =item size - char[10]
    339
    340 This field provides the size of the file, in bytes, encoded as a decimal ASCII
    341 string. If the size field is negative (starts with a minus sign, 0x02D), then
    342 the archive member is stored in compressed form. The first byte of the archive
    343 member's data indicates the compression type used. A value of 0 (0x30) indicates
    344 that no compression was used. A value of 2 (0x32) indicates that bzip2
    345 compression was used.
    346
    347 =item fmag - char[2]
    348
    349 This field is the archive file member magic number. Its content is always the
    350 two characters back tick (0x60) and newline (0x0A). This provides some measure
    351 utility in identifying archive files that have been corrupted.
    352
    353 =back
    354
    355 The LLVM symbol table has the special name "#_LLVM_SYM_TAB_#". It is presumed
    356 that no regular archive member file will want this name. The LLVM symbol table
    357 is simply composed of a sequence of triplets: byte offset, length of symbol,
    358 and the symbol itself. Symbols are not null or newline terminated. Here are
    359 the details on each of these items:
    360
    361 =over
    362
    363 =item offset - vbr encoded 32-bit integer
    364
    365 The offset item provides the offset into the archive file where the bitcode
    366 member is stored that is associated with the symbol. The offset value is 0
    367 based at the start of the first "normal" file member. To derive the actual
    368 file offset of the member, you must add the number of bytes occupied by the file
    369 signature (8 bytes) and the symbol tables. The value of this item is encoded
    370 using variable bit rate encoding to reduce the size of the symbol table.
    371 Variable bit rate encoding uses the high bit (0x80) of each byte to indicate
    372 if there are more bytes to follow. The remaining 7 bits in each byte carry bits
    373 from the value. The final byte does not have the high bit set.
    374
    375 =item length - vbr encoded 32-bit integer
    376
    377 The length item provides the length of the symbol that follows. Like this
    378 I item, the length is variable bit rate encoded.
    379
    380 =item symbol - character array
    381
    382 The symbol item provides the text of the symbol that is associated with the
    383 I. The symbol is not terminated by any character. Its length is provided
    384 by the I field. Note that is allowed (but unwise) to use non-printing
    385 characters (even 0x00) in the symbol. This allows for multiple encodings of
    386 symbol names.
    387
    388 =back
    389
    390 =head1 EXIT STATUS
    391
    392 If B succeeds, it will exit with 0. A usage error, results
    393 in an exit code of 1. A hard (file system typically) error results in an
    394 exit code of 2. Miscellaneous or unknown errors result in an
    395 exit code of 3.
    396
    397 =head1 SEE ALSO
    398
    399 L, ar(1)
    400
    401 =head1 AUTHORS
    402
    403 Maintained by the LLVM Team (L).
    404
    405 =cut
    +0
    -77
    docs/CommandGuide/llvm-as.pod less more
    None =pod
    1
    2 =head1 NAME
    3
    4 llvm-as - LLVM assembler
    5
    6 =head1 SYNOPSIS
    7
    8 B [I] [I]
    9
    10 =head1 DESCRIPTION
    11
    12 B is the LLVM assembler. It reads a file containing human-readable
    13 LLVM assembly language, translates it to LLVM bitcode, and writes the result
    14 into a file or to standard output.
    15
    16 If F is omitted or is C<->, then B reads its input from
    17 standard input.
    18
    19 If an output file is not specified with the B<-o> option, then
    20 B sends its output to a file or standard output by following
    21 these rules:
    22
    23 =over
    24
    25 =item *
    26
    27 If the input is standard input, then the output is standard output.
    28
    29 =item *
    30
    31 If the input is a file that ends with C<.ll>, then the output file is of
    32 the same name, except that the suffix is changed to C<.bc>.
    33
    34 =item *
    35
    36 If the input is a file that does not end with the C<.ll> suffix, then the
    37 output file has the same name as the input file, except that the C<.bc>
    38 suffix is appended.
    39
    40 =back
    41
    42 =head1 OPTIONS
    43
    44 =over
    45
    46 =item B<-f>
    47
    48 Enable binary output on terminals. Normally, B will refuse to
    49 write raw bitcode output if the output stream is a terminal. With this option,
    50 B will write raw bitcode regardless of the output device.
    51
    52 =item B<-help>
    53
    54 Print a summary of command line options.
    55
    56 =item B<-o> F
    57
    58 Specify the output file name. If F is C<->, then B
    59 sends its output to standard output.
    60
    61 =back
    62
    63 =head1 EXIT STATUS
    64
    65 If B succeeds, it will exit with 0. Otherwise, if an error
    66 occurs, it will exit with a non-zero value.
    67
    68 =head1 SEE ALSO
    69
    70 L, L
    71
    72 =head1 AUTHORS
    73
    74 Maintained by the LLVM Team (L).
    75
    76 =cut
    +0
    -315
    docs/CommandGuide/llvm-bcanalyzer.pod less more
    None =pod
    1
    2 =head1 NAME
    3
    4 llvm-bcanalyzer - LLVM bitcode analyzer
    5
    6 =head1 SYNOPSIS
    7
    8 B [I] [F]
    9
    10 =head1 DESCRIPTION
    11
    12 The B command is a small utility for analyzing bitcode files.
    13 The tool reads a bitcode file (such as generated with the B tool) and
    14 produces a statistical report on the contents of the bitcode file. The tool
    15 can also dump a low level but human readable version of the bitcode file.
    16 This tool is probably not of much interest or utility except for those working
    17 directly with the bitcode file format. Most LLVM users can just ignore
    18 this tool.
    19
    20 If F is omitted or is C<->, then B reads its input
    21 from standard input. This is useful for combining the tool into a pipeline.
    22 Output is written to the standard output.
    23
    24 =head1 OPTIONS
    25
    26 =over
    27
    28 =item B<-nodetails>
    29
    30 Causes B to abbreviate its output by writing out only a module
    31 level summary. The details for individual functions are not displayed.
    32
    33 =item B<-dump>
    34
    35 Causes B to dump the bitcode in a human readable format. This
    36 format is significantly different from LLVM assembly and provides details about
    37 the encoding of the bitcode file.
    38
    39 =item B<-verify>
    40
    41 Causes B to verify the module produced by reading the
    42 bitcode. This ensures that the statistics generated are based on a consistent
    43 module.
    44
    45 =item B<-help>
    46
    47 Print a summary of command line options.
    48
    49 =back
    50
    51 =head1 EXIT STATUS
    52
    53 If B succeeds, it will exit with 0. Otherwise, if an error
    54 occurs, it will exit with a non-zero value, usually 1.
    55
    56 =head1 SUMMARY OUTPUT DEFINITIONS
    57
    58 The following items are always printed by llvm-bcanalyzer. They comprize the
    59 summary output.
    60
    61 =over
    62
    63 =item B
    64
    65 This just provides the name of the module for which bitcode analysis is being
    66 generated.
    67
    68 =item B
    69
    70 The bitcode version (not LLVM version) of the file read by the analyzer.
    71
    72 =item B
    73
    74 The size, in bytes, of the entire bitcode file.
    75
    76 =item B
    77
    78 The size, in bytes, of the module block. Percentage is relative to File Size.
    79
    80 =item B
    81
    82 The size, in bytes, of all the function blocks. Percentage is relative to File
    83 Size.
    84
    85 =item B
    86
    87 The size, in bytes, of the Global Types Pool. Percentage is relative to File
    88 Size. This is the size of the definitions of all types in the bitcode file.
    89
    90 =item B
    91
    92 The size, in bytes, of the Constant Pool Blocks Percentage is relative to File
    93 Size.
    94
    95 =item B
    96
    97 Ths size, in bytes, of the Global Variable Definitions and their initializers.
    98 Percentage is relative to File Size.
    99
    100 =item B
    101
    102 The size, in bytes, of all the instruction lists in all the functions.
    103 Percentage is relative to File Size. Note that this value is also included in
    104 the Function Bytes.
    105
    106 =item B
    107
    108 The size, in bytes, of all the compaction tables in all the functions.
    109 Percentage is relative to File Size. Note that this value is also included in
    110 the Function Bytes.
    111
    112 =item B
    113
    114 The size, in bytes, of all the symbol tables in all the functions. Percentage is
    115 relative to File Size. Note that this value is also included in the Function
    116 Bytes.
    117
    118 =item B
    119
    120 The size, in bytes, of the list of dependent libraries in the module. Percentage
    121 is relative to File Size. Note that this value is also included in the Module
    122 Global Bytes.
    123
    124 =item B
    125
    126 The total number of blocks of any kind in the bitcode file.
    127
    128 =item B
    129
    130 The total number of function definitions in the bitcode file.
    131
    132 =item B
    133
    134 The total number of types defined in the Global Types Pool.
    135
    136 =item B
    137
    138 The total number of constants (of any type) defined in the Constant Pool.
    139
    140 =item B
    141
    142 The total number of basic blocks defined in all functions in the bitcode file.
    143
    144 =item B
    145
    146 The total number of instructions defined in all functions in the bitcode file.
    147
    148 =item B
    149
    150 The total number of long instructions defined in all functions in the bitcode
    151 file. Long instructions are those taking greater than 4 bytes. Typically long
    152 instructions are GetElementPtr with several indices, PHI nodes, and calls to
    153 functions with large numbers of arguments.
    154
    155 =item B
    156
    157 The total number of operands used in all instructions in the bitcode file.
    158
    159 =item B
    160
    161 The total number of compaction tables in all functions in the bitcode file.
    162
    163 =item B
    164
    165 The total number of symbol tables in all functions in the bitcode file.
    166
    167 =item B
    168
    169 The total number of dependent libraries found in the bitcode file.
    170
    171 =item B
    172
    173 The total size of the instructions in all functions in the bitcode file.
    174
    175 =item B
    176
    177 The average number of bytes per instruction across all functions in the bitcode
    178 file. This value is computed by dividing Total Instruction Size by Number Of
    179 Instructions.
    180
    181 =item B
    182
    183 The maximum value used for a type's slot number. Larger slot number values take
    184 more bytes to encode.
    185
    186 =item B
    187
    188 The maximum value used for a value's slot number. Larger slot number values take
    189 more bytes to encode.
    190
    191 =item B
    192
    193 The average size of a Value definition (of any type). This is computed by
    194 dividing File Size by the total number of values of any type.
    195
    196 =item B
    197
    198 The average size of a global definition (constants and global variables).
    199
    200 =item B
    201
    202 The average number of bytes per function definition. This is computed by
    203 dividing Function Bytes by Number Of Functions.
    204
    205 =item B<# of VBR 32-bit Integers>
    206
    207 The total number of 32-bit integers encoded using the Variable Bit Rate
    208 encoding scheme.
    209
    210 =item B<# of VBR 64-bit Integers>
    211
    212 The total number of 64-bit integers encoded using the Variable Bit Rate encoding
    213 scheme.
    214
    215 =item B<# of VBR Compressed Bytes>
    216
    217 The total number of bytes consumed by the 32-bit and 64-bit integers that use
    218 the Variable Bit Rate encoding scheme.
    219
    220 =item B<# of VBR Expanded Bytes>
    221
    222 The total number of bytes that would have been consumed by the 32-bit and 64-bit
    223 integers had they not been compressed with the Variable Bit Rage encoding
    224 scheme.
    225
    226 =item B
    227
    228 The total number of bytes saved by using the Variable Bit Rate encoding scheme.
    229 The percentage is relative to # of VBR Expanded Bytes.
    230
    231 =back
    232
    233 =head1 DETAILED OUTPUT DEFINITIONS
    234
    235 The following definitions occur only if the -nodetails option was not given.
    236 The detailed output provides additional information on a per-function basis.
    237
    238 =over
    239
    240 =item B
    241
    242 The type signature of the function.
    243
    244 =item B
    245
    246 The total number of bytes in the function's block.
    247
    248 =item B
    249
    250 The number of basic blocks defined by the function.
    251
    252 =item B
    253
    254 The number of instructions defined by the function.
    255
    256 =item B
    257
    258 The number of instructions using the long instruction format in the function.
    259
    260 =item B
    261
    262 The number of operands used by all instructions in the function.
    263
    264 =item B
    265
    266 The number of bytes consumed by instructions in the function.
    267
    268 =item B
    269
    270 The average number of bytes consumed by the instructions in the function. This
    271 value is computed by dividing Instruction Size by Instructions.
    272
    273 =item B
    274
    275 The average number of bytes used by the function per instruction. This value is
    276 computed by dividing Byte Size by Instructions. Note that this is not the same
    277 as Average Instruction Size. It computes a number relative to the total function
    278 size not just the size of the instruction list.
    279
    280 =item B
    281
    282 The total number of 32-bit integers found in this function (for any use).
    283
    284 =item B
    285
    286 The total number of 64-bit integers found in this function (for any use).
    287
    288 =item B
    289
    290 The total number of bytes in this function consumed by the 32-bit and 64-bit
    291 integers that use the Variable Bit Rate encoding scheme.
    292
    293 =item B
    294
    295 The total number of bytes in this function that would have been consumed by
    296 the 32-bit and 64-bit integers had they not been compressed with the Variable
    297 Bit Rate encoding scheme.
    298
    299 =item B
    300
    301 The total number of bytes saved in this function by using the Variable Bit
    302 Rate encoding scheme. The percentage is relative to # of VBR Expanded Bytes.
    303
    304 =back
    305
    306 =head1 SEE ALSO
    307
    308 L, L
    309
    310 =head1 AUTHORS
    311
    312 Maintained by the LLVM Team (L).
    313
    314 =cut
    +0
    -86
    docs/CommandGuide/llvm-build.pod less more
    None =pod
    1
    2 =head1 NAME
    3
    4 llvm-build - LLVM Project Build Utility
    5
    6 =head1 SYNOPSIS
    7
    8 B [I]
    9
    10 =head1 DESCRIPTION
    11
    12 B is a tool for working with LLVM projects that use the LLVMBuild
    13 system for describing their components.
    14
    15 At heart, B is responsible for loading, verifying, and manipulating
    16 the project's component data. The tool is primarily designed for use in
    17 implementing build systems and tools which need access to the project structure
    18 information.
    19
    20 =head1 OPTIONS
    21
    22 =over
    23
    24 =item B<-h>, B<--help>
    25
    26 Print the builtin program help.
    27
    28 =item B<--source-root>=I
    29
    30 If given, load the project at the given source root path. If this option is not
    31 given, the location of the project sources will be inferred from the location of
    32 the B script itself.
    33
    34 =item B<--print-tree>
    35
    36 Print the component tree for the project.
    37
    38 =item B<--write-library-table>
    39
    40 Write out the C++ fragment which defines the components, library names, and
    41 required libraries. This C++ fragment is built into L
    42 in order to provide clients with the list of required libraries for arbitrary
    43 component combinations.
    44
    45 =item B<--write-llvmbuild>
    46
    47 Write out new I files based on the loaded components. This is
    48 useful for auto-upgrading the schema of the files. B will try to a
    49 limited extent to preserve the comments which were written in the original
    50 source file, although at this time it only preserves block comments that preceed
    51 the section names in the I files.
    52
    53 =item B<--write-cmake-fragment>
    54
    55 Write out the LLVMBuild in the form of a CMake fragment, so it can easily be
    56 consumed by the CMake based build system. The exact contents and format of this
    57 file are closely tied to how LLVMBuild is integrated with CMake, see LLVM's
    58 top-level CMakeLists.txt.
    59
    60 =item B<--write-make-fragment>
    61
    62 Write out the LLVMBuild in the form of a Makefile fragment, so it can easily be
    63 consumed by a Make based build system. The exact contents and format of this
    64 file are closely tied to how LLVMBuild is integrated with the Makefiles, see
    65 LLVM's Makefile.rules.
    66
    67 =item B<--llvmbuild-source-root>=I
    68
    69 If given, expect the I files for the project to be rooted at the
    70 given path, instead of inside the source tree itself. This option is primarily
    71 designed for use in conjunction with B<--write-llvmbuild> to test changes to
    72 I schema.
    73
    74 =back
    75
    76 =head1 EXIT STATUS
    77
    78 B exits with 0 if operation was successful. Otherwise, it will exist
    79 with a non-zero value.
    80
    81 =head1 AUTHOR
    82
    83 Maintained by the LLVM Team (L).
    84
    85 =cut
    +0
    -131
    docs/CommandGuide/llvm-config.pod less more
    None =pod
    1
    2 =head1 NAME
    3
    4 llvm-config - Print LLVM compilation options
    5
    6 =head1 SYNOPSIS
    7
    8 B I
    9
    10 =head1 DESCRIPTION
    11
    12 B makes it easier to build applications that use LLVM. It can
    13 print the compiler flags, linker flags and object libraries needed to link
    14 against LLVM.
    15
    16 =head1 EXAMPLES
    17
    18 To link against the JIT:
    19
    20 g++ `llvm-config --cxxflags` -o HowToUseJIT.o -c HowToUseJIT.cpp
    21 g++ `llvm-config --ldflags` -o HowToUseJIT HowToUseJIT.o \
    22 `llvm-config --libs engine bcreader scalaropts`
    23
    24 =head1 OPTIONS
    25
    26 =over
    27
    28 =item B<--version>
    29
    30 Print the version number of LLVM.
    31
    32 =item B<-help>
    33
    34 Print a summary of B arguments.
    35
    36 =item B<--prefix>
    37
    38 Print the installation prefix for LLVM.
    39
    40 =item B<--src-root>
    41
    42 Print the source root from which LLVM was built.
    43
    44 =item B<--obj-root>
    45
    46 Print the object root used to build LLVM.
    47
    48 =item B<--bindir>
    49
    50 Print the installation directory for LLVM binaries.
    51
    52 =item B<--includedir>
    53
    54 Print the installation directory for LLVM headers.
    55
    56 =item B<--libdir>
    57
    58 Print the installation directory for LLVM libraries.
    59
    60 =item B<--cxxflags>
    61
    62 Print the C++ compiler flags needed to use LLVM headers.
    63
    64 =item B<--ldflags>
    65
    66 Print the flags needed to link against LLVM libraries.
    67
    68 =item B<--libs>
    69
    70 Print all the libraries needed to link against the specified LLVM
    71 I, including any dependencies.
    72
    73 =item B<--libnames>
    74
    75 Similar to B<--libs>, but prints the bare filenames of the libraries
    76 without B<-l> or pathnames. Useful for linking against a not-yet-installed
    77 copy of LLVM.
    78
    79 =item B<--libfiles>
    80
    81 Similar to B<--libs>, but print the full path to each library file. This is
    82 useful when creating makefile dependencies, to ensure that a tool is relinked if
    83 any library it uses changes.
    84
    85 =item B<--components>
    86
    87 Print all valid component names.
    88
    89 =item B<--targets-built>
    90
    91 Print the component names for all targets supported by this copy of LLVM.
    92
    93 =item B<--build-mode>
    94
    95 Print the build mode used when LLVM was built (e.g. Debug or Release)
    96
    97 =back
    98
    99 =head1 COMPONENTS
    100
    101 To print a list of all available components, run B
    102 --components>. In most cases, components correspond directly to LLVM
    103 libraries. Useful "virtual" components include:
    104
    105 =over
    106
    107 =item B
    108
    109 Includes all LLVM libaries. The default if no components are specified.
    110
    111 =item B
    112
    113 Includes either a native backend or the C backend.
    114
    115 =item B
    116
    117 Includes either a native JIT or the bitcode interpreter.
    118
    119 =back
    120
    121 =head1 EXIT STATUS
    122
    123 If B succeeds, it will exit with 0. Otherwise, if an error
    124 occurs, it will exit with a non-zero value.
    125
    126 =head1 AUTHORS
    127
    128 Maintained by the LLVM Team (L).
    129
    130 =cut
    +0
    -45
    docs/CommandGuide/llvm-cov.pod less more
    None =pod
    1
    2 =head1 NAME
    3
    4 llvm-cov - emit coverage information
    5
    6 =head1 SYNOPSIS
    7
    8 B [-gcno=filename] [-gcda=filename] [dump]
    9
    10 =head1 DESCRIPTION
    11
    12 The experimental B tool reads in description file generated by compiler
    13 and coverage data file generated by instrumented program. This program assumes
    14 that the description and data file uses same format as gcov files.
    15
    16 =head1 OPTIONS
    17
    18 =over
    19
    20 =item B<-gcno=filename]
    21
    22 This option selects input description file generated by compiler while instrumenting
    23 program.
    24
    25 =item B<-gcda=filename]
    26
    27 This option selects coverage data file generated by instrumented compiler.
    28
    29 =item B<-dump>
    30
    31 This options enables output dump that is suitable for a developer to help debug
    32 B itself.
    33
    34 =back
    35
    36 =head1 EXIT STATUS
    37
    38 B returns 1 if it cannot read input files. Otherwise, it exits with zero.
    39
    40 =head1 AUTHOR
    41
    42 B is maintained by the LLVM Team (L).
    43
    44 =cut
    +0
    -53
    docs/CommandGuide/llvm-diff.pod less more
    None =pod
    1
    2 =head1 NAME
    3
    4 llvm-diff - LLVM structural 'diff'
    5
    6 =head1 SYNOPSIS
    7
    8 B [I] I I [I]
    9
    10 =head1 DESCRIPTION
    11
    12 B compares the structure of two LLVM modules, primarily
    13 focusing on differences in function definitions. Insignificant
    14 differences, such as changes in the ordering of globals or in the
    15 names of local values, are ignored.
    16
    17 An input module will be interpreted as an assembly file if its name
    18 ends in '.ll'; otherwise it will be read in as a bitcode file.
    19
    20 If a list of global names is given, just the values with those names
    21 are compared; otherwise, all global values are compared, and
    22 diagnostics are produced for globals which only appear in one module
    23 or the other.
    24
    25 B compares two functions by comparing their basic blocks,
    26 beginning with the entry blocks. If the terminators seem to match,
    27 then the corresponding successors are compared; otherwise they are
    28 ignored. This algorithm is very sensitive to changes in control flow,
    29 which tend to stop any downstream changes from being detected.
    30
    31 B is intended as a debugging tool for writers of LLVM
    32 passes and frontends. It does not have a stable output format.
    33
    34 =head1 EXIT STATUS
    35
    36 If B finds no differences between the modules, it will exit
    37 with 0 and produce no output. Otherwise it will exit with a non-zero
    38 value.
    39
    40 =head1 BUGS
    41
    42 Many important differences, like changes in linkage or function
    43 attributes, are not diagnosed.
    44
    45 Changes in memory behavior (for example, coalescing loads) can cause
    46 massive detected differences in blocks.
    47
    48 =head1 AUTHORS
    49
    50 Maintained by the LLVM Team (L).
    51
    52 =cut
    +0
    -60
    docs/CommandGuide/llvm-dis.pod less more
    None =pod
    1
    2 =head1 NAME
    3
    4 llvm-dis - LLVM disassembler
    5
    6 =head1 SYNOPSIS
    7
    8 B [I] [I]
    9
    10 =head1 DESCRIPTION
    11
    12 The B command is the LLVM disassembler. It takes an LLVM
    13 bitcode file and converts it into human-readable LLVM assembly language.
    14
    15 If filename is omitted or specified as C<->, B reads its
    16 input from standard input.
    17
    18 If the input is being read from standard input, then B
    19 will send its output to standard output by default. Otherwise, the
    20 output will be written to a file named after the input file, with
    21 a C<.ll> suffix added (any existing C<.bc> suffix will first be
    22 removed). You can override the choice of output file using the
    23 B<-o> option.
    24
    25 =head1 OPTIONS
    26
    27 =over
    28
    29 =item B<-f>
    30
    31 Enable binary output on terminals. Normally, B will refuse to
    32 write raw bitcode output if the output stream is a terminal. With this option,
    33 B will write raw bitcode regardless of the output device.
    34
    35 =item B<-help>
    36
    37 Print a summary of command line options.
    38
    39 =item B<-o> F
    40
    41 Specify the output file name. If F is -, then the output is sent
    42 to standard output.
    43
    44 =back
    45
    46 =head1 EXIT STATUS
    47
    48 If B succeeds, it will exit with 0. Otherwise, if an error
    49 occurs, it will exit with a non-zero value.
    50
    51 =head1 SEE ALSO
    52
    53 L
    54
    55 =head1 AUTHORS
    56
    57 Maintained by the LLVM Team (L).
    58
    59 =cut
    +0
    -85
    docs/CommandGuide/llvm-extract.pod less more
    None =pod
    1
    2 =head1 NAME
    3
    4 llvm-extract - extract a function from an LLVM module
    5
    6 =head1 SYNOPSIS
    7
    8 B [I] B<--func> I [I]
    9
    10 =head1 DESCRIPTION
    11
    12 The B command takes the name of a function and extracts it from
    13 the specified LLVM bitcode file. It is primarily used as a debugging tool to
    14 reduce test cases from larger programs that are triggering a bug.
    15
    16 In addition to extracting the bitcode of the specified function,
    17 B will also remove unreachable global variables, prototypes, and
    18 unused types.
    19
    20 The B command reads its input from standard input if filename is
    21 omitted or if filename is -. The output is always written to standard output,
    22 unless the B<-o> option is specified (see below).
    23
    24 =head1 OPTIONS
    25
    26 =over
    27
    28 =item B<-f>
    29
    30 Enable binary output on terminals. Normally, B will refuse to
    31 write raw bitcode output if the output stream is a terminal. With this option,
    32 B will write raw bitcode regardless of the output device.
    33
    34 =item B<--func> I
    35
    36 Extract the function named I from the LLVM bitcode. May be
    37 specified multiple times to extract multiple functions at once.
    38
    39 =item B<--rfunc> I
    40
    41 Extract the function(s) matching I from the LLVM bitcode.
    42 All functions matching the regular expression will be extracted. May be
    43 specified multiple times.
    44
    45 =item B<--glob> I
    46
    47 Extract the global variable named I from the LLVM bitcode. May be
    48 specified multiple times to extract multiple global variables at once.
    49
    50 =item B<--rglob> I
    51
    52 Extract the global variable(s) matching I from the LLVM
    53 bitcode. All global variables matching the regular expression will be extracted.
    54 May be specified multiple times.
    55
    56 =item B<-help>
    57
    58 Print a summary of command line options.
    59
    60 =item B<-o> I
    61
    62 Specify the output filename. If filename is "-" (the default), then
    63 B sends its output to standard output.
    64
    65 =item B<-S>
    66
    67 Write output in LLVM intermediate language (instead of bitcode).
    68
    69 =back
    70
    71 =head1 EXIT STATUS
    72
    73 If B succeeds, it will exit with 0. Otherwise, if an error
    74 occurs, it will exit with a non-zero value.
    75
    76 =head1 SEE ALSO
    77
    78 L
    79
    80 =head1 AUTHORS
    81
    82 Maintained by the LLVM Team (L).
    83
    84 =cut
    +0
    -79
    docs/CommandGuide/llvm-link.pod less more
    None =pod
    1
    2 =head1 NAME
    3
    4 llvm-link - LLVM linker
    5
    6 =head1 SYNOPSIS
    7
    8 B [I] I
    9
    10 =head1 DESCRIPTION
    11
    12 B takes several LLVM bitcode files and links them together into a
    13 single LLVM bitcode file. It writes the output file to standard output, unless
    14 the B<-o> option is used to specify a filename.
    15
    16 B attempts to load the input files from the current directory. If
    17 that fails, it looks for each file in each of the directories specified by the
    18 B<-L> options on the command line. The library search paths are global; each
    19 one is searched for every input file if necessary. The directories are searched
    20 in the order they were specified on the command line.
    21
    22 =head1 OPTIONS
    23
    24 =over
    25
    26 =item B<-L> F
    27
    28 Add the specified F to the library search path. When looking for
    29 libraries, B will look in path name for libraries. This option can be
    30 specified multiple times; B will search inside these directories in
    31 the order in which they were specified on the command line.
    32
    33 =item B<-f>
    34
    35 Enable binary output on terminals. Normally, B will refuse to
    36 write raw bitcode output if the output stream is a terminal. With this option,
    37 B will write raw bitcode regardless of the output device.
    38
    39 =item B<-o> F
    40
    41 Specify the output file name. If F is C<->, then B will
    42 write its output to standard output.
    43
    44 =item B<-S>
    45
    46 Write output in LLVM intermediate language (instead of bitcode).
    47
    48 =item B<-d>
    49
    50 If specified, B prints a human-readable version of the output
    51 bitcode file to standard error.
    52
    53 =item B<-help>
    54
    55 Print a summary of command line options.
    56
    57 =item B<-v>
    58
    59 Verbose mode. Print information about what B is doing. This
    60 typically includes a message for each bitcode file linked in and for each
    61 library found.
    62
    63 =back
    64
    65 =head1 EXIT STATUS
    66
    67 If B succeeds, it will exit with 0. Otherwise, if an error
    68 occurs, it will exit with a non-zero value.
    69
    70 =head1 SEE ALSO
    71
    72 L
    73
    74 =head1 AUTHORS
    75
    76 Maintained by the LLVM Team (L).
    77
    78 =cut
    +0
    -122
    docs/CommandGuide/llvm-nm.pod less more
    None =pod
    1
    2 =head1 NAME
    3
    4 llvm-nm - list LLVM bitcode file's symbol table
    5
    6 =head1 SYNOPSIS
    7
    8 B [I] [I]
    9
    10 =head1 DESCRIPTION
    11
    12 The B utility lists the names of symbols from the LLVM bitcode files,
    13 or B archives containing LLVM bitcode files, named on the command line.
    14 Each symbol is listed along with some simple information about its provenance.
    15 If no file name is specified, or I<-> is used as a file name, B will
    16 process a bitcode file on its standard input stream.
    17
    18 B's default output format is the traditional BSD B output format.
    19 Each such output record consists of an (optional) 8-digit hexadecimal address,
    20 followed by a type code character, followed by a name, for each symbol. One
    21 record is printed per line; fields are separated by spaces. When the address is
    22 omitted, it is replaced by 8 spaces.
    23
    24 Type code characters currently supported, and their meanings, are as follows:
    25
    26 =over
    27
    28 =item U
    29
    30 Named object is referenced but undefined in this bitcode file
    31
    32 =item C
    33
    34 Common (multiple definitions link together into one def)
    35
    36 =item W
    37
    38 Weak reference (multiple definitions link together into zero or one definitions)
    39
    40 =item t
    41
    42 Local function (text) object
    43
    44 =item T
    45
    46 Global function (text) object
    47
    48 =item d
    49
    50 Local data object
    51
    52 =item D
    53
    54 Global data object
    55
    56 =item ?
    57
    58 Something unrecognizable
    59
    60 =back
    61
    62 Because LLVM bitcode files typically contain objects that are not considered to
    63 have addresses until they are linked into an executable image or dynamically
    64 compiled "just-in-time", B does not print an address for any symbol,
    65 even symbols which are defined in the bitcode file.
    66
    67 =head1 OPTIONS
    68
    69 =over
    70
    71 =item B<-P>
    72
    73 Use POSIX.2 output format. Alias for B<--format=posix>.
    74
    75 =item B<-B> (default)
    76
    77 Use BSD output format. Alias for B<--format=bsd>.
    78
    79 =item B<-help>
    80
    81 Print a summary of command-line options and their meanings.
    82
    83 =item B<--defined-only>
    84
    85 Print only symbols defined in this bitcode file (as opposed to
    86 symbols which may be referenced by objects in this file, but not
    87 defined in this file.)
    88
    89 =item B<--extern-only>, B<-g>
    90
    91 Print only symbols whose definitions are external; that is, accessible
    92 from other bitcode files.
    93
    94 =item B<--undefined-only>, B<-u>
    95
    96 Print only symbols referenced but not defined in this bitcode file.
    97
    98 =item B<--format=>I, B<-f>
    99
    100 Select an output format; I may be I, I, or I. The
    101 default is I.
    102
    103 =back
    104
    105 =head1 BUGS
    106
    107 B cannot demangle C++ mangled names, like GNU B can.
    108
    109 =head1 EXIT STATUS
    110
    111 B exits with an exit code of zero.
    112
    113 =head1 SEE ALSO
    114
    115 L, ar(1), nm(1)
    116
    117 =head1 AUTHOR
    118
    119 Maintained by the LLVM Team (L).
    120
    121 =cut
    +0
    -57
    docs/CommandGuide/llvm-prof.pod less more
    None =pod
    1
    2 =head1 NAME
    3
    4 llvm-prof - print execution profile of LLVM program
    5
    6 =head1 SYNOPSIS
    7
    8 B [I] [I] [I]
    9
    10 =head1 DESCRIPTION
    11
    12 The B tool reads in an F file (which can
    13 optionally use a specific file with the third program argument), a bitcode file
    14 for the program, and produces a human readable report, suitable for determining
    15 where the program hotspots are.
    16
    17 This program is often used in conjunction with the F
    18 script. This script automatically instruments a program, runs it with the JIT,
    19 then runs B to format a report. To get more information about
    20 F, execute it with the B<-help> option.
    21
    22 =head1 OPTIONS
    23
    24 =over
    25
    26 =item B<--annotated-llvm> or B<-A>
    27
    28 In addition to the normal report printed, print out the code for the
    29 program, annotated with execution frequency information. This can be
    30 particularly useful when trying to visualize how frequently basic blocks
    31 are executed. This is most useful with basic block profiling
    32 information or better.
    33
    34 =item B<--print-all-code>
    35
    36 Using this option enables the B<--annotated-llvm> option, but it
    37 prints the entire module, instead of just the most commonly executed
    38 functions.
    39
    40 =item B<--time-passes>
    41
    42 Record the amount of time needed for each pass and print it to standard
    43 error.
    44
    45 =back
    46
    47 =head1 EXIT STATUS
    48
    49 B returns 1 if it cannot load the bitcode file or the profile
    50 information. Otherwise, it exits with zero.
    51
    52 =head1 AUTHOR
    53
    54 B is maintained by the LLVM Team (L).
    55
    56 =cut
    +0
    -52
    docs/CommandGuide/llvm-ranlib.pod less more
    None =pod
    1
    2 =head1 NAME
    3
    4 llvm-ranlib - Generate index for LLVM archive
    5
    6 =head1 SYNOPSIS
    7
    8 B [--version] [-help]
    9
    10 =head1 DESCRIPTION
    11
    12 The B command is similar to the common Unix utility, C. It
    13 adds or updates the symbol table in an LLVM archive file. Note that using the
    14 B modifier F is usually more efficient than running B
    15 which is only provided only for completness and compatibility. Unlike other
    16 implementations of C, B indexes LLVM bitcode files, not
    17 native object modules. You can list the contents of the symbol table with the
    18 C command.
    19
    20 =head1 OPTIONS
    21
    22 =over
    23
    24 =item F
    25
    26 Specifies the archive-file to which the symbol table is added or updated.
    27
    28 =item F<--version>
    29
    30 Print the version of B and exit without building a symbol table.
    31
    32 =item F<-help>
    33
    34 Print usage help for B and exit without building a symbol table.
    35
    36 =back
    37
    38 =head1 EXIT STATUS
    39
    40 If B succeeds, it will exit with 0. If an error occurs, a non-zero
    41 exit code will be returned.
    42
    43 =head1 SEE ALSO
    44
    45 L, ranlib(1)
    46
    47 =head1 AUTHORS
    48
    49 Maintained by the LLVM Team (L).
    50
    51 =cut
    +0
    -42
    docs/CommandGuide/llvm-stress.pod less more
    None =pod
    1
    2 =head1 NAME
    3
    4 llvm-stress - generate random .ll files
    5
    6 =head1 SYNOPSIS
    7
    8 B [-gcno=filename] [-gcda=filename] [dump]
    9
    10 =head1 DESCRIPTION
    11
    12 The B tool is used to generate random .ll files that can be used to
    13 test different components of LLVM.
    14
    15 =head1 OPTIONS
    16
    17 =over
    18
    19 =item B<-o> I
    20
    21 Specify the output filename.
    22
    23 =item B<-size> I
    24
    25 Specify the size of the generated .ll file.
    26
    27 =item B<-seed> I
    28
    29 Specify the seed to be used for the randomly generated instructions.
    30
    31 =back
    32
    33 =head1 EXIT STATUS
    34
    35 B returns 0.
    36
    37 =head1 AUTHOR
    38
    39 B is maintained by the LLVM Team (L).
    40
    41 =cut
    +0
    -256
    docs/CommandGuide/manpage.css less more
    None /* Based on http://www.perldoc.com/css/perldoc.css */
    1
    2 @import url("../llvm.css");
    3
    4 body { font-family: Arial,Helvetica; }
    5
    6 blockquote { margin: 10pt; }
    7
    8 h1, a { color: #336699; }
    9
    10
    11 /*** Top menu style ****/
    12 .mmenuon {
    13 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
    14 color: #ff6600; font-size: 10pt;
    15 }
    16 .mmenuoff {
    17 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
    18 color: #ffffff; font-size: 10pt;
    19 }
    20 .cpyright {
    21 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
    22 color: #ffffff; font-size: xx-small;
    23 }
    24 .cpyrightText {
    25 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
    26 color: #ffffff; font-size: xx-small;
    27 }
    28 .sections {
    29 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
    30 color: #336699; font-size: 11pt;
    31 }
    32 .dsections {
    33 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
    34 color: #336699; font-size: 12pt;
    35 }
    36 .slink {
    37 font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
    38 color: #000000; font-size: 9pt;
    39 }
    40
    41 .slink2 { font-family: Arial,Helvetica; text-decoration: none; color: #336699; }
    42
    43 .maintitle {
    44 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
    45 color: #336699; font-size: 18pt;
    46 }
    47 .dblArrow {
    48 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
    49 color: #336699; font-size: small;
    50 }
    51 .menuSec {
    52 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
    53 color: #336699; font-size: small;
    54 }
    55
    56 .newstext {
    57 font-family: Arial,Helvetica; font-size: small;
    58 }
    59
    60 .linkmenu {
    61 font-family: Arial,Helvetica; color: #000000; font-weight: bold;
    62 text-decoration: none;
    63 }
    64
    65 P {
    66 font-family: Arial,Helvetica;
    67 }
    68
    69 PRE {
    70 font-size: 10pt;
    71 }
    72 .quote {
    73 font-family: Times; text-decoration: none;
    74 color: #000000; font-size: 9pt; font-style: italic;
    75 }
    76 .smstd { font-family: Arial,Helvetica; color: #000000; font-size: x-small; }
    77 .std { font-family: Arial,Helvetica; color: #000000; }
    78 .meerkatTitle {
    79 font-family: sans-serif; font-size: x-small; color: black; }
    80
    81 .meerkatDescription { font-family: sans-serif; font-size: 10pt; color: black }
    82 .meerkatCategory {
    83 font-family: sans-serif; font-size: 9pt; font-weight: bold; font-style: italic;
    84 color: brown; }
    85 .meerkatChannel {
    86 font-family: sans-serif; font-size: 9pt; font-style: italic; color: brown; }
    87 .meerkatDate { font-family: sans-serif; font-size: xx-small; color: #336699; }
    88
    89 .tocTitle {
    90 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
    91 color: #333333; font-size: 10pt;
    92 }
    93
    94 .toc-item {
    95 font-family: Arial,Helvetica; font-weight: bold;
    96 color: #336699; font-size: 10pt; text-decoration: underline;
    97 }
    98
    99 .perlVersion {
    100 font-family: Arial,Helvetica; font-weight: bold;
    101 color: #336699; font-size: 10pt; text-decoration: none;
    102 }
    103
    104 .podTitle {
    105 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
    106 color: #000000;
    107 }
    108
    109 .docTitle {
    110 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
    111 color: #000000; font-size: 10pt;
    112 }
    113 .dotDot {
    114 font-family: Arial,Helvetica; font-weight: bold;
    115 color: #000000; font-size: 9pt;
    116 }
    117
    118 .docSec {
    119 font-family: Arial,Helvetica; font-weight: normal;
    120 color: #333333; font-size: 9pt;
    121 }
    122 .docVersion {
    123 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
    124 color: #336699; font-size: 10pt;
    125 }
    126
    127 .docSecs-on {
    128 font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
    129 color: #ff0000; font-size: 10pt;
    130 }
    131 .docSecs-off {
    132 font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
    133 color: #333333; font-size: 10pt;
    134 }
    135
    136 h2 {
    137 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
    138 color: #336699; font-size: medium;
    139 }
    140 h1 {
    141 font-family: Verdana,Arial,Helvetica; font-weight: bold; text-decoration: none;
    142 color: #336699; font-size: large;
    143 }
    144
    145 DL {
    146 font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
    147 color: #333333; font-size: 10pt;
    148 }
    149
    150 UL > LI > A {
    151 font-family: Arial,Helvetica; font-weight: bold;
    152 color: #336699; font-size: 10pt;
    153 }
    154
    155 .moduleInfo {
    156 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
    157 color: #333333; font-size: 11pt;
    158 }
    159
    160 .moduleInfoSec {
    161 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
    162 color: #336699; font-size: 10pt;
    163 }
    164
    165 .moduleInfoVal {
    166 font-family: Arial,Helvetica; font-weight: normal; text-decoration: underline;
    167 color: #000000; font-size: 10pt;
    168 }
    169
    170 .cpanNavTitle {
    171 font-family: Arial,Helvetica; font-weight: bold;
    172 color: #ffffff; font-size: 10pt;
    173 }
    174 .cpanNavLetter {
    175 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
    176 color: #333333; font-size: 9pt;
    177 }
    178 .cpanCat {
    179 font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
    180 color: #336699; font-size: 9pt;
    181 }
    182
    183 .bttndrkblue-bkgd-top {
    184 background-color: #225688;
    185 background-image: url(/global/mvc_objects/images/bttndrkblue_bgtop.gif);
    186 }
    187 .bttndrkblue-bkgd-left {
    188 background-color: #225688;
    189 background-image: url(/global/mvc_objects/images/bttndrkblue_bgleft.gif);
    190 }
    191 .bttndrkblue-bkgd {
    192 padding-top: 0px;
    193 padding-bottom: 0px;
    194 margin-bottom: 0px;
    195 margin-top: 0px;
    196 background-repeat: no-repeat;
    197 background-color: #225688;
    198 background-image: url(/global/mvc_objects/images/bttndrkblue_bgmiddle.gif);
    199 vertical-align: top;
    200 }
    201 .bttndrkblue-bkgd-right {
    202 background-color: #225688;
    203 background-image: url(/global/mvc_objects/images/bttndrkblue_bgright.gif);
    204 }
    205 .bttndrkblue-bkgd-bottom {
    206 background-color: #225688;
    207 background-image: url(/global/mvc_objects/images/bttndrkblue_bgbottom.gif);
    208 }
    209 .bttndrkblue-text a {
    210 color: #ffffff;
    211 text-decoration: none;
    212 }
    213 a.bttndrkblue-text:hover {
    214 color: #ffDD3C;
    215 text-decoration: none;
    216 }
    217 .bg-ltblue {
    218 background-color: #f0f5fa;
    219 }
    220
    221 .border-left-b {
    222 background: #f0f5fa url(/i/corner-leftline.gif) repeat-y;
    223 }
    224
    225 .border-right-b {
    226 background: #f0f5fa url(/i/corner-rightline.gif) repeat-y;
    227 }
    228
    229 .border-top-b {
    230 background: #f0f5fa url(/i/corner-topline.gif) repeat-x;
    231 }
    232
    233 .border-bottom-b {
    234 background: #f0f5fa url(/i/corner-botline.gif) repeat-x;
    235 }
    236
    237 .border-right-w {
    238 background: #ffffff url(/i/corner-rightline.gif) repeat-y;
    239 }
    240
    241 .border-top-w {
    242 background: #ffffff url(/i/corner-topline.gif) repeat-x;
    243 }
    244
    245 .border-bottom-w {
    246 background: #ffffff url(/i/corner-botline.gif) repeat-x;
    247 }
    248
    249 .bg-white {
    250 background-color: #ffffff;
    251 }
    252
    253 .border-left-w {
    254 background: #ffffff url(/i/corner-leftline.gif) repeat-y;
    255 }
    +0
    -143
    docs/CommandGuide/opt.pod less more
    None =pod
    1
    2 =head1 NAME
    3
    4 opt - LLVM optimizer
    5
    6 =head1 SYNOPSIS
    7
    8 B [I] [I]
    9
    10 =head1 DESCRIPTION
    11
    12 The B command is the modular LLVM optimizer and analyzer. It takes LLVM
    13 source files as input, runs the specified optimizations or analyses on it, and then
    14 outputs the optimized file or the analysis results. The function of
    15 B depends on whether the B<-analyze> option is given.
    16
    17 When B<-analyze> is specified, B performs various analyses of the input
    18 source. It will usually print the results on standard output, but in a few
    19 cases, it will print output to standard error or generate a file with the
    20 analysis output, which is usually done when the output is meant for another
    21 program.
    22
    23 While B<-analyze> is I given, B attempts to produce an optimized
    24 output file. The optimizations available via B depend upon what
    25 libraries were linked into it as well as any additional libraries that have
    26 been loaded with the B<-load> option. Use the B<-help> option to determine
    27 what optimizations you can use.
    28
    29 If I is omitted from the command line or is I<->, B reads its
    30 input from standard input. Inputs can be in either the LLVM assembly language
    31 format (.ll) or the LLVM bitcode format (.bc).
    32
    33 If an output filename is not specified with the B<-o> option, B
    34 writes its output to the standard output.
    35
    36 =head1 OPTIONS
    37
    38 =over
    39
    40 =item B<-f>
    41
    42 Enable binary output on terminals. Normally, B will refuse to
    43 write raw bitcode output if the output stream is a terminal. With this option,
    44 B will write raw bitcode regardless of the output device.
    45
    46 =item B<-help>
    47
    48 Print a summary of command line options.
    49
    50 =item B<-o> I
    51
    52 Specify the output filename.
    53
    54 =item B<-S>
    55
    56 Write output in LLVM intermediate language (instead of bitcode).
    57
    58 =item B<-{passname}>
    59
    60 B provides the ability to run any of LLVM's optimization or analysis passes
    61 in any order. The B<-help> option lists all the passes available. The order in
    62 which the options occur on the command line are the order in which they are
    63 executed (within pass constraints).
    64
    65 =item B<-std-compile-opts>
    66
    67 This is short hand for a standard list of I passes.
    68 This is typically used to optimize the output from the llvm-gcc front end. It
    69 might be useful for other front end compilers as well. To discover the full set
    70 of options available, use the following command:
    71
    72 llvm-as < /dev/null | opt -std-compile-opts -disable-output -debug-pass=Arguments
    73
    74 =item B<-disable-inlining>
    75
    76 This option is only meaningful when B<-std-compile-opts> is given. It simply
    77 removes the inlining pass from the standard list.
    78
    79 =item B<-disable-opt>
    80
    81 This option is only meaningful when B<-std-compile-opts> is given. It disables
    82 most, but not all, of the B<-std-compile-opts>. The ones that remain are
    83 B<-verify>, B<-lower-setjmp>, and B<-funcresolve>.
    84
    85 =item B<-strip-debug>
    86
    87 This option causes opt to strip debug information from the module before
    88 applying other optimizations. It is essentially the same as B<-strip> but it
    89 ensures that stripping of debug information is done first.
    90
    91 =item B<-verify-each>
    92
    93 This option causes opt to add a verify pass after every pass otherwise specified
    94 on the command line (including B<-verify>). This is useful for cases where it
    95 is suspected that a pass is creating an invalid module but it is not clear which
    96 pass is doing it. The combination of B<-std-compile-opts> and B<-verify-each>
    97 can quickly track down this kind of problem.
    98
    99 =item B<-profile-info-file> I
    100
    101 Specify the name of the file loaded by the -profile-loader option.
    102
    103 =item B<-stats>
    104
    105 Print statistics.
    106
    107 =item B<-time-passes>
    108
    109 Record the amount of time needed for each pass and print it to standard
    110 error.
    111
    112 =item B<-debug>
    113
    114 If this is a debug build, this option will enable debug printouts
    115 from passes which use the I macro. See the B
    116 Manual>, section I<#DEBUG> for more information.
    117
    118 =item B<-load>=I
    119
    120 Load the dynamic object I. This object should register new optimization
    121 or analysis passes. Once loaded, the object will add new command line options to