mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-23 03:02:36 +01:00
Documentation: Perform automated correction of common typos.
llvm-svn: 83849
This commit is contained in:
Benjamin Kramer
parent
01eeaaa236
commit
1791be26f8
@ -254,7 +254,7 @@ Blocks in a bitstream denote nested regions of the stream, and are identified by
|
||||
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
|
||||
|
||||
@ -303,7 +303,7 @@ for debate.</p>
|
||||
<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>
|
||||
@ -491,7 +491,7 @@ most cases, you simply don't need the definition of a class... and not
|
||||
<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>
|
||||
@ -790,7 +790,7 @@ locality.</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
|
||||
|
||||
@ -1022,7 +1022,7 @@ files that use them. This is called the internal storage model.</p>
|
||||
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>
|
||||
@ -1107,7 +1107,7 @@ a command line option. Look <a href="#value_desc_example">here</a> for an
|
||||
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
|
||||
initial 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,
|
||||
@ -1178,7 +1178,7 @@ href="#cl::list">cl::list</a></tt>. These modifiers give you the ability to
|
||||
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>
|
||||
@ -1190,9 +1190,9 @@ your application well.</p>
|
||||
<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>
|
||||
|
||||
@ -1536,7 +1536,7 @@ not be available, it can't just look in <tt>argv[0]</tt>), the name of the
|
||||
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
|
||||
|
||||
@ -307,13 +307,13 @@ separate option groups syntactically.</p>
|
||||
<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
|
||||
@ -682,7 +682,7 @@ the <tt class="docutils literal"><span class="pre">Base</span></tt> plugin behav
|
||||
<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>
|
||||
|
||||
@ -685,7 +685,7 @@ Stop.
|
||||
<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>
|
||||
|
||||
@ -700,7 +700,7 @@ Stop.
|
||||
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
|
||||
|
||||
@ -40,7 +40,7 @@
|
||||
<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>
|
||||
|
||||
@ -40,7 +40,7 @@
|
||||
<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
|
||||
@ -499,7 +499,7 @@ svn copy https://llvm.org/svn/llvm-project/test-suite/branches/release_XX \
|
||||
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>
|
||||
|
||||
|
||||
@ -60,7 +60,7 @@ more easily.</p>
|
||||
<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>
|
||||
|
||||
|
||||
@ -2019,7 +2019,7 @@ Classifications</a> </div>
|
||||
<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>
|
||||
|
||||
@ -2118,7 +2118,7 @@ number of reasons, but the short answer is that an undef "variable" can
|
||||
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>
|
||||
|
||||
@ -2300,7 +2300,7 @@ has undefined behavior.</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>
|
||||
|
||||
@ -2619,8 +2619,8 @@ IfUnequal:
|
||||
<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
|
||||
|
||||
@ -166,7 +166,7 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific
|
||||
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
|
||||
@ -189,7 +189,7 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific
|
||||
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>
|
||||
|
||||
@ -261,7 +261,7 @@
|
||||
<!-- ======================================================================= -->
|
||||
<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>
|
||||
|
||||
@ -1544,7 +1544,7 @@ if (X < 3) {</pre>
|
||||
<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
|
||||
|
||||
@ -650,7 +650,7 @@ even if the source lives in multiple files.</p>
|
||||
<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">
|
||||
@ -2983,7 +2983,7 @@ the <tt>lib/VMCore</tt> directory.</p>
|
||||
<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>
|
||||
@ -3552,7 +3552,7 @@ of a list of <a href="#BasicBlock"><tt>BasicBlock</tt></a>s, a list of formal
|
||||
<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
|
||||
layed out by the backend. Additionally, the first <a
|
||||
laid 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
|
||||
@ -3682,7 +3682,7 @@ Superclasses: <a href="#GlobalValue"><tt>GlobalValue</tt></a>,
|
||||
<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
|
||||
@ -3732,7 +3732,7 @@ never change at runtime).</p>
|
||||
|
||||
<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>
|
||||
|
||||
|
||||
@ -288,7 +288,7 @@ height="369">
|
||||
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
|
||||
|
||||
@ -453,7 +453,7 @@ available, from the most general to the most specific.</p>
|
||||
<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>
|
||||
@ -492,7 +492,7 @@ invalidated, and are never "run".</p>
|
||||
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>
|
||||
|
||||
|
||||
@ -183,7 +183,7 @@ Value *VariableExprAST::Codegen() {
|
||||
</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
|
||||
@ -362,7 +362,7 @@ definition of this function.</p>
|
||||
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
|
||||
|
||||
@ -209,7 +209,7 @@ requires a pointer to the <tt>Module</tt> (through the <tt>ModuleProvider</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 "<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
|
||||
|
||||
@ -159,7 +159,7 @@ uses "the foo::get(..)" idiom instead of "new foo(..)" or "foo::Create(..)".</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
|
||||
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
|
||||
@ -323,7 +323,7 @@ code above.</p>
|
||||
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">
|
||||
|
||||
@ -224,7 +224,7 @@ requires a pointer to the <tt>the_module</tt> (through the
|
||||
<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>
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user