llvm.org GIT mirror llvm / 8040cd3
Documentation: Perform automated correction of common typos. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83849 91177308-0d34-0410-b5e6-96231b3b80d8 Benjamin Kramer 10 years ago
19 changed file(s) with 42 addition(s) and 42 deletion(s). Raw diff Collapse all Expand all
253253 a content-specific id number (for example, LLVM IR uses an ID of 12 to represent
254254 function bodies). Block IDs 0-7 are reserved for standard blocks
255255 whose meaning is defined by Bitcode; block IDs 8 and greater are
256 application specific. Nested blocks capture the hierachical structure of the data
256 application specific. Nested blocks capture the hierarchical structure of the data
257257 encoded in it, and various properties are associated with blocks as the file is
258258 parsed. Block definitions allow the reader to efficiently skip blocks
259259 in constant time if the reader wants a summary of blocks, or if it wants to
302302
303303
304304

In all cases, prefer spaces to tabs in source files. People have different

305 prefered indentation levels, and different styles of indentation that they
305 preferred indentation levels, and different styles of indentation that they
306306 like... this is fine. What isn't is that different editors/viewers expand tabs
307307 out to different tab stops. This can cause your code to look completely
308308 unreadable, and it is not worth dealing with.

490490 must include all of the header files that you are using -- you can
491491 include them either directly
492492 or indirectly (through another header file). To make sure that you don't
493 accidently forget to include a header file in your module header, make sure to
493 accidentally forget to include a header file in your module header, make sure to
494494 include your module header first in the implementation file (as mentioned
495495 above). This way there won't be any hidden dependencies that you'll find out
496496 about later...

789789
790790
791791

Use the "assert" function to its fullest. Check all of your

