a content-specific id number (for example, LLVM IR uses an ID of 12 to represent
function bodies). Block IDs 0-7 are reserved for <a href="#stdblocks">standard blocks</a>
whose meaning is defined by Bitcode; block IDs 8 and greater are
-application specific. Nested blocks capture the hierachical structure of the data
+application specific. Nested blocks capture the hierarchical structure of the data
encoded in it, and various properties are associated with blocks as the file is
parsed. Block definitions allow the reader to efficiently skip blocks
in constant time if the reader wants a summary of blocks, or if it wants to
<div class="doc_text">
<p>In all cases, prefer spaces to tabs in source files. People have different
-prefered indentation levels, and different styles of indentation that they
+preferred indentation levels, and different styles of indentation that they
like... this is fine. What isn't is that different editors/viewers expand tabs
out to different tab stops. This can cause your code to look completely
unreadable, and it is not worth dealing with.</p>
<b>must</b> include all of the header files that you are using -- you can
include them either directly
or indirectly (through another header file). To make sure that you don't
-accidently forget to include a header file in your module header, make sure to
+accidentally forget to include a header file in your module header, make sure to
include your module header <b>first</b> in the implementation file (as mentioned
above). This way there won't be any hidden dependencies that you'll find out
about later...</p>
<div class="doc_text">
<p>Use the "<tt>assert</tt>" function to its fullest. Check all of your
-preconditions and assumptions, you never know when a bug (not neccesarily even
+preconditions and assumptions, you never know when a bug (not necessarily even
yours) might be caught early by an assertion, which reduces debugging time
dramatically. The "<tt><cassert></tt>" header file is probably already
included by the header files you are using, so it doesn't cost anything to use
code from the storage of the value parsed. For example, lets say that we have a
'<tt>-debug</tt>' option that we would like to use to enable debug information
across the entire body of our program. In this case, the boolean value
-controlling the debug code should be globally accessable (in a header file, for
+controlling the debug code should be globally accessible (in a header file, for
example) yet the command line option processing code should not be exposed to
all of these clients (requiring lots of .cpp files to #include
<tt>CommandLine.h</tt>).</p>
example.</li>
<li><a name="cl::init">The <b><tt>cl::init</tt></b></a> attribute specifies an
-inital value for a <a href="#cl::opt">scalar</a> option. If this attribute is
+init
ial value for a <a href="#cl::opt">scalar</a> option. If this attribute is
not specified then the command line option value defaults to the value created
by the default constructor for the type. <b>Warning</b>: If you specify both
<b><tt>cl::init</tt></b> and <b><tt>cl::location</tt></b> for an option,
tweak how options are parsed and how <tt>--help</tt> output is generated to fit
your application well.</p>
-<p>These options fall into five main catagories:</p>
+<p>These options fall into five main categories:</p>
<ol>
<li><a href="#hiding">Hiding an option from <tt>--help</tt> output</a></li>
<li><a href="#misc">Miscellaneous option modifiers</a></li>
</ol>
-<p>It is not possible to specify two options from the same catagory (you'll get
+<p>It is not possible to specify two options from the same category (you'll get
a runtime error) to a single option, except for options in the miscellaneous
-catagory. The CommandLine library specifies defaults for all of these settings
+category. The CommandLine library specifies defaults for all of these settings
that are the most useful in practice and the most common, which mean that you
usually shouldn't have to worry about these.</p>
environment variable to examine, the optional
<a href="#description">additional extra text</a> to emit when the
<tt>--help</tt> option is invoked, and the boolean
-switch that controls whether <a href="#response">reponse files</a>
+switch that controls whether <a href="#response">response files</a>
should be read.</p>
<p><tt>cl::ParseEnvironmentOptions</tt> will break the environment
<tt class="docutils literal"><span class="pre">-std=c99</span></tt>. It is also allowed to use spaces instead of the equality
sign: <tt class="docutils literal"><span class="pre">-std</span> <span class="pre">c99</span></tt>. At most one occurrence is allowed.</li>
<li><tt class="docutils literal"><span class="pre">parameter_list_option</span></tt> - same as the above, but more than one option
-occurence is allowed.</li>
+occurrence is allowed.</li>
<li><tt class="docutils literal"><span class="pre">prefix_option</span></tt> - same as the parameter_option, but the option name and
argument do not have to be separated. Example: <tt class="docutils literal"><span class="pre">-ofile</span></tt>. This can be also
specified as <tt class="docutils literal"><span class="pre">-o</span> <span class="pre">file</span></tt>; however, <tt class="docutils literal"><span class="pre">-o=file</span></tt> will be parsed incorrectly
(<tt class="docutils literal"><span class="pre">=file</span></tt> will be interpreted as option value). At most one occurrence is
allowed.</li>
-<li><tt class="docutils literal"><span class="pre">prefix_list_option</span></tt> - same as the above, but more than one occurence of
+<li><tt class="docutils literal"><span class="pre">prefix_list_option</span></tt> - same as the above, but more than one occurrence of
the option is allowed; example: <tt class="docutils literal"><span class="pre">-lm</span> <span class="pre">-lpthread</span></tt>.</li>
<li><tt class="docutils literal"><span class="pre">alias_option</span></tt> - a special option type for creating aliases. Unlike other
option types, aliases are not allowed to have any properties besides the
<a href="mailto:foldr@codedgers.com">Mikhail Glushenkov</a><br />
<a href="http://llvm.org">LLVM Compiler Infrastructure</a><br />
-Last modified: $Date: 2008-12-11 11:34:48 -0600 (Thu, 11 Dec 2008) $
+Last modified: $Date$
</address></div>
</div>
</div>
<p>Also, there are a number of other limitations of the C backend that cause it
to produce code that does not fully conform to the C++ ABI on most
platforms. Some of the C++ programs in LLVM's test suite are known to fail
- when compiled with the C back end because of ABI incompatiblities with
+ when compiled with the C back end because of ABI incompatibilities with
standard C++ libraries.</p>
</div>
portable is by using the preprocessor to include platform-specific code. In
practice, information about other platforms is lost after preprocessing, so
the result is inherently dependent on the platform that the preprocessing was
- targetting.</p>
+ targeting.</p>
<p>Another example is <tt>sizeof</tt>. It's common for <tt>sizeof(long)</tt> to
vary between platforms. In most C front-ends, <tt>sizeof</tt> is expanded to
<div class="doc_text">
<p>This document seeks to dispel the mystery and confusion surrounding LLVM's
GetElementPtr (GEP) instruction. Questions about the wiley GEP instruction are
- probably the most frequently occuring questions once a developer gets down to
+ probably the most frequently occurring questions once a developer gets down to
coding with LLVM. Here we lay out the sources of confusion and show that the
GEP instruction is really quite simple.
</p>
<div class="doc_text">
<p>LLVM is released on a time based schedule (currently every 6 months). We
do not have dot releases because of the nature of LLVM incremental
- developement philosophy. The release schedule is roughly as follows:
+ development philosophy. The release schedule is roughly as follows:
</p>
<ol>
<li>Set code freeze and branch creation date for 6 months after last code freeze
release documentation.</li>
<li> Finally, update the main page (<tt>index.html</tt> and sidebar) to
point to the new release and release announcement. Make sure this all gets
- commited back into Subversion.</li>
+ committed back into Subversion.</li>
</ol>
</div>
<p>Once you have a reduced test-case, go to <a
href="http://llvm.org/bugs/enter_bug.cgi">the LLVM Bug Tracking
System</a> and fill out the form with the necessary details (note that you don't
-need to pick a catagory, just use the "new-bugs" catagory if you're not sure).
+need to pick a category, just use the "new-bugs" category if you're not sure).
The bug description should contain the following
information:</p>
<div class="doc_text">
<p>The string '<tt>undef</tt>' can be used anywhere a constant is expected, and
- indicates that the user of the value may recieve an unspecified bit-pattern.
+ indicates that the user of the value may receive an unspecified bit-pattern.
Undefined values may be of any type (other than label or void) and be used
anywhere a constant is permitted.</p>
arbitrarily change its value over its "live range". This is true because the
"variable" doesn't actually <em>have a live range</em>. Instead, the value is
logically read from arbitrary registers that happen to be around when needed,
-so the value is not neccesarily consistent over time. In fact, %A and %C need
+so the value is not necessarily consistent over time. In fact, %A and %C need
to have the same semantics or the core LLVM "replace all uses with" concept
would not hold.</p>
the two digit hex code. For example: "<tt>!"test\00"</tt>".</p>
<p>Metadata nodes are represented with notation similar to structure constants
- (a comma separated list of elements, surrounded by braces and preceeded by an
+ (a comma separated list of elements, surrounded by braces and preceded by an
exclamation point). For example: "<tt>!{ metadata !"test\00", i32
10}</tt>".</p>
<p>The <tt>switch</tt> instruction specifies a table of values and
destinations. When the '<tt>switch</tt>' instruction is executed, this table
is searched for the given value. If the value is found, control flow is
- transfered to the corresponding destination; otherwise, control flow is
- transfered to the default destination.</p>
+ transferred to the corresponding destination; otherwise, control flow is
+ transferred to the default destination.</p>
<h5>Implementation:</h5>
<p>Depending on properties of the target machine and the particular
provided by the linker on various platform are not unique. This means,
this new tool needs to support all such features and platforms in one
super tool or a separate tool per platform is required. This increases
- maintance cost for link time optimizer significantly, which is not
+ maintenance cost for link time optimizer significantly, which is not
necessary. This approach also requires staying synchronized with linker
developements on various platforms, which is not the main focus of the link
time optimizer. Finally, this approach increases end user's build time due
user-supplied information, such as a list of exported symbols. LLVM
optimizer collects control flow information, data flow information and knows
much more about program structure from the optimizer's point of view.
- Our goal is to take advantage of tight intergration between the linker and
+ Our goal is to take advantage of tight integration between the linker and
the optimizer by sharing this information during various linking phases.
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsubsection"><a name="BCModules">Bitcode Modules</a></div>
<div class="doc_text">
- <p>In some situations, it is desireable to build a single bitcode module from
+ <p>In some situations, it is desirable to build a single bitcode module from
a variety of sources, instead of an archive, shared library, or bitcode
library. Bitcode modules can be specified in addition to any of the other
types of libraries by defining the <a href="#MODULE_NAME">MODULE_NAME</a>
<p>
This file demotes all registers to memory references. It is intented to be
the inverse of <a href="#mem2reg"><tt>-mem2reg</tt></a>. By converting to
- <tt>load</tt> instructions, the only values live accross basic blocks are
+ <tt>load</tt> instructions, the only values live across basic blocks are
<tt>alloca</tt> instructions and <tt>load</tt> instructions before
<tt>phi</tt> nodes. It is intended that this should make CFG hacking much
easier. To make later hacking easier, the entry block is split into two, such
<p>The <tt>DEBUG_WITH_TYPE</tt> macro is also available for situations where you
would like to set <tt>DEBUG_TYPE</tt>, but only for one specific <tt>DEBUG</tt>
statement. It takes an additional first parameter, which is the type to use. For
-example, the preceeding example could be written as:</p>
+example, the preceding example could be written as:</p>
<div class="doc_code">
<dt><tt>VectorType</tt></dt>
<dd>Subclass of SequentialType for vector types. A
vector type is similar to an ArrayType but is distinguished because it is
- a first class type wherease ArrayType is not. Vector types are used for
+ a first class type whereas ArrayType is not. Vector types are used for
vector operations and are usually small vectors of of an integer or floating
point type.</dd>
<dt><tt>StructType</tt></dt>
<p>The list of <a href="#BasicBlock"><tt>BasicBlock</tt></a>s is the most
commonly used part of <tt>Function</tt> objects. The list imposes an implicit
ordering of the blocks in the function, which indicate how the code will be
-la
yed out by the backend. Additionally, the first <a
+la
id out by the backend. Additionally, the first <a
href="#BasicBlock"><tt>BasicBlock</tt></a> is the implicit entry node for the
<tt>Function</tt>. It is not legal in LLVM to explicitly branch to this initial
block. There are no implicit exit nodes, and in fact there may be multiple exit
<a href="#User"><tt>User</tt></a>,
<a href="#Value"><tt>Value</tt></a></p>
-<p>Global variables are represented with the (suprise suprise)
+<p>Global variables are represented with the (surprise surprise)
<tt>GlobalVariable</tt> class. Like functions, <tt>GlobalVariable</tt>s are also
subclasses of <a href="#GlobalValue"><tt>GlobalValue</tt></a>, and as such are
always referenced by their address (global values must live in memory, so their
<li><tt><a href="#Constant">Constant</a> *getInitializer()</tt>
- <p>Returns the intial value for a <tt>GlobalVariable</tt>. It is not legal
+ <p>Returns the initial value for a <tt>GlobalVariable</tt>. It is not legal
to call this method if there is no initializer.</p></li>
</ul>
way. Also, all debugging information objects start with a tag to indicate
what type of object it is. The source-language is allowed to define its own
objects, by using unreserved tag numbers. We recommend using with tags in
- the range 0x1000 thru 0x2000 (there is a defined enum DW_TAG_user_base =
+ the range 0x1000 through 0x2000 (there is a defined enum DW_TAG_user_base =
0x1000.)</p>
<p>The fields of debug descriptors used internally by LLVM
<p>When choosing a superclass for your Pass, you should choose the <b>most
specific</b> class possible, while still being able to meet the requirements
listed. This gives the LLVM Pass Infrastructure information necessary to
-optimize how passes are run, so that the resultant compiler isn't unneccesarily
+optimize how passes are run, so that the resultant compiler isn't unnecessarily
slow.</p>
</div>
href="http://llvm.org/doxygen/classllvm_1_1ModulePass.html">ModulePass</a></tt>"
class is the most general of all superclasses that you can use. Deriving from
<tt>ModulePass</tt> indicates that your pass uses the entire program as a unit,
-refering to function bodies in no predictable order, or adding and removing
+referring to function bodies in no predictable order, or adding and removing
functions. Because nothing is known about the behavior of <tt>ModulePass</tt>
subclasses, no optimization can be done for their execution.</p>
</div>
<p>References to variables are also quite simple using LLVM. In the simple version
-of Kaleidoscope, we assume that the variable has already been emited somewhere
+of Kaleidoscope, we assume that the variable has already been emitted somewhere
and its value is available. In practice, the only values that can be in the
<tt>NamedValues</tt> map are function arguments. This
code simply checks to see that the specified name is in the map (if not, an
first, we want to allow 'extern'ing a function more than once, as long as the
prototypes for the externs match (since all arguments have the same type, we
just have to check that the number of arguments match). Second, we want to
-allow 'extern'ing a function and then definining a body for it. This is useful
+allow 'extern'ing a function and then defining a body for it. This is useful
when defining mutually recursive functions.</p>
<p>In order to implement this, the code above first checks to see if there is
to construct itself. Once it is set up, we use a series of "add" calls to add
a bunch of LLVM passes. The first pass is basically boilerplate, it adds a pass
so that later optimizations know how the data structures in the program are
-layed out. The "<tt>TheExecutionEngine</tt>" variable is related to the JIT,
+laid out. The "<tt>TheExecutionEngine</tt>" variable is related to the JIT,
which we will get to in the next section.</p>
<p>In this case, we choose to add 4 optimization passes. The passes we chose
</div>
<p>References to variables are also quite simple using LLVM. In the simple
-version of Kaleidoscope, we assume that the variable has already been emited
+version of Kaleidoscope, we assume that the variable has already been emitted
somewhere and its value is available. In practice, the only values that can be
in the <tt>Codegen.named_values</tt> map are function arguments. This code
simply checks to see that the specified name is in the map (if not, an unknown
first, we want to allow 'extern'ing a function more than once, as long as the
prototypes for the externs match (since all arguments have the same type, we
just have to check that the number of arguments match). Second, we want to
-allow 'extern'ing a function and then definining a body for it. This is useful
+allow 'extern'ing a function and then defining a body for it. This is useful
when defining mutually recursive functions.</p>
<div class="doc_code">
<tt>the_module_provider</tt>) to construct itself. Once it is set up, we use a
series of "add" calls to add a bunch of LLVM passes. The first pass is
basically boilerplate, it adds a pass so that later optimizations know how the
-data structures in the program are layed out. The
+data structures in the program are laid out. The
"<tt>the_execution_engine</tt>" variable is related to the JIT, which we will
get to in the next section.</p>
projects / oota-llvm.git / commitdiff