792 preconditions and assumptions, you never know when a bug (not neccesarily even
792 preconditions and assumptions, you never know when a bug (not necessarily even
793793 yours) might be caught early by an assertion, which reduces debugging time
794794 dramatically. The "<cassert>" header file is probably already
795795 included by the header files you are using, so it doesn't cost anything to use
10211021 code from the storage of the value parsed. For example, lets say that we have a
10221022 '-debug' option that we would like to use to enable debug information
10231023 across the entire body of our program. In this case, the boolean value
1024 controlling the debug code should be globally accessable (in a header file, for
1024 controlling the debug code should be globally accessible (in a header file, for
10251025 example) yet the command line option processing code should not be exposed to
10261026 all of these clients (requiring lots of .cpp files to #include
10271027 CommandLine.h).

11061106 example.
11071107
11081108
  • The cl::init attribute specifies an
  • 1109 inital value for a scalar option. If this attribute is
    1109 initial value for a scalar option. If this attribute is
    11101110 not specified then the command line option value defaults to the value created
    11111111 by the default constructor for the type. Warning: If you specify both
    11121112 cl::init and cl::location for an option,
    11771177 tweak how options are parsed and how --help output is generated to fit
    11781178 your application well.

    11791179
    1180

    These options fall into five main catagories:

    1180

    These options fall into five main categories:

    11811181
    11821182
    11831183
  • Hiding an option from --help output
  • 11891189
  • Miscellaneous option modifiers
  • 11901190
    11911191
    1192

    It is not possible to specify two options from the same catagory (you'll get

    1192

    It is not possible to specify two options from the same category (you'll get

    11931193 a runtime error) to a single option, except for options in the miscellaneous
    1194 catagory. The CommandLine library specifies defaults for all of these settings
    1194 category. The CommandLine library specifies defaults for all of these settings
    11951195 that are the most useful in practice and the most common, which mean that you
    11961196 usually shouldn't have to worry about these.

    11971197
    15351535 environment variable to examine, the optional
    15361536 additional extra text to emit when the
    15371537 --help option is invoked, and the boolean
    1538 switch that controls whether reponse files
    1538 switch that controls whether response files
    15391539 should be read.

    15401540
    15411541

    cl::ParseEnvironmentOptions will break the environment

    306306 -std=c99. It is also allowed to use spaces instead of the equality
    307307 sign: -std c99. At most one occurrence is allowed.
    308308
  • parameter_list_option - same as the above, but more than one option
  • 309 occurence is allowed.
    309 occurrence is allowed.
    310310
  • prefix_option - same as the parameter_option, but the option name and
  • 311311 argument do not have to be separated. Example: -ofile. This can be also
    312312 specified as -o file; however, -o=file will be parsed incorrectly
    313313 (=file will be interpreted as option value). At most one occurrence is
    314314 allowed.
    315
  • prefix_list_option - same as the above, but more than one occurence of
  • 315
  • prefix_list_option - same as the above, but more than one occurrence of
  • 316316 the option is allowed; example: -lm -lpthread.
    317317
  • alias_option - a special option type for creating aliases. Unlike other
  • 318318 option types, aliases are not allowed to have any properties besides the
    681681 Mikhail Glushenkov
    682682 LLVM Compiler Infrastructure
    683683
    684 Last modified: $Date: 2008-12-11 11:34:48 -0600 (Thu, 11 Dec 2008) $
    684 Last modified: $Date$
    685685
    686686
    687687
    684684

    Also, there are a number of other limitations of the C backend that cause it

    685685 to produce code that does not fully conform to the C++ ABI on most
    686686 platforms. Some of the C++ programs in LLVM's test suite are known to fail
    687 when compiled with the C back end because of ABI incompatiblities with
    687 when compiled with the C back end because of ABI incompatibilities with
    688688 standard C++ libraries.

    689689
    690690
    699699 portable is by using the preprocessor to include platform-specific code. In
    700700 practice, information about other platforms is lost after preprocessing, so
    701701 the result is inherently dependent on the platform that the preprocessing was
    702 targetting.

    702 targeting.

    703703
    704704

    Another example is sizeof. It's common for sizeof(long) to

    705705 vary between platforms. In most C front-ends, sizeof is expanded to
    3939
    4040

    This document seeks to dispel the mystery and confusion surrounding LLVM's

    4141 GetElementPtr (GEP) instruction. Questions about the wiley GEP instruction are
    42 probably the most frequently occuring questions once a developer gets down to
    42 probably the most frequently occurring questions once a developer gets down to
    4343 coding with LLVM. Here we lay out the sources of confusion and show that the
    4444 GEP instruction is really quite simple.
    4545

    3939
    4040

    LLVM is released on a time based schedule (currently every 6 months). We

    4141 do not have dot releases because of the nature of LLVM incremental
    42 developement philosophy. The release schedule is roughly as follows:
    42 development philosophy. The release schedule is roughly as follows:
    4343

    4444
    4545
  • Set code freeze and branch creation date for 6 months after last code freeze
  • 498498 release documentation.
    499499
  • Finally, update the main page (index.html and sidebar) to
  • 500500 point to the new release and release announcement. Make sure this all gets
    501 commited back into Subversion.
    501 committed back into Subversion.
    502502
    503503
    504504
    5959

    Once you have a reduced test-case, go to

    6060 href="http://llvm.org/bugs/enter_bug.cgi">the LLVM Bug Tracking
    6161 System and fill out the form with the necessary details (note that you don't
    62 need to pick a catagory, just use the "new-bugs" catagory if you're not sure).
    62 need to pick a category, just use the "new-bugs" category if you're not sure).
    6363 The bug description should contain the following
    6464 information:

    6565
    20182018
    20192019
    20202020

    The string 'undef' can be used anywhere a constant is expected, and

    2021 indicates that the user of the value may recieve an unspecified bit-pattern.
    2021 indicates that the user of the value may receive an unspecified bit-pattern.
    20222022 Undefined values may be of any type (other than label or void) and be used
    20232023 anywhere a constant is permitted.

    20242024
    21172117 arbitrarily change its value over its "live range". This is true because the
    21182118 "variable" doesn't actually have a live range. Instead, the value is
    21192119 logically read from arbitrary registers that happen to be around when needed,
    2120 so the value is not neccesarily consistent over time. In fact, %A and %C need
    2120 so the value is not necessarily consistent over time. In fact, %A and %C need
    21212121 to have the same semantics or the core LLVM "replace all uses with" concept
    21222122 would not hold.

    21232123
    22992299 the two digit hex code. For example: "!"test\00"".

    23002300
    23012301

    Metadata nodes are represented with notation similar to structure constants

    2302 (a comma separated list of elements, surrounded by braces and preceeded by an
    2302 (a comma separated list of elements, surrounded by braces and preceded by an
    23032303 exclamation point). For example: "!{ metadata !"test\00", i32
    23042304 10}".

    23052305
    26182618

    The switch instruction specifies a table of values and

    26192619 destinations. When the 'switch' instruction is executed, this table
    26202620 is searched for the given value. If the value is found, control flow is
    2621 transfered to the corresponding destination; otherwise, control flow is
    2622 transfered to the default destination.

    2621 transferred to the corresponding destination; otherwise, control flow is
    2622 transferred to the default destination.

    26232623
    26242624
    Implementation:
    26252625

    Depending on properties of the target machine and the particular

    165165 provided by the linker on various platform are not unique. This means,
    166166 this new tool needs to support all such features and platforms in one
    167167 super tool or a separate tool per platform is required. This increases
    168 maintance cost for link time optimizer significantly, which is not
    168 maintenance cost for link time optimizer significantly, which is not
    169169 necessary. This approach also requires staying synchronized with linker
    170170 developements on various platforms, which is not the main focus of the link
    171171 time optimizer. Finally, this approach increases end user's build time due
    188188 user-supplied information, such as a list of exported symbols. LLVM
    189189 optimizer collects control flow information, data flow information and knows
    190190 much more about program structure from the optimizer's point of view.
    191 Our goal is to take advantage of tight intergration between the linker and
    191 Our goal is to take advantage of tight integration between the linker and
    192192 the optimizer by sharing this information during various linking phases.
    193193

    194194
    260260
    261261
    262262
    263

    In some situations, it is desireable to build a single bitcode module from

    263

    In some situations, it is desirable to build a single bitcode module from

    264264 a variety of sources, instead of an archive, shared library, or bitcode
    265265 library. Bitcode modules can be specified in addition to any of the other
    266266 types of libraries by defining the MODULE_NAME
    15431543

    15441544 This file demotes all registers to memory references. It is intented to be
    15451545 the inverse of -mem2reg. By converting to
    1546 load instructions, the only values live accross basic blocks are
    1546 load instructions, the only values live across basic blocks are
    15471547 alloca instructions and load instructions before
    15481548 phi nodes. It is intended that this should make CFG hacking much
    15491549 easier. To make later hacking easier, the entry block is split into two, such
    649649

    The DEBUG_WITH_TYPE macro is also available for situations where you

    650650 would like to set DEBUG_TYPE, but only for one specific DEBUG
    651651 statement. It takes an additional first parameter, which is the type to use. For
    652 example, the preceeding example could be written as:

    652 example, the preceding example could be written as:

    653653
    654654
    655655
    29822982
    VectorType
    29832983
    Subclass of SequentialType for vector types. A
    29842984 vector type is similar to an ArrayType but is distinguished because it is
    2985 a first class type wherease ArrayType is not. Vector types are used for
    2985 a first class type whereas ArrayType is not. Vector types are used for
    29862986 vector operations and are usually small vectors of of an integer or floating
    29872987 point type.
    29882988
    StructType
    35513551

    The list of BasicBlocks is the most

    35523552 commonly used part of Function objects. The list imposes an implicit
    35533553 ordering of the blocks in the function, which indicate how the code will be
    3554 layed out by the backend. Additionally, the first
    3554 laid out by the backend. Additionally, the first
    35553555 href="#BasicBlock">BasicBlock is the implicit entry node for the
    35563556 Function. It is not legal in LLVM to explicitly branch to this initial
    35573557 block. There are no implicit exit nodes, and in fact there may be multiple exit
    36813681 User,
    36823682 Value

    36833683
    3684

    Global variables are represented with the (suprise suprise)

    3684

    Global variables are represented with the (surprise surprise)

    36853685 GlobalVariable class. Like functions, GlobalVariables are also
    36863686 subclasses of GlobalValue, and as such are
    36873687 always referenced by their address (global values must live in memory, so their
    37313731
    37323732
  • Constant *getInitializer()
  • 37333733
    3734

    Returns the intial value for a GlobalVariable. It is not legal

    3734

    Returns the initial value for a GlobalVariable. It is not legal

    37353735 to call this method if there is no initializer.

    37363736
    37373737
    287287 way. Also, all debugging information objects start with a tag to indicate
    288288 what type of object it is. The source-language is allowed to define its own
    289289 objects, by using unreserved tag numbers. We recommend using with tags in
    290 the range 0x1000 thru 0x2000 (there is a defined enum DW_TAG_user_base =
    290 the range 0x1000 through 0x2000 (there is a defined enum DW_TAG_user_base =
    291291 0x1000.)

    292292
    293293

    The fields of debug descriptors used internally by LLVM

    452452

    When choosing a superclass for your Pass, you should choose the most

    453453 specific class possible, while still being able to meet the requirements
    454454 listed. This gives the LLVM Pass Infrastructure information necessary to
    455 optimize how passes are run, so that the resultant compiler isn't unneccesarily
    455 optimize how passes are run, so that the resultant compiler isn't unnecessarily
    456456 slow.

    457457
    458458
    491491 href="http://llvm.org/doxygen/classllvm_1_1ModulePass.html">ModulePass"
    492492 class is the most general of all superclasses that you can use. Deriving from
    493493 ModulePass indicates that your pass uses the entire program as a unit,
    494 refering to function bodies in no predictable order, or adding and removing
    494 referring to function bodies in no predictable order, or adding and removing
    495495 functions. Because nothing is known about the behavior of ModulePass
    496496 subclasses, no optimization can be done for their execution.

    497497
    182182
    183183
    184184

    References to variables are also quite simple using LLVM. In the simple version

    185 of Kaleidoscope, we assume that the variable has already been emited somewhere
    185 of Kaleidoscope, we assume that the variable has already been emitted somewhere
    186186 and its value is available. In practice, the only values that can be in the
    187187 NamedValues map are function arguments. This
    188188 code simply checks to see that the specified name is in the map (if not, an
    361361 first, we want to allow 'extern'ing a function more than once, as long as the
    362362 prototypes for the externs match (since all arguments have the same type, we
    363363 just have to check that the number of arguments match). Second, we want to
    364 allow 'extern'ing a function and then definining a body for it. This is useful
    364 allow 'extern'ing a function and then defining a body for it. This is useful
    365365 when defining mutually recursive functions.

    366366
    367367

    In order to implement this, the code above first checks to see if there is

    208208 to construct itself. Once it is set up, we use a series of "add" calls to add
    209209 a bunch of LLVM passes. The first pass is basically boilerplate, it adds a pass
    210210 so that later optimizations know how the data structures in the program are
    211 layed out. The "TheExecutionEngine" variable is related to the JIT,
    211 laid out. The "TheExecutionEngine" variable is related to the JIT,
    212212 which we will get to in the next section.

    213213
    214214

    In this case, we choose to add 4 optimization passes. The passes we chose

    158158
    159159
    160160

    References to variables are also quite simple using LLVM. In the simple

    161 version of Kaleidoscope, we assume that the variable has already been emited
    161 version of Kaleidoscope, we assume that the variable has already been emitted
    162162 somewhere and its value is available. In practice, the only values that can be
    163163 in the Codegen.named_values map are function arguments. This code
    164164 simply checks to see that the specified name is in the map (if not, an unknown
    322322 first, we want to allow 'extern'ing a function more than once, as long as the
    323323 prototypes for the externs match (since all arguments have the same type, we
    324324 just have to check that the number of arguments match). Second, we want to
    325 allow 'extern'ing a function and then definining a body for it. This is useful
    325 allow 'extern'ing a function and then defining a body for it. This is useful
    326326 when defining mutually recursive functions.

    327327
    328328
    223223 the_module_provider) to construct itself. Once it is set up, we use a
    224224 series of "add" calls to add a bunch of LLVM passes. The first pass is
    225225 basically boilerplate, it adds a pass so that later optimizations know how the
    226 data structures in the program are layed out. The
    226 data structures in the program are laid out. The
    227227 "the_execution_engine" variable is related to the JIT, which we will
    228228 get to in the next section.

    229229