diff options
| author | Eli Bendersky <eliben@chromium.org> | 2013-07-15 16:09:15 -0700 |
|---|---|---|
| committer | Eli Bendersky <eliben@chromium.org> | 2013-07-15 16:09:15 -0700 |
| commit | c6cf05cb5108f356dde97c01ee4188b0671d4542 (patch) | |
| tree | 436fdc2a55296d3c202e7ef11f31be3be53efb5f /docs | |
| parent | c75199c649c739aade160289d93f257edc798cde (diff) | |
| parent | 7dfcb84fc16b3bf6b2379713b53090757f0a45f9 (diff) | |
Merge commit '7dfcb84fc16b3bf6b2379713b53090757f0a45f9'
Conflicts:
docs/LangRef.rst
include/llvm/CodeGen/CallingConvLower.h
include/llvm/IRReader/IRReader.h
include/llvm/Target/TargetMachine.h
lib/CodeGen/CallingConvLower.cpp
lib/IRReader/IRReader.cpp
lib/IRReader/LLVMBuild.txt
lib/IRReader/Makefile
lib/LLVMBuild.txt
lib/Makefile
lib/Support/MemoryBuffer.cpp
lib/Support/Unix/PathV2.inc
lib/Target/ARM/ARMBaseInstrInfo.cpp
lib/Target/ARM/ARMISelLowering.cpp
lib/Target/ARM/ARMInstrInfo.td
lib/Target/ARM/ARMSubtarget.cpp
lib/Target/ARM/ARMTargetMachine.cpp
lib/Target/Mips/CMakeLists.txt
lib/Target/Mips/MipsDelaySlotFiller.cpp
lib/Target/Mips/MipsISelLowering.cpp
lib/Target/Mips/MipsInstrInfo.td
lib/Target/Mips/MipsSubtarget.cpp
lib/Target/Mips/MipsSubtarget.h
lib/Target/X86/X86FastISel.cpp
lib/Target/X86/X86ISelDAGToDAG.cpp
lib/Target/X86/X86ISelLowering.cpp
lib/Target/X86/X86InstrControl.td
lib/Target/X86/X86InstrFormats.td
lib/Transforms/IPO/ExtractGV.cpp
lib/Transforms/InstCombine/InstCombineCompares.cpp
lib/Transforms/Utils/SimplifyLibCalls.cpp
test/CodeGen/X86/fast-isel-divrem.ll
test/MC/ARM/data-in-code.ll
tools/Makefile
tools/llvm-extract/llvm-extract.cpp
tools/llvm-link/CMakeLists.txt
tools/opt/CMakeLists.txt
tools/opt/LLVMBuild.txt
tools/opt/Makefile
tools/opt/opt.cpp
Diffstat (limited to 'docs')
45 files changed, 1271 insertions, 409 deletions
diff --git a/docs/CMake.rst b/docs/CMake.rst index 6eab04b970..8459081fb8 100644 --- a/docs/CMake.rst +++ b/docs/CMake.rst @@ -168,8 +168,8 @@ LLVM-specific variables **LLVM_TARGETS_TO_BUILD**:STRING Semicolon-separated list of targets to build, or *all* for building all - targets. Case-sensitive. For Visual C++ defaults to *X86*. On the other cases - defaults to *all*. Example: ``-DLLVM_TARGETS_TO_BUILD="X86;PowerPC"``. + targets. Case-sensitive. Defaults to *all*. Example: + ``-DLLVM_TARGETS_TO_BUILD="X86;PowerPC"``. **LLVM_BUILD_TOOLS**:BOOL Build LLVM tools. Defaults to ON. Targets for building each tool are generated @@ -204,7 +204,7 @@ LLVM-specific variables tests. **LLVM_APPEND_VC_REV**:BOOL - Append version control revision info (svn revision number or git revision id) + Append version control revision info (svn revision number or Git revision id) to LLVM version string (stored in the PACKAGE_VERSION macro). For this to work cmake must be invoked before the build. Defaults to OFF. @@ -271,6 +271,10 @@ LLVM-specific variables **LLVM_USE_INTEL_JITEVENTS**:BOOL Enable building support for Intel JIT Events API. Defaults to OFF +**LLVM_ENABLE_ZLIB**:BOOL + Build with zlib to support compression/uncompression in LLVM tools. + Defaults to ON. + Executing the test suite ======================== diff --git a/docs/CodeGenerator.rst b/docs/CodeGenerator.rst index b5d4180974..10ca307b78 100644 --- a/docs/CodeGenerator.rst +++ b/docs/CodeGenerator.rst @@ -1038,6 +1038,24 @@ for your target. It has the following strengths: are used to manipulate the input immediate (in this case, take the high or low 16-bits of the immediate). +* When using the 'Pat' class to map a pattern to an instruction that has one + or more complex operands (like e.g. `X86 addressing mode`_), the pattern may + either specify the operand as a whole using a ``ComplexPattern``, or else it + may specify the components of the complex operand separately. The latter is + done e.g. for pre-increment instructions by the PowerPC back end: + + :: + + def STWU : DForm_1<37, (outs ptr_rc:$ea_res), (ins GPRC:$rS, memri:$dst), + "stwu $rS, $dst", LdStStoreUpd, []>, + RegConstraint<"$dst.reg = $ea_res">, NoEncode<"$ea_res">; + + def : Pat<(pre_store GPRC:$rS, ptr_rc:$ptrreg, iaddroff:$ptroff), + (STWU GPRC:$rS, iaddroff:$ptroff, ptr_rc:$ptrreg)>; + + Here, the pair of ``ptroff`` and ``ptrreg`` operands is matched onto the + complex operand ``dst`` of class ``memri`` in the ``STWU`` instruction. + * While the system does automate a lot, it still allows you to write custom C++ code to match special cases if there is something that is hard to express. @@ -1776,6 +1794,7 @@ Here is the table: :raw-html:`<th>NVPTX</th>` :raw-html:`<th>PowerPC</th>` :raw-html:`<th>Sparc</th>` +:raw-html:`<th>SystemZ</th>` :raw-html:`<th>X86</th>` :raw-html:`<th>XCore</th>` :raw-html:`</tr>` @@ -1790,8 +1809,9 @@ Here is the table: :raw-html:`<td class="yes"></td> <!-- NVPTX -->` :raw-html:`<td class="yes"></td> <!-- PowerPC -->` :raw-html:`<td class="yes"></td> <!-- Sparc -->` +:raw-html:`<td class="yes"></td> <!-- SystemZ -->` :raw-html:`<td class="yes"></td> <!-- X86 -->` -:raw-html:`<td class="unknown"></td> <!-- XCore -->` +:raw-html:`<td class="yes"></td> <!-- XCore -->` :raw-html:`</tr>` :raw-html:`<tr>` @@ -1804,6 +1824,7 @@ Here is the table: :raw-html:`<td class="no"></td> <!-- NVPTX -->` :raw-html:`<td class="no"></td> <!-- PowerPC -->` :raw-html:`<td class="no"></td> <!-- Sparc -->` +:raw-html:`<td class="yes"></td> <!-- SystemZ -->` :raw-html:`<td class="yes"></td> <!-- X86 -->` :raw-html:`<td class="no"></td> <!-- XCore -->` :raw-html:`</tr>` @@ -1817,9 +1838,10 @@ Here is the table: :raw-html:`<td class="no"></td> <!-- Mips -->` :raw-html:`<td class="na"></td> <!-- NVPTX -->` :raw-html:`<td class="no"></td> <!-- PowerPC -->` +:raw-html:`<td class="no"></td> <!-- SystemZ -->` :raw-html:`<td class="no"></td> <!-- Sparc -->` :raw-html:`<td class="yes"></td> <!-- X86 -->` -:raw-html:`<td class="no"></td> <!-- XCore -->` +:raw-html:`<td class="yes"></td> <!-- XCore -->` :raw-html:`</tr>` :raw-html:`<tr>` @@ -1832,8 +1854,9 @@ Here is the table: :raw-html:`<td class="yes"></td> <!-- NVPTX -->` :raw-html:`<td class="yes"></td> <!-- PowerPC -->` :raw-html:`<td class="unknown"></td> <!-- Sparc -->` +:raw-html:`<td class="yes"></td> <!-- SystemZ -->` :raw-html:`<td class="yes"></td> <!-- X86 -->` -:raw-html:`<td class="unknown"></td> <!-- XCore -->` +:raw-html:`<td class="yes"></td> <!-- XCore -->` :raw-html:`</tr>` :raw-html:`<tr>` @@ -1846,8 +1869,9 @@ Here is the table: :raw-html:`<td class="na"></td> <!-- NVPTX -->` :raw-html:`<td class="yes"></td> <!-- PowerPC -->` :raw-html:`<td class="unknown"></td> <!-- Sparc -->` +:raw-html:`<td class="yes"></td> <!-- SystemZ -->` :raw-html:`<td class="yes"></td> <!-- X86 -->` -:raw-html:`<td class="unknown"></td> <!-- XCore -->` +:raw-html:`<td class="no"></td> <!-- XCore -->` :raw-html:`</tr>` :raw-html:`<tr>` @@ -1860,6 +1884,7 @@ Here is the table: :raw-html:`<td class="na"></td> <!-- NVPTX -->` :raw-html:`<td class="no"></td> <!-- PowerPC -->` :raw-html:`<td class="no"></td> <!-- Sparc -->` +:raw-html:`<td class="yes"></td> <!-- SystemZ -->` :raw-html:`<td class="yes"></td> <!-- X86 -->` :raw-html:`<td class="no"></td> <!-- XCore -->` :raw-html:`</tr>` @@ -1874,8 +1899,9 @@ Here is the table: :raw-html:`<td class="no"></td> <!-- NVPTX -->` :raw-html:`<td class="yes"></td> <!-- PowerPC -->` :raw-html:`<td class="unknown"></td> <!-- Sparc -->` +:raw-html:`<td class="no"></td> <!-- SystemZ -->` :raw-html:`<td class="yes"></td> <!-- X86 -->` -:raw-html:`<td class="unknown"></td> <!-- XCore -->` +:raw-html:`<td class="no"></td> <!-- XCore -->` :raw-html:`</tr>` :raw-html:`<tr>` @@ -1888,6 +1914,7 @@ Here is the table: :raw-html:`<td class="no"></td> <!-- NVPTX -->` :raw-html:`<td class="no"></td> <!-- PowerPC -->` :raw-html:`<td class="no"></td> <!-- Sparc -->` +:raw-html:`<td class="no"></td> <!-- SystemZ -->` :raw-html:`<td class="partial"><a href="#feat_segstacks_x86">*</a></td> <!-- X86 -->` :raw-html:`<td class="no"></td> <!-- XCore -->` :raw-html:`</tr>` diff --git a/docs/CommandGuide/index.rst b/docs/CommandGuide/index.rst index 9bfa9645d8..b3b4bc389e 100644 --- a/docs/CommandGuide/index.rst +++ b/docs/CommandGuide/index.rst @@ -28,6 +28,7 @@ Basic Commands llvm-diff llvm-cov llvm-stress + llvm-symbolizer Debugging Tools ~~~~~~~~~~~~~~~ @@ -49,3 +50,4 @@ Developer Tools tblgen lit llvm-build + llvm-readobj diff --git a/docs/CommandGuide/llc.rst b/docs/CommandGuide/llc.rst index 70354b0343..e6a59767aa 100644 --- a/docs/CommandGuide/llc.rst +++ b/docs/CommandGuide/llc.rst @@ -69,6 +69,14 @@ End-user Options llvm-as < /dev/null | llc -march=xyz -mcpu=help +.. option:: -filetype=<output file type> + + Specify what kind of output ``llc`` should generated. Options are: ``asm`` + for textual assembly ( ``'.s'``), ``obj`` for native object files (``'.o'``) + and ``null`` for not emitting anything (for performance testing). + + Note that not all targets support all options. + .. option:: -mattr=a1,+a2,-a3,... Override or control specific attributes of the target, such as whether SIMD diff --git a/docs/CommandGuide/lli.rst b/docs/CommandGuide/lli.rst index 7cc128444d..a9aaf310e1 100644 --- a/docs/CommandGuide/lli.rst +++ b/docs/CommandGuide/lli.rst @@ -50,7 +50,7 @@ GENERAL OPTIONS -**-load**\ =\ *puginfilename* +**-load**\ =\ *pluginfilename* Causes **lli** to load the plugin (shared object) named *pluginfilename* and use it for optimization. diff --git a/docs/CommandGuide/llvm-link.rst b/docs/CommandGuide/llvm-link.rst index e4f2228841..3bcfa68c25 100644 --- a/docs/CommandGuide/llvm-link.rst +++ b/docs/CommandGuide/llvm-link.rst @@ -1,5 +1,5 @@ -llvm-link - LLVM linker -======================= +llvm-link - LLVM bitcode linker +=============================== SYNOPSIS -------- @@ -13,23 +13,9 @@ DESCRIPTION into a single LLVM bitcode file. It writes the output file to standard output, unless the :option:`-o` option is used to specify a filename. -:program:`llvm-link` attempts to load the input files from the current -directory. If that fails, it looks for each file in each of the directories -specified by the :option:`-L` options on the command line. The library search -paths are global; each one is searched for every input file if necessary. The -directories are searched in the order they were specified on the command line. - OPTIONS ------- -.. option:: -L directory - - Add the specified ``directory`` to the library search path. When looking for - libraries, :program:`llvm-link` will look in path name for libraries. This - option can be specified multiple times; :program:`llvm-link` will search - inside these directories in the order in which they were specified on the - command line. - .. option:: -f Enable binary output on terminals. Normally, :program:`llvm-link` will refuse @@ -48,8 +34,8 @@ OPTIONS .. option:: -d - If specified, :program:`llvm-link` prints a human-readable version of the output - bitcode file to standard error. + If specified, :program:`llvm-link` prints a human-readable version of the + output bitcode file to standard error. .. option:: -help @@ -67,8 +53,4 @@ EXIT STATUS If :program:`llvm-link` succeeds, it will exit with 0. Otherwise, if an error occurs, it will exit with a non-zero value. -SEE ALSO --------- - -gccld diff --git a/docs/CommandGuide/llvm-readobj.rst b/docs/CommandGuide/llvm-readobj.rst new file mode 100644 index 0000000000..b1918b548f --- /dev/null +++ b/docs/CommandGuide/llvm-readobj.rst @@ -0,0 +1,86 @@ +llvm-readobj - LLVM Object Reader +================================= + +SYNOPSIS +-------- + +:program:`llvm-readobj` [*options*] [*input...*] + +DESCRIPTION +----------- + +The :program:`llvm-readobj` tool displays low-level format-specific information +about one or more object files. The tool and its output is primarily designed +for use in FileCheck-based tests. + +OPTIONS +------- + +If ``input`` is "``-``" or omitted, :program:`llvm-readobj` reads from standard +input. Otherwise, it will read from the specified ``filenames``. + +.. option:: -help + + Print a summary of command line options. + +.. option:: -version + + Display the version of this program + +.. option:: -file-headers, -h + + Display file headers. + +.. option:: -sections, -s + + Display all sections. + +.. option:: -section-data, -sd + + When used with ``-sections``, display section data for each section shown. + +.. option:: -section-relocations, -sr + + When used with ``-sections``, display relocations for each section shown. + +.. option:: -section-symbols, -st + + When used with ``-sections``, display symbols for each section shown. + +.. option:: -relocations, -r + + Display the relocation entries in the file. + +.. option:: -symbols, -t + + Display the symbol table. + +.. option:: -dyn-symbols + + Display the dynamic symbol table (only for ELF object files). + +.. option:: -unwind, -u + + Display unwind information. + +.. option:: -expand-relocs + + When used with ``-relocations``, display each relocation in an expanded + multi-line format. + +.. option:: -dynamic-table + + Display the ELF .dynamic section table (only for ELF object files). + +.. option:: -needed-libs + + Display the needed libraries (only for ELF object files). + +.. option:: -program-headers + + Display the ELF program headers (only for ELF object files). + +EXIT STATUS +----------- + +:program:`llvm-readobj` returns 0. diff --git a/docs/CommandGuide/llvm-symbolizer.rst b/docs/CommandGuide/llvm-symbolizer.rst new file mode 100644 index 0000000000..73babb1e5c --- /dev/null +++ b/docs/CommandGuide/llvm-symbolizer.rst @@ -0,0 +1,65 @@ +llvm-symbolizer - convert addresses into source code locations +============================================================== + +SYNOPSIS +-------- + +:program:`llvm-symbolizer` [options] + +DESCRIPTION +----------- + +:program:`llvm-symbolizer` reads object file names and addresses from standard +input and prints corresponding source code locations to standard output. This +program uses debug info sections and symbol table in the object files. + +EXAMPLE +-------- + +.. code-block:: console + + $ cat addr.txt + a.out 0x4004f4 + /tmp/b.out 0x400528 + /tmp/c.so 0x710 + $ llvm-symbolizer < addr.txt + main + /tmp/a.cc:4 + + f(int, int) + /tmp/b.cc:11 + + h_inlined_into_g + /tmp/header.h:2 + g_inlined_into_f + /tmp/header.h:7 + f_inlined_into_main + /tmp/source.cc:3 + main + /tmp/source.cc:8 + +OPTIONS +------- + +.. option:: -functions + + Print function names as well as source file/line locations. Defaults to true. + +.. option:: -use-symbol-table + + Prefer function names stored in symbol table to function names + in debug info sections. Defaults to true. + +.. option:: -demangle + + Print demangled function names. Defaults to true. + +.. option:: -inlining + + If a source code location is in an inlined function, prints all the + inlnied frames. Defaults to true. + +EXIT STATUS +----------- + +:program:`llvm-symbolizer` returns 0. Other exit codes imply internal program error. diff --git a/docs/CommandGuide/tblgen.rst b/docs/CommandGuide/tblgen.rst index 1858ee447d..1c4682830d 100644 --- a/docs/CommandGuide/tblgen.rst +++ b/docs/CommandGuide/tblgen.rst @@ -23,6 +23,8 @@ file to read as input. OPTIONS ------- +.. program:: tblgen + .. option:: -help Print a summary of command line options. @@ -56,7 +58,7 @@ OPTIONS .. option:: -print-enums - Print enumeration values for a class + Print enumeration values for a class. .. option:: -print-sets diff --git a/docs/CommandLine.rst b/docs/CommandLine.rst index 073958b16b..9b77a98908 100644 --- a/docs/CommandLine.rst +++ b/docs/CommandLine.rst @@ -2,6 +2,9 @@ CommandLine 2.0 Library Manual ============================== +.. contents:: + :local: + Introduction ============ @@ -615,6 +618,55 @@ would yield the help output: -help - display available options (-help-hidden for more) -o <filename> - Specify output filename +.. _grouping options into categories: + +Grouping options into categories +-------------------------------- + +If our program has a large number of options it may become difficult for users +of our tool to navigate the output of ``-help``. To alleviate this problem we +can put our options into categories. This can be done by declaring option +categories (`cl::OptionCategory`_ objects) and then placing our options into +these categories using the `cl::cat`_ option attribute. For example: + +.. code-block:: c++ + + cl::OptionCategory StageSelectionCat("Stage Selection Options", + "These control which stages are run."); + + cl::opt<bool> Preprocessor("E",cl::desc("Run preprocessor stage."), + cl::cat(StageSelectionCat)); + + cl::opt<bool> NoLink("c",cl::desc("Run all stages except linking."), + cl::cat(StageSelectionCat)); + +The output of ``-help`` will become categorized if an option category is +declared. The output looks something like :: + + OVERVIEW: This is a small program to demo the LLVM CommandLine API + USAGE: Sample [options] + + OPTIONS: + + General options: + + -help - Display available options (-help-hidden for more) + -help-list - Display list of available options (-help-list-hidden for more) + + + Stage Selection Options: + These control which stages are run. + + -E - Run preprocessor stage. + -c - Run all stages except linking. + +In addition to the behaviour of ``-help`` changing when an option category is +declared, the command line option ``-help-list`` becomes visible which will +print the command line options as uncategorized list. + +Note that Options that are not explicitly categorized will be placed in the +``cl::GeneralCategory`` category. + .. _Reference Guide: Reference Guide @@ -943,6 +995,11 @@ This section describes the basic attributes that you can specify on options. of the usual modifiers on multi-valued options (besides ``cl::ValueDisallowed``, obviously). +.. _cl::cat: + +* The **cl::cat** attribute specifies the option category that the option + belongs to. The category should be a `cl::OptionCategory`_ object. + Option Modifiers ---------------- @@ -1212,6 +1269,57 @@ only consists of one function `cl::ParseCommandLineOptions`_) and three main classes: `cl::opt`_, `cl::list`_, and `cl::alias`_. This section describes these three classes in detail. +.. _cl::getRegisteredOptions: + +The ``cl::getRegisteredOptions`` function +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The ``cl::getRegisteredOptions`` function is designed to give a programmer +access to declared non positional command line options so that how they appear +in ``-help`` can be modified prior to calling `cl::ParseCommandLineOptions`_. +Note this method should not be called during any static initialisation because +it cannot be guaranteed that all options will have been initialised. Hence it +should be called from ``main``. + +This function can be used to gain access to options declared in libraries that +the tool writter may not have direct access to. + +The function retrieves a :ref:`StringMap <dss_stringmap>` that maps the option +string (e.g. ``-help``) to an ``Option*``. + +Here is an example of how the function could be used: + +.. code-block:: c++ + + using namespace llvm; + int main(int argc, char **argv) { + cl::OptionCategory AnotherCategory("Some options"); + + StringMap<cl::Option*> Map; + cl::getRegisteredOptions(Map); + + //Unhide useful option and put it in a different category + assert(Map.count("print-all-options") > 0); + Map["print-all-options"]->setHiddenFlag(cl::NotHidden); + Map["print-all-options"]->setCategory(AnotherCategory); + + //Hide an option we don't want to see + assert(Map.count("enable-no-infs-fp-math") > 0); + Map["enable-no-infs-fp-math"]->setHiddenFlag(cl::Hidden); + + //Change --version to --show-version + assert(Map.count("version") > 0); + Map["version"]->setArgStr("show-version"); + + //Change --help description + assert(Map.count("help") > 0); + Map["help"]->setDescription("Shows help"); + + cl::ParseCommandLineOptions(argc, argv, "This is a small program to demo the LLVM CommandLine API"); + ... + } + + .. _cl::ParseCommandLineOptions: The ``cl::ParseCommandLineOptions`` function @@ -1382,6 +1490,29 @@ For example: cl::extrahelp("\nADDITIONAL HELP:\n\n This is the extra help\n"); +.. _cl::OptionCategory: + +The ``cl::OptionCategory`` class +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The ``cl::OptionCategory`` class is a simple class for declaring +option categories. + +.. code-block:: c++ + + namespace cl { + class OptionCategory; + } + +An option category must have a name and optionally a description which are +passed to the constructor as ``const char*``. + +Note that declaring an option category and associating it with an option before +parsing options (e.g. statically) will change the output of ``-help`` from +uncategorized to categorized. If an option category is declared but not +associated with an option then it will be hidden from the output of ``-help`` +but will be shown in the output of ``-help-hidden``. + .. _different parser: .. _discussed previously: diff --git a/docs/CompilerWriterInfo.rst b/docs/CompilerWriterInfo.rst index bc0b99680e..e9a7bc876a 100644 --- a/docs/CompilerWriterInfo.rst +++ b/docs/CompilerWriterInfo.rst @@ -10,8 +10,6 @@ Architecture & Platform Information for Compiler Writers This document is a work-in-progress. Additions and clarifications are welcome. - Compiled by `Misha Brukman <http://misha.brukman.net>`_. - Hardware ======== @@ -22,11 +20,15 @@ ARM * `ABI <http://www.arm.com/products/DevTools/ABI.html>`_ +* `ARM C Language Extensions <http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053a/IHI0053A_acle.pdf>`_ + AArch64 ------- * `ARMv8 Instruction Set Overview <http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.genc010197a/index.html>`_ +* `ARM C Language Extensions <http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053a/IHI0053A_acle.pdf>`_ + Itanium (ia64) -------------- @@ -109,6 +111,12 @@ OS X * `Mach-O Runtime Architecture <http://developer.apple.com/documentation/Darwin/RuntimeArchitecture-date.html>`_ * `Notes on Mach-O ABI <http://www.unsanity.org/archives/000044.php>`_ +NVPTX +===== + +* `CUDA Documentation <http://docs.nvidia.com/cuda/index.html>`_ includes the PTX + ISA and Driver API documentation + Miscellaneous Resources ======================= diff --git a/docs/DeveloperPolicy.rst b/docs/DeveloperPolicy.rst index 43bdc85985..0655559cee 100644 --- a/docs/DeveloperPolicy.rst +++ b/docs/DeveloperPolicy.rst @@ -260,7 +260,7 @@ quality patches. If you would like commit access, please send an email to from, e.g. "J. Random Hacker <hacker@yoyodyne.com>". #. A "password hash" of the password you want to use, e.g. "``2ACR96qjUqsyM``". - Note that you don't ever tell us what your password is, you just give it to + Note that you don't ever tell us what your password is; you just give it to us in an encrypted form. To get this, run "``htpasswd``" (a utility that comes with apache) in crypt mode (often enabled with "``-d``"), or find a web page that will do it for you. @@ -269,17 +269,17 @@ Once you've been granted commit access, you should be able to check out an LLVM tree with an SVN URL of "https://username@llvm.org/..." instead of the normal anonymous URL of "http://llvm.org/...". The first time you commit you'll have to type in your password. Note that you may get a warning from SVN about an -untrusted key, you can ignore this. To verify that your commit access works, +untrusted key; you can ignore this. To verify that your commit access works, please do a test commit (e.g. change a comment or add a blank line). Your first commit to a repository may require the autogenerated email to be approved by a -mailing list. This is normal, and will be done when the mailing list owner has +mailing list. This is normal and will be done when the mailing list owner has time. If you have recently been granted commit access, these policies apply: #. You are granted *commit-after-approval* to all parts of LLVM. To get approval, submit a `patch`_ to `llvm-commits - <http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>`_. When approved + <http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>`_. When approved, you may commit it yourself. #. You are allowed to commit patches without approval which you think are @@ -291,7 +291,7 @@ If you have recently been granted commit access, these policies apply: #. You are allowed to commit patches without approval to those portions of LLVM that you have contributed or maintain (i.e., have been assigned responsibility for), with the proviso that such commits must not break the - build. This is a "trust but verify" policy and commits of this nature are + build. This is a "trust but verify" policy, and commits of this nature are reviewed after they are committed. #. Multiple violations of these policies or a single egregious violation may @@ -300,7 +300,7 @@ If you have recently been granted commit access, these policies apply: In any case, your changes are still subject to `code review`_ (either before or after they are committed, depending on the nature of the change). You are encouraged to review other peoples' patches as well, but you aren't required -to. +to do so. .. _discuss the change/gather consensus: diff --git a/docs/ExtendingLLVM.rst b/docs/ExtendingLLVM.rst index 3d8e9ee79a..3ae676a1b6 100644 --- a/docs/ExtendingLLVM.rst +++ b/docs/ExtendingLLVM.rst @@ -45,7 +45,7 @@ function and then be turned into an instruction if warranted. what the restrictions are. Talk to other people about it so that you are sure it's a good idea. -#. ``llvm/include/llvm/Intrinsics*.td``: +#. ``llvm/include/llvm/IR/Intrinsics*.td``: Add an entry for your intrinsic. Describe its memory access characteristics for optimization (this controls whether it will be DCE'd, CSE'd, etc). Note diff --git a/docs/Extensions.rst b/docs/Extensions.rst new file mode 100644 index 0000000000..062804a9fc --- /dev/null +++ b/docs/Extensions.rst @@ -0,0 +1,39 @@ +=============== +LLVM Extensions +=============== + +.. contents:: + :local: + :depth: 1 + +.. toctree:: + :hidden: + +Introduction +============ + +This document describes extensions to tools and formats LLVM seeks compatibility +with. + +Machine-specific Assembly Syntax +================================ + +X86/COFF-Dependent +------------------ + +The following additional relocation type is supported: + +**@IMGREL** (AT&T syntax only) generates an image-relative relocation that +corresponds to the COFF relocation types ``IMAGE_REL_I386_DIR32NB`` (32-bit) or +``IMAGE_REL_AMD64_ADDR32NB`` (64-bit). + +.. code-block:: gas + + .text + fun: + mov foo@IMGREL(%ebx, %ecx, 4), %eax + + .section .pdata + .long fun@IMGREL + .long (fun@imgrel + 0x3F) + .long $unwind$fun@imgrel diff --git a/docs/GettingStarted.rst b/docs/GettingStarted.rst index 539c75e2d7..6016b53bfc 100644 --- a/docs/GettingStarted.rst +++ b/docs/GettingStarted.rst @@ -229,6 +229,8 @@ uses the package and provides other details. +--------------------------------------------------------------+-----------------+---------------------------------------------+ | `libtool <http://savannah.gnu.org/projects/libtool>`_ | 1.5.22 | Shared library manager\ :sup:`4` | +--------------------------------------------------------------+-----------------+---------------------------------------------+ +| `zlib <http://zlib.net>`_ | >=1.2.3.4 | Compression library\ :sup:`5` | ++--------------------------------------------------------------+-----------------+---------------------------------------------+ .. note:: @@ -243,6 +245,8 @@ uses the package and provides other details. #. If you want to make changes to the configure scripts, you will need GNU autoconf (2.60), and consequently, GNU M4 (version 1.4 or higher). You will also need automake (1.9.6). We only use aclocal from that package. + #. Optional, adds compression/uncompression capabilities to selected LLVM + tools. Additionally, your compilation host is expected to have the usual plethora of Unix utilities. Specifically: @@ -521,13 +525,13 @@ By placing it in the ``llvm/projects``, it will be automatically configured by the LLVM configure script as well as automatically updated when you run ``svn update``. -GIT mirror +Git Mirror ---------- -GIT mirrors are available for a number of LLVM subprojects. These mirrors sync +Git mirrors are available for a number of LLVM subprojects. These mirrors sync automatically with each Subversion commit and contain all necessary git-svn marks (so, you can recreate git-svn metadata locally). Note that right now -mirrors reflect only ``trunk`` for each project. You can do the read-only GIT +mirrors reflect only ``trunk`` for each project. You can do the read-only Git clone of LLVM via: .. code-block:: console @@ -538,10 +542,23 @@ If you want to check out clang too, run: .. code-block:: console - % git clone http://llvm.org/git/llvm.git % cd llvm/tools % git clone http://llvm.org/git/clang.git +If you want to check out compiler-rt too, run: + +.. code-block:: console + + % cd llvm/projects + % git clone http://llvm.org/git/compiler-rt.git + +If you want to check out the Test Suite Source Code (optional), run: + +.. code-block:: console + + % cd llvm/projects + % git clone http://llvm.org/git/test-suite.git + Since the upstream repository is in Subversion, you should use ``git pull --rebase`` instead of ``git pull`` to avoid generating a non-linear history in your clone. To configure ``git pull`` to pass ``--rebase`` by default on the @@ -626,8 +643,10 @@ To set up clone from which you can submit code using ``git-svn``, run: % git config svn-remote.svn.fetch :refs/remotes/origin/master % git svn rebase -l +Likewise for compiler-rt and test-suite. + To update this clone without generating git-svn tags that conflict with the -upstream git repo, run: +upstream Git repo, run: .. code-block:: console @@ -638,39 +657,26 @@ upstream git repo, run: git checkout master && git svn rebase -l) +Likewise for compiler-rt and test-suite. + This leaves your working directories on their master branches, so you'll need to ``checkout`` each working branch individually and ``rebase`` it on top of its parent branch. -For those who wish to be able to update an llvm repo in a simpler fashion, -consider placing the following git script in your path under the name -``git-svnup``: - -.. code-block:: bash - - #!/bin/bash - - STATUS=$(git status -s | grep -v "??") - - if [ ! -z "$STATUS" ]; then - STASH="yes" - git stash >/dev/null - fi - - git fetch - OLD_BRANCH=$(git rev-parse --abbrev-ref HEAD) - git checkout master 2> /dev/null - git svn rebase -l - git checkout $OLD_BRANCH 2> /dev/null +For those who wish to be able to update an llvm repo/revert patches easily using +git-svn, please look in the directory for the scripts ``git-svnup`` and +``git-svnrevert``. - if [ ! -z $STASH ]; then - git stash pop >/dev/null - fi +To perform the aforementioned update steps go into your source directory and +just type ``git-svnup`` or ``git svnup`` and everything will just work. -Then to perform the aforementioned update steps go into your source directory -and just type ``git-svnup`` or ``git svnup`` and everything will just work. +If one wishes to revert a commit with git-svn, but do not want the git hash to +escape into the commit message, one can use the script ``git-svnrevert`` or +``git svnrevert`` which will take in the git hash for the commit you want to +revert, look up the appropriate svn revision, and output a message where all +references to the git hash have been replaced with the svn revision. -To commit back changes via git-svn, use ``dcommit``: +To commit back changes via git-svn, use ``git svn dcommit``: .. code-block:: console @@ -753,7 +759,7 @@ The following options can be used to set or enable LLVM specific options: case. The current set of targets is: ``arm, cpp, hexagon, mblaze, mips, mipsel, msp430, powerpc, ptx, sparc, spu, - x86, x86_64, xcore``. + systemz, x86, x86_64, xcore``. ``--enable-doxygen`` @@ -991,7 +997,7 @@ Optional Configuration Items ---------------------------- If you're running on a Linux system that supports the `binfmt_misc -<http://www.tat.physik.uni-tuebingen.de/~rguenth/linux/binfmt_misc.html>`_ +<http://en.wikipedia.org/wiki/binfmt_misc>`_ module, and you have root access on the system, you can set your system up to execute LLVM bitcode files directly. To do this, use commands like this (the first command may not be required if you are already using the module): diff --git a/docs/GettingStartedVS.rst b/docs/GettingStartedVS.rst index 4c80f2c57b..a80a9e2657 100644 --- a/docs/GettingStartedVS.rst +++ b/docs/GettingStartedVS.rst @@ -137,15 +137,18 @@ Here's the short story for getting up and running quickly with LLVM: .. code-block:: bat - C:\..\llvm> llvm-lit test + C:\..\llvm> python ..\build\bin\llvm-lit --param build_config=Win32 --param build_mode=Debug --param llvm_site_config=../build/test/lit.site.cfg test - Note that quite a few of these test will fail. + This example assumes that Python is in your PATH variable, you + have built a Win32 Debug version of llvm with a standard out of + line build. You should not see any unexpected failures, but will + see many unsupported tests and expected failures. A specific test or test directory can be run with: .. code-block:: bat - C:\..\llvm> llvm-lit test/path/to/test + C:\..\llvm> python ..\build\bin\llvm-lit --param build_config=Win32 --param build_mode=Debug --param llvm_site_config=../build/test/lit.site.cfg test/path/to/test An Example Using the LLVM Tool Chain diff --git a/docs/HowToSetUpLLVMStyleRTTI.rst b/docs/HowToSetUpLLVMStyleRTTI.rst index b906b25621..e0f865a141 100644 --- a/docs/HowToSetUpLLVMStyleRTTI.rst +++ b/docs/HowToSetUpLLVMStyleRTTI.rst @@ -295,6 +295,78 @@ ordering right:: | OtherSpecialSquare | Circle +A Bug to be Aware Of +-------------------- + +The example just given opens the door to bugs where the ``classof``\s are +not updated to match the ``Kind`` enum when adding (or removing) classes to +(from) the hierarchy. + +Continuing the example above, suppose we add a ``SomewhatSpecialSquare`` as +a subclass of ``Square``, and update the ``ShapeKind`` enum like so: + +.. code-block:: c++ + + enum ShapeKind { + SK_Square, + SK_SpecialSquare, + SK_OtherSpecialSquare, + + SK_SomewhatSpecialSquare, + SK_Circle + } + +Now, suppose that we forget to update ``Square::classof()``, so it still +looks like: + +.. code-block:: c++ + + static bool classof(const Shape *S) { + // BUG: Returns false when S->getKind() == SK_SomewhatSpecialSquare, + // even though SomewhatSpecialSquare "is a" Square. + return S->getKind() >= SK_Square && + S->getKind() <= SK_OtherSpecialSquare; + } + +As the comment indicates, this code contains a bug. A straightforward and +non-clever way to avoid this is to introduce an explicit ``SK_LastSquare`` +entry in the enum when adding the first subclass(es). For example, we could +rewrite the example at the beginning of `Concrete Bases and Deeper +Hierarchies`_ as: + +.. code-block:: c++ + + enum ShapeKind { + SK_Square, + + SK_SpecialSquare, + + SK_OtherSpecialSquare, + + SK_LastSquare, + SK_Circle + } + ... + // Square::classof() + - static bool classof(const Shape *S) { + - return S->getKind() == SK_Square; + - } + + static bool classof(const Shape *S) { + + return S->getKind() >= SK_Square && + + S->getKind() <= SK_LastSquare; + + } + +Then, adding new subclasses is easy: + +.. code-block:: c++ + + enum ShapeKind { + SK_Square, + SK_SpecialSquare, + SK_OtherSpecialSquare, + + SK_SomewhatSpecialSquare, + SK_LastSquare, + SK_Circle + } + +Notice that ``Square::classof`` does not need to be changed. + .. _classof-contract: The Contract of ``classof`` diff --git a/docs/LLVMBuild.rst b/docs/LLVMBuild.rst index d9215dd8eb..040b04480e 100644 --- a/docs/LLVMBuild.rst +++ b/docs/LLVMBuild.rst @@ -123,8 +123,8 @@ the file format is below: boolean_property_name = 1 (or 0) LLVMBuild files are expected to define a strict set of sections and -properties. An typical component description file for a library -component would look typically look like the following example: +properties. A typical component description file for a library +component would look like the following example: .. code-block:: ini diff --git a/docs/LangRef.rst b/docs/LangRef.rst index 2c55d333a6..935732a032 100644 --- a/docs/LangRef.rst +++ b/docs/LangRef.rst @@ -127,8 +127,7 @@ lexical features of LLVM: #. Comments are delimited with a '``;``' and go until the end of line. #. Unnamed temporaries are created when the result of a computation is not assigned to a named value. -#. Unnamed temporaries are numbered sequentially (using a per-function - incrementing counter, starting with 0). +#. Unnamed temporaries are numbered sequentially It also shows a convention that we follow in this document. When demonstrating instructions, we will follow an instruction with a comment @@ -387,8 +386,6 @@ More calling conventions can be added/defined on an as-needed basis, to support Pascal conventions or any other well-known target-independent convention. -.. _visibilitystyles: - Visibility Styles ----------------- @@ -414,8 +411,6 @@ styles: defining module will bind to the local symbol. That is, the symbol cannot be overridden by another module. -.. _namedtypes: - Named Types ----------- @@ -568,11 +563,7 @@ A function definition contains a list of basic blocks, forming the CFG start with a label (giving the basic block a symbol table entry), contains a list of instructions, and ends with a :ref:`terminator <terminators>` instruction (such as a branch or function -return). If explicit label is not provided, a block is assigned an -implicit numbered label, using a next value from the same counter as used -for unnamed temporaries (:ref:`see above<identifiers>`). For example, if a -function entry block does not have explicit label, it will be assigned -label "%0", then first unnamed temporary in that block will be "%1", etc. +return). The first basic block in a function is special in two ways: it is immediately executed on entrance to the function, and it is not allowed @@ -600,8 +591,6 @@ Syntax:: [fn Attrs] [section "name"] [align N] [gc] { ... } -.. _langref_aliases: - Aliases ------- @@ -703,7 +692,7 @@ Currently, only the following parameter attributes are defined: the first parameter. This is not a valid attribute for return values. ``noalias`` - This indicates that pointer values :ref:`based <pointeraliasing>` on + This indicates that pointer values `*based* <pointeraliasing>` on the argument or return value do not alias pointer values which are not *based* on it, ignoring certain "irrelevant" dependencies. For a call to the parent function, dependencies between memory references @@ -818,11 +807,6 @@ example: This attribute indicates that the inliner should attempt to inline this function into callers whenever possible, ignoring any active inlining size threshold for this caller. -``cold`` - This attribute indicates that this function is rarely called. When - computing edge weights, basic blocks post-dominated by a cold - function call are also considered to be cold; and, thus, given low - weight. ``nonlazybind`` This attribute suppresses lazy symbol binding for the function. This may make calls to the function faster, at the cost of extra program @@ -976,8 +960,6 @@ two digit hex code for the number. The inline asm code is simply printed to the machine code .s file when assembly code is generated. -.. _langref_datalayout: - Data Layout ----------- @@ -1367,8 +1349,6 @@ transformation. A strong type system makes it easier to read the generated code and enables novel analyses and transformations that are not feasible to perform on normal three address code representations. -.. _typeclassifications: - Type Classifications -------------------- @@ -1882,8 +1862,6 @@ followed by 4 hexadecimal digits. All hexadecimal formats are big-endian There are no constants of type x86mmx. -.. _complexconstants: - Complex Constants ----------------- @@ -2205,8 +2183,6 @@ instruction. Finally, some targets may provide defined semantics when using the value as the operand to an inline assembly, but that is target specific. -.. _constantexprs: - Constant Expressions -------------------- @@ -2311,8 +2287,6 @@ The following is the syntax for constant expressions: Other Values ============ -.. _inlineasmexprs: - Inline Assembler Expressions ---------------------------- @@ -2570,8 +2544,8 @@ Examples: It is sometimes useful to attach information to loop constructs. Currently, loop metadata is implemented as metadata attached to the branch instruction in the loop latch block. This type of metadata refer to a metadata node that is -guaranteed to be separate for each loop. The loop identifier metadata is -specified with the name ``llvm.loop``. +guaranteed to be separate for each loop. The loop-level metadata is prefixed +with ``llvm.loop``. The loop identifier metadata is implemented using a metadata that refers to itself to avoid merging it with any other identifier metadata, e.g., @@ -2585,17 +2559,32 @@ constructs: !0 = metadata !{ metadata !0 } !1 = metadata !{ metadata !1 } -The loop identifier metadata can be used to specify additional per-loop -metadata. Any operands after the first operand can be treated as user-defined -metadata. For example the ``llvm.vectorizer.unroll`` metadata is understood -by the loop vectorizer to indicate how many times to unroll the loop: -.. code-block:: llvm +'``llvm.loop.parallel``' Metadata +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - br i1 %exitcond, label %._crit_edge, label %.lr.ph, !llvm.loop !0 - ... - !0 = metadata !{ metadata !0, metadata !1 } - !1 = metadata !{ metadata !"llvm.vectorizer.unroll", i32 2 } +This loop metadata can be used to communicate that a loop should be considered +a parallel loop. The semantics of parallel loops in this case is the one +with the strongest cross-iteration instruction ordering freedom: the +iterations in the loop can be considered completely independent of each +other (also known as embarrassingly parallel loops). + +This metadata can originate from a programming language with parallel loop +constructs. In such a case it is completely the programmer's responsibility +to ensure the instructions from the different iterations of the loop can be +executed in an arbitrary order, in parallel, or intertwined. No loop-carried +dependency checking at all must be expected from the compiler. + +In order to fulfill the LLVM requirement for metadata to be safely ignored, +it is important to ensure that a parallel loop is converted to +a sequential loop in case an optimization (agnostic of the parallel loop +semantics) converts the loop back to such. This happens when new memory +accesses that do not fulfill the requirement of free ordering across iterations +are added to the loop. Therefore, this metadata is required, but not +sufficient, to consider the loop at hand a parallel loop. For a loop +to be parallel, all its memory accessing instructions need to be +marked with the ``llvm.mem.parallel_loop_access`` metadata that refer +to the same loop identifier metadata that identify the loop at hand. '``llvm.mem``' ^^^^^^^^^^^^^^^ @@ -2607,28 +2596,29 @@ for optimizations are prefixed with ``llvm.mem``. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ For a loop to be parallel, in addition to using -the ``llvm.loop`` metadata to mark the loop latch branch instruction, +the ``llvm.loop.parallel`` metadata to mark the loop latch branch instruction, also all of the memory accessing instructions in the loop body need to be marked with the ``llvm.mem.parallel_loop_access`` metadata. If there is at least one memory accessing instruction not marked with the metadata, -the loop must be considered a sequential loop. This causes parallel loops to be +the loop, despite it possibly using the ``llvm.loop.parallel`` metadata, +must be considered a sequential loop. This causes parallel loops to be converted to sequential loops due to optimization passes that are unaware of the parallel semantics and that insert new memory instructions to the loop body. Example of a loop that is considered parallel due to its correct use of -both ``llvm.loop`` and ``llvm.mem.parallel_loop_access`` +both ``llvm.loop.parallel`` and ``llvm.mem.parallel_loop_access`` metadata types that refer to the same loop identifier metadata. .. code-block:: llvm for.body: - ... - %0 = load i32* %arrayidx, align 4, !llvm.mem.parallel_loop_access !0 - ... - store i32 %0, i32* %arrayidx4, align 4, !llvm.mem.parallel_loop_access !0 - ... - br i1 %exitcond, label %for.end, label %for.body, !llvm.loop !0 + ... + %0 = load i32* %arrayidx, align 4, !llvm.mem.parallel_loop_access !0 + ... + store i32 %0, i32* %arrayidx4, align 4, !llvm.mem.parallel_loop_access !0 + ... + br i1 %exitcond, label %for.end, label %for.body, !llvm.loop.parallel !0 for.end: ... @@ -2644,75 +2634,27 @@ the loop identifier metadata node directly: ... inner.for.body: - ... - %0 = load i32* %arrayidx, align 4, !llvm.mem.parallel_loop_access !0 - ... - store i32 %0, i32* %arrayidx4, align 4, !llvm.mem.parallel_loop_access !0 - ... - br i1 %exitcond, label %inner.for.end, label %inner.for.body, !llvm.loop !1 + ... + %0 = load i32* %arrayidx, align 4, !llvm.mem.parallel_loop_access !0 + ... + store i32 %0, i32* %arrayidx4, align 4, !llvm.mem.parallel_loop_access !0 + ... + br i1 %exitcond, label %inner.for.end, label %inner.for.body, !llvm.loop.parallel !1 inner.for.end: - ... - %0 = load i32* %arrayidx, align 4, !llvm.mem.parallel_loop_access !0 - ... - store i32 %0, i32* %arrayidx4, align 4, !llvm.mem.parallel_loop_access !0 - ... - br i1 %exitcond, label %outer.for.end, label %outer.for.body, !llvm.loop !2 + ... + %0 = load i32* %arrayidx, align 4, !llvm.mem.parallel_loop_access !0 + ... + store i32 %0, i32* %arrayidx4, align 4, !llvm.mem.parallel_loop_access !0 + ... + br i1 %exitcond, label %outer.for.end, label %outer.for.body, !llvm.loop.parallel !2 outer.for.end: ; preds = %for.body ... - !0 = metadata !{ metadata !1, metadata !2 } ; a list of loop identifiers - !1 = metadata !{ metadata !1 } ; an identifier for the inner loop - !2 = metadata !{ metadata !2 } ; an identifier for the outer loop - -'``llvm.vectorizer``' -^^^^^^^^^^^^^^^^^^^^^ - -Metadata prefixed with ``llvm.vectorizer`` is used to control per-loop -vectorization parameters such as vectorization factor and unroll factor. + !0 = metadata !{ metadata !1, metadata !2 } ; a list of parallel loop identifiers + !1 = metadata !{ metadata !1 } ; an identifier for the inner parallel loop + !2 = metadata !{ metadata !2 } ; an identifier for the outer parallel loop -``llvm.vectorizer`` metadata should be used in conjunction with ``llvm.loop`` -loop identification metadata. - -'``llvm.vectorizer.unroll``' Metadata -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -This metadata instructs the loop vectorizer to unroll the specified -loop exactly ``N`` times. - -The first operand is the string ``llvm.vectorizer.unroll`` and the second -operand is an integer specifying the unroll factor. For example: - -.. code-block:: llvm - - !0 = metadata !{ metadata !"llvm.vectorizer.unroll", i32 4 } - -Note that setting ``llvm.vectorizer.unroll`` to 1 disables unrolling of the -loop. - -If ``llvm.vectorizer.unroll`` is set to 0 then the amount of unrolling will be -determined automatically. - -'``llvm.vectorizer.width``' Metadata -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -This metadata sets the target width of the vectorizer to ``N``. Without -this metadata, the vectorizer will choose a width automatically. -Regardless of this metadata, the vectorizer will only vectorize loops if -it believes it is valid to do so. - -The first operand is the string ``llvm.vectorizer.width`` and the second -operand is an integer specifying the width. For example: - -.. code-block:: llvm - - !0 = metadata !{ metadata !"llvm.vectorizer.width", i32 4 } - -Note that setting ``llvm.vectorizer.width`` to 1 disables vectorization of the -loop. - -If ``llvm.vectorizer.width`` is set to 0 then the width will be determined -automatically. Module Flags Metadata ===================== @@ -2914,8 +2856,6 @@ Each individual option is required to be either a valid option for the target's linker, or an option that is reserved by the target specific assembly writer or object file emitter. No other aspect of these options is defined by the IR. -.. _intrinsicglobalvariables: - Intrinsic Global Variables ========================== @@ -2925,15 +2865,13 @@ All globals of this sort should have a section specified as "``llvm.metadata``". This section and all globals that start with "``llvm.``" are reserved for use by LLVM. -.. _gv_llvmused: - The '``llvm.used``' Global Variable ----------------------------------- -The ``@llvm.used`` global is an array which has +The ``@llvm.used`` global is an array with i8\* element type which has :ref:`appending linkage <linkage_appending>`. This array contains a list of -pointers to named global variables, functions and aliases which may optionally -have a pointer cast formed of bitcast or getelementptr. For example, a legal +pointers to global variables and functions which may optionally have a +pointer cast formed of bitcast or getelementptr. For example, a legal use of it is: .. code-block:: llvm @@ -2946,20 +2884,18 @@ use of it is: i8* bitcast (i32* @Y to i8*) ], section "llvm.metadata" -If a symbol appears in the ``@llvm.used`` list, then the compiler, assembler, -and linker are required to treat the symbol as if there is a reference to the -symbol that it cannot see (which is why they have to be named). For example, if -a variable has internal linkage and no references other than that from the -``@llvm.used`` list, it cannot be deleted. This is commonly used to represent -references from inline asms and other things the compiler cannot "see", and -corresponds to "``attribute((used))``" in GNU C. +If a global variable appears in the ``@llvm.used`` list, then the +compiler, assembler, and linker are required to treat the symbol as if +there is a reference to the global that it cannot see. For example, if a +variable has internal linkage and no references other than that from the +``@llvm.used`` list, it cannot be deleted. This is commonly used to +represent references from inline asms and other things the compiler +cannot "see", and corresponds to "``attribute((used))``" in GNU C. On some targets, the code generator must emit a directive to the assembler or object file to prevent the assembler and linker from molesting the symbol. -.. _gv_llvmcompilerused: - The '``llvm.compiler.used``' Global Variable -------------------------------------------- @@ -2972,8 +2908,6 @@ by ``@llvm.used``. This is a rare construct that should only be used in rare circumstances, and should not be exposed to source languages. -.. _gv_llvmglobalctors: - The '``llvm.global_ctors``' Global Variable ------------------------------------------- @@ -2988,8 +2922,6 @@ array will be called in ascending order of priority (i.e. lowest first) when the module is loaded. The order of functions with the same priority is not defined. -.. _llvmglobaldtors: - The '``llvm.global_dtors``' Global Variable ------------------------------------------- @@ -4076,7 +4008,7 @@ Example: <result> = lshr i32 4, 1 ; yields {i32}:result = 2 <result> = lshr i32 4, 2 ; yields {i32}:result = 1 <result> = lshr i8 4, 3 ; yields {i8}:result = 0 - <result> = lshr i8 -2, 1 ; yields {i8}:result = 0x7F + <result> = lshr i8 -2, 1 ; yields {i8}:result = 0x7FFFFFFF <result> = lshr i32 1, 32 ; undefined <result> = lshr <2 x i32> < i32 -2, i32 4>, < i32 1, i32 2> ; yields: result=<2 x i32> < i32 0x7FFFFFFF, i32 1> @@ -6726,9 +6658,6 @@ memory. Implementations are allowed to either return a application specific value or a system wide value. On backends without support, this is lowered to a constant 0. -Note that runtime support may be conditional on the privilege-level code is -running at and the host platform. - Standard C Library Intrinsics ----------------------------- @@ -8685,3 +8614,4 @@ Semantics: This intrinsic does nothing, and it's removed by optimizers and ignored by codegen. +S
\ No newline at end of file diff --git a/docs/NVPTXUsage.rst b/docs/NVPTXUsage.rst new file mode 100644 index 0000000000..5451619686 --- /dev/null +++ b/docs/NVPTXUsage.rst @@ -0,0 +1,276 @@ +============================= +User Guide for NVPTX Back-end +============================= + +.. contents:: + :local: + :depth: 3 + + +Introduction +============ + +To support GPU programming, the NVPTX back-end supports a subset of LLVM IR +along with a defined set of conventions used to represent GPU programming +concepts. This document provides an overview of the general usage of the back- +end, including a description of the conventions used and the set of accepted +LLVM IR. + +.. note:: + + This document assumes a basic familiarity with CUDA and the PTX + assembly language. Information about the CUDA Driver API and the PTX assembly + language can be found in the `CUDA documentation + <http://docs.nvidia.com/cuda/index.html>`_. + + + +Conventions +=========== + +Marking Functions as Kernels +---------------------------- + +In PTX, there are two types of functions: *device functions*, which are only +callable by device code, and *kernel functions*, which are callable by host +code. By default, the back-end will emit device functions. Metadata is used to +declare a function as a kernel function. This metadata is attached to the +``nvvm.annotations`` named metadata object, and has the following format: + +.. code-block:: llvm + + !0 = metadata !{<function-ref>, metadata !"kernel", i32 1} + +The first parameter is a reference to the kernel function. The following +example shows a kernel function calling a device function in LLVM IR. The +function ``@my_kernel`` is callable from host code, but ``@my_fmad`` is not. + +.. code-block:: llvm + + define float @my_fmad(float %x, float %y, float %z) { + %mul = fmul float %x, %y + %add = fadd float %mul, %z + ret float %add + } + + define void @my_kernel(float* %ptr) { + %val = load float* %ptr + %ret = call float @my_fmad(float %val, float %val, float %val) + store float %ret, float* %ptr + ret void + } + + !nvvm.annotations = !{!1} + !1 = metadata !{void (float*)* @my_kernel, metadata !"kernel", i32 1} + +When compiled, the PTX kernel functions are callable by host-side code. + + +Address Spaces +-------------- + +The NVPTX back-end uses the following address space mapping: + + ============= ====================== + Address Space Memory Space + ============= ====================== + 0 Generic + 1 Global + 2 Internal Use + 3 Shared + 4 Constant + 5 Local + ============= ====================== + +Every global variable and pointer type is assigned to one of these address +spaces, with 0 being the default address space. Intrinsics are provided which +can be used to convert pointers between the generic and non-generic address +spaces. + +As an example, the following IR will define an array ``@g`` that resides in +global device memory. + +.. code-block:: llvm + + @g = internal addrspace(1) global [4 x i32] [ i32 0, i32 1, i32 2, i32 3 ] + +LLVM IR functions can read and write to this array, and host-side code can +copy data to it by name with the CUDA Driver API. + +Note that since address space 0 is the generic space, it is illegal to have +global variables in address space 0. Address space 0 is the default address +space in LLVM, so the ``addrspace(N)`` annotation is *required* for global +variables. + + +NVPTX Intrinsics +================ + +Address Space Conversion +------------------------ + +'``llvm.nvvm.ptr.*.to.gen``' Intrinsics +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" + +These are overloaded intrinsics. You can use these on any pointer types. + +.. code-block:: llvm + + declare i8* @llvm.nvvm.ptr.global.to.gen.p0i8.p1i8(i8 addrspace(1)*) + declare i8* @llvm.nvvm.ptr.shared.to.gen.p0i8.p3i8(i8 addrspace(3)*) + declare i8* @llvm.nvvm.ptr.constant.to.gen.p0i8.p4i8(i8 addrspace(4)*) + declare i8* @llvm.nvvm.ptr.local.to.gen.p0i8.p5i8(i8 addrspace(5)*) + +Overview: +""""""""" + +The '``llvm.nvvm.ptr.*.to.gen``' intrinsics convert a pointer in a non-generic +address space to a generic address space pointer. + +Semantics: +"""""""""" + +These intrinsics modify the pointer value to be a valid generic address space +pointer. + + +'``llvm.nvvm.ptr.gen.to.*``' Intrinsics +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" + +These are overloaded intrinsics. You can use these on any pointer types. + +.. code-block:: llvm + + declare i8* @llvm.nvvm.ptr.gen.to.global.p1i8.p0i8(i8 addrspace(1)*) + declare i8* @llvm.nvvm.ptr.gen.to.shared.p3i8.p0i8(i8 addrspace(3)*) + declare i8* @llvm.nvvm.ptr.gen.to.constant.p4i8.p0i8(i8 addrspace(4)*) + declare i8* @llvm.nvvm.ptr.gen.to.local.p5i8.p0i8(i8 addrspace(5)*) + +Overview: +""""""""" + +The '``llvm.nvvm.ptr.gen.to.*``' intrinsics convert a pointer in the generic +address space to a pointer in the target address space. Note that these +intrinsics are only useful if the address space of the target address space of +the pointer is known. It is not legal to use address space conversion +intrinsics to convert a pointer from one non-generic address space to another +non-generic address space. + +Semantics: +"""""""""" + +These intrinsics modify the pointer value to be a valid pointer in the target +non-generic address space. + + +Reading PTX Special Registers +----------------------------- + +'``llvm.nvvm.read.ptx.sreg.*``' +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" + +.. code-block:: llvm + + declare i32 @llvm.nvvm.read.ptx.sreg.tid.x() + declare i32 @llvm.nvvm.read.ptx.sreg.tid.y() + declare i32 @llvm.nvvm.read.ptx.sreg.tid.z() + declare i32 @llvm.nvvm.read.ptx.sreg.ntid.x() + declare i32 @llvm.nvvm.read.ptx.sreg.ntid.y() + declare i32 @llvm.nvvm.read.ptx.sreg.ntid.z() + declare i32 @llvm.nvvm.read.ptx.sreg.ctaid.x() + declare i32 @llvm.nvvm.read.ptx.sreg.ctaid.y() + declare i32 @llvm.nvvm.read.ptx.sreg.ctaid.z() + declare i32 @llvm.nvvm.read.ptx.sreg.nctaid.x() + declare i32 @llvm.nvvm.read.ptx.sreg.nctaid.y() + declare i32 @llvm.nvvm.read.ptx.sreg.nctaid.z() + declare i32 @llvm.nvvm.read.ptx.sreg.warpsize() + +Overview: +""""""""" + +The '``@llvm.nvvm.read.ptx.sreg.*``' intrinsics provide access to the PTX +special registers, in particular the kernel launch bounds. These registers +map in the following way to CUDA builtins: + + ============ ===================================== + CUDA Builtin PTX Special Register Intrinsic + ============ ===================================== + ``threadId`` ``@llvm.nvvm.read.ptx.sreg.tid.*`` + ``blockIdx`` ``@llvm.nvvm.read.ptx.sreg.ctaid.*`` + ``blockDim`` ``@llvm.nvvm.read.ptx.sreg.ntid.*`` + ``gridDim`` ``@llvm.nvvm.read.ptx.sreg.nctaid.*`` + ============ ===================================== + + +Barriers +-------- + +'``llvm.nvvm.barrier0``' +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Syntax: +""""""" + +.. code-block:: llvm + + declare void @llvm.nvvm.barrier0() + +Overview: +""""""""" + +The '``@llvm.nvvm.barrier0()``' intrinsic emits a PTX ``bar.sync 0`` +instruction, equivalent to the ``__syncthreads()`` call in CUDA. + + +Other Intrinsics +---------------- + +For the full set of NVPTX intrinsics, please see the +``include/llvm/IR/IntrinsicsNVVM.td`` file in the LLVM source tree. + + +Executing PTX +============= + +The most common way to execute PTX assembly on a GPU device is to use the CUDA +Driver API. This API is a low-level interface to the GPU driver and allows for +JIT compilation of PTX code to native GPU machine code. + +Initializing the Driver API: + +.. code-block:: c++ + + CUdevice device; + CUcontext context; + + // Initialize the driver API + cuInit(0); + // Get a handle to the first compute device + cuDeviceGet(&device, 0); + // Create a compute device context + cuCtxCreate(&context, 0, device); + +JIT compiling a PTX string to a device binary: + +.. code-block:: c++ + + CUmodule module; + CUfunction funcion; + + // JIT compile a null-terminated PTX string + cuModuleLoadData(&module, (void*)PTXString); + + // Get a handle to the "myfunction" kernel function + cuModuleGetFunction(&function, module, "myfunction"); + +For full examples of executing PTX assembly, please see the `CUDA Samples +<https://developer.nvidia.com/cuda-downloads>`_ distribution. diff --git a/docs/Passes.rst b/docs/Passes.rst index ed72166663..d279eca3af 100644 --- a/docs/Passes.rst +++ b/docs/Passes.rst @@ -34,9 +34,6 @@ LLVM's Analysis and Transform Passes .. contents:: :local: -Written by `Reid Spencer <mailto:rspencer@x10sys.com>`_ - and Gordon Henriksen - Introduction ============ @@ -1021,8 +1018,8 @@ possible, it transforms the individual ``alloca`` instructions into nice clean scalar SSA form. This combines a simple scalar replacement of aggregates algorithm with the -:ref:`mem2reg <passes-mem2reg>` algorithm because often interact, especially -for C++ programs. As such, iterating between ``scalarrepl``, then +:ref:`mem2reg <passes-mem2reg>` algorithm because they often interact, +especially for C++ programs. As such, iterating between ``scalarrepl``, then :ref:`mem2reg <passes-mem2reg>` until we run out of things to promote works well. diff --git a/docs/ProgrammersManual.rst b/docs/ProgrammersManual.rst index 4fc4597933..7864165617 100644 --- a/docs/ProgrammersManual.rst +++ b/docs/ProgrammersManual.rst @@ -626,6 +626,33 @@ SmallVectors are most useful when on the stack. SmallVector also provides a nice portable and efficient replacement for ``alloca``. +.. note:: + + Prefer to use ``SmallVectorImpl<T>`` as a parameter type. + + In APIs that don't care about the "small size" (most?), prefer to use + the ``SmallVectorImpl<T>`` class, which is basically just the "vector + header" (and methods) without the elements allocated after it. Note that + ``SmallVector<T, N>`` inherits from ``SmallVectorImpl<T>`` so the + conversion is implicit and costs nothing. E.g. + + .. code-block:: c++ + + // BAD: Clients cannot pass e.g. SmallVector<Foo, 4>. + hardcodedSmallSize(SmallVector<Foo, 2> &Out); + // GOOD: Clients can pass any SmallVector<Foo, N>. + allowsAnySmallSize(SmallVectorImpl<Foo> &Out); + + void someFunc() { + SmallVector<Foo, 8> Vec; + hardcodedSmallSize(Vec); // Error. + allowsAnySmallSize(Vec); // Works. + } + + Even though it has "``Impl``" in the name, this is so widely used that + it really isn't "private to the implementation" anymore. A name like + ``SmallVectorHeader`` would be more appropriate. + .. _dss_vector: <vector> @@ -989,7 +1016,9 @@ coupled with a good choice of :ref:`sequential container <ds_sequential>`. This combination provides the several nice properties: the result data is contiguous in memory (good for cache locality), has few allocations, is easy to address (iterators in the final vector are just indices or pointers), and can be -efficiently queried with a standard binary or radix search. +efficiently queried with a standard binary search (e.g. +``std::lower_bound``; if you want the whole range of elements comparing +equal, use ``std::equal_range``). .. _dss_smallset: diff --git a/docs/ReleaseNotes.rst b/docs/ReleaseNotes.rst index 9383c5b3fa..73b0abf628 100644 --- a/docs/ReleaseNotes.rst +++ b/docs/ReleaseNotes.rst @@ -5,12 +5,6 @@ LLVM 3.3 Release Notes .. contents:: :local: -.. warning:: - These are in-progress notes for the upcoming LLVM 3.3 release. You may - prefer the `LLVM 3.2 Release Notes <http://llvm.org/releases/3.2/docs - /ReleaseNotes.html>`_. - - Introduction ============ @@ -34,13 +28,6 @@ page <http://llvm.org/releases/>`_. Non-comprehensive list of changes in this release ================================================= -.. NOTE - For small 1-3 sentence descriptions, just add an entry at the end of - this list. If your description won't fit comfortably in one bullet - point (e.g. maybe you would like to give an example of the - functionality, or simply have a lot to talk about), see the `NOTE` below - for adding a new subsection. - * The CellSPU port has been removed. It can still be found in older versions. * The IR-level extended linker APIs (for example, to link bitcode files out of @@ -64,17 +51,21 @@ Non-comprehensive list of changes in this release attributes, which are useful for passing information to code generation. See :doc:`HowToUseAttributes` for more details. -* ... next change ... +* TableGen's syntax for instruction selection patterns has been simplified. + Instead of specifying types indirectly with register classes, you should now + specify types directly in the input patterns. See ``SparcInstrInfo.td`` for + examples of the new syntax. The old syntax using register classes still + works, but it will be removed in a future LLVM release. -.. NOTE - If you would like to document a larger change, then you can add a - subsection about it right here. You can copy the following boilerplate - and un-indent it (the indentation causes it to be inside this comment). +* MCJIT now supports exception handling. Support for it in the old jit will be + removed in the 3.4 release. - Special New Feature - ------------------- +* Command line options can now be grouped into categories which are shown in + the output of ``-help``. See :ref:`grouping options into categories`. - Makes programs 10x faster by doing Special New Thing. +* The appearance of command line options in ``-help`` that are inherited by + linking with libraries that use the LLVM Command line support library can now + be modified at runtime. See :ref:`cl::getRegisteredOptions`. AArch64 target -------------- @@ -90,30 +81,229 @@ in fairly early stages, but we expect successful compilation when: Some additional functionality is also implemented, notably DWARF debugging, GNU-style thread local storage and inline assembly. +Hexagon Target +-------------- + +Removed support for legacy hexagonv2 and hexagonv3 processor architectures which +are no longer in use. Currently supported architectures are hexagonv4 and +hexagonv5. + +Mips target +-------------- + +New features and improvements: + +- Clang driver + - Support for Sourcery CodeBench Mips toolchain directories tree. + - Support for new command line options including: + - -mxgot/-mno-xgot + - -EL / -EB + - -mmicromips / -mno-micromips + - -msingle-float / -mdouble-float + - -mabi=32 (o32 abi) and -mabi=64 (n64 abi) + - Previously, options such as -mips16, -mmicromips, -mdsp and -mdspr2 were + not passed to the assembler. This issue has been fixed. + +- A number of changes have been made to improve the quality of DSP-ASE code + generation. + - Multiply and multiply-accumulate instructions can now use all four + accumulators. + - Instruction selection patterns have been added so that DSP instructions + are emitted without having to use builtins. + +- Delay slot filler pass can now search successor blocks for instructions to + fill delay slots (use option -disable-mips-df-succbb-search=false). + +PowerPC Target +-------------- + +New features and improvements: + +- PowerPC now supports an assembly parser. +- Support added for thread-local storage. 64-bit ELF subtarget only. +- Support added for medium and large code model (-mcmodel=medium,large). + Medium code model is now the default. 64-bit ELF subtarget only. +- Improved register allocation (fewer reserved registers). +- 64-bit atomic load and store are now supported. +- Improved code generation for unaligned memory accesses of scalar types. +- Improved performance of floating-point divide and square root + with -ffast-math. +- Support for predicated returns. +- Improved code generation for comparisons. +- Support added for inline setjmp and longjmp. +- Support added for many instructions introduced in PowerISA 2.04, 2.05, + and 2.06. +- Improved spill code for vector registers. +- Support added for -mno-altivec. +- ABI compatibility fixes for complex parameters, 128-bit integer parameters, + and varargs functions. 64-bit ELF subtarget only. + Loop Vectorizer --------------- We've continued the work on the loop vectorizer. The loop vectorizer now has the following features: -- Loops with unknown trip count. -- Runtime checks of pointers -- Reductions, Inductions -- If Conversion -- Pointer induction variables -- Reverse iterators -- Vectorization of mixed types -- Vectorization of function calls -- Partial unrolling during vectorization +- Loops with unknown trip counts. +- Runtime checks of pointers. +- Reductions, Inductions. +- Min/Max reductions of integers. +- If Conversion. +- Pointer induction variables. +- Reverse iterators. +- Vectorization of mixed types. +- Vectorization of function calls. +- Partial unrolling during vectorization. + +The loop vectorizer is now enabled by default for -O3. + +SLP Vectorizer +-------------- + +LLVM now has a new SLP vectorizer. The new SLP vectorizer is not enabled by +default but can be enabled using the clang flag ``-fslp-vectorize``. The +BB-vectorizer can also be enabled using the command line flag +``-fslp-vectorize-aggressive``. R600 Backend ------------ -The R600 backend was added in this release, it supports AMD GPUs -(HD2XXX - HD7XXX). This backend is used in AMD's Open Source -graphics / compute drivers which are developed as part of the `Mesa3D -<http://www.mesa3d.org>`_ project. +The R600 backend was added in this release, it supports AMD GPUs (HD2XXX - +HD7XXX). This backend is used in AMD's Open Source graphics / compute drivers +which are developed as part of the `Mesa3D <http://www.mesa3d.org>`_ project. + +SystemZ/s390x Backend +--------------------- + +LLVM and clang now support IBM's z/Architecture. At present this support +is restricted to GNU/Linux (GNU triplet s390x-linux-gnu) and requires +z10 or greater. + + +Sub-project Status Update +========================= + +In addition to the core LLVM 3.3 distribution of production-quality compiler +infrastructure, the LLVM project includes sub-projects that use the LLVM core +and share the same distribution license. This section provides updates on these +sub-projects. + + +DragonEgg: GCC front-ends, LLVM back-end +---------------------------------------- + +`DragonEgg <http://dragonegg.llvm.org/>`_ is a +`GCC plugin <http://gcc.gnu.org/wiki/plugins>`_ that replaces GCC's optimizers +and code generators with LLVM's. It works with gcc-4.5, 4.6, 4.7 and 4.8, can +target the x86-32/x86-64 and ARM processor families, and has been successfully +used on the Darwin, FreeBSD, KFreeBSD, Linux and OpenBSD platforms. It fully +supports Ada, C, C++ and Fortran. It has partial support for Go, Java, Obj-C +and Obj-C++. Note that gcc-4.6 is the best supported version, and that Ada in +particular doesn't work well with gcc-4.7 and newer. + +The `3.3 release <http://llvm.org/apt/>`_ has the following notable changes. + +- supports gcc-4.8 (requires gcc-4.8.1 or newer) +- object files can be written directly using LLVM's integrated assembler +- produces saner debug info +- bitfields can now contain arbitrary scalar types (useful for Ada) + + +LLDB: Low Level Debugger +------------------------ + +`LLDB <http://lldb.llvm.org/>`_ is a ground-up implementation of a command-line +debugger, as well as a debugger API that can be used from scripts and other +applications. LLDB uses the following components of the LLVM core distribution +to support the latest language features and target support: + +- the Clang parser for high-quality parsing of C, C++ and Objective C +- the LLVM disassembler +- the LLVM JIT compiler (MCJIT) for expression evaluation + +The `3.3 release <http://lldb.llvm.org/download.html>`_ has the following notable changes. + +Features now supported on Linux: + +- Debugging multi-threaded programs +- Support for watchpoints +- Process list, attach and fork +- `vim integration <http://llvm.org/svn/llvm-project/lldb/branches/release_33/utils/vim-lldb/README>`_ for LLDB + +Portability: + +- Builds with cmake, ninja, auto-tools, clang 3.3 and gcc 4.6 + +Linux Improvements: + +- Improved register support including vector registers +- Basic debugging of i386 programs +- Bug fixes for expression evaluation + + +External Open Source Projects Using LLVM 3.3 +============================================ + +An exciting aspect of LLVM is that it is used as an enabling technology for a +lot of other language and tools projects. This section lists some of the +projects that have already been updated to work with LLVM 3.3. + + +Portable Computing Language (pocl) +---------------------------------- + +In addition to producing an easily portable open source OpenCL implementation, +another major goal of `pocl <http://pocl.sourceforge.net/>`_ is improving +performance portability of OpenCL programs with compiler optimizations, reducing +the need for target-dependent manual optimizations. An important part of pocl is +a set of LLVM passes used to statically parallelize multiple work-items with the +kernel compiler, even in the presence of work-group barriers. This enables +static parallelization of the fine-grained static concurrency in the work groups +in multiple ways. + +TTA-based Co-design Environment (TCE) +------------------------------------- + +`TCE <http://tce.cs.tut.fi/>`_ is a toolset for designing new processors based +on the Transport triggered architecture (TTA). The toolset provides a complete +co-design flow from C/C++ programs down to synthesizable VHDL/Verilog and +parallel program binaries. Processor customization points include the register +files, function units, supported operations, and the interconnection network. + +TCE uses Clang and LLVM for C/C++/OpenCL C language support, target independent +optimizations and also for parts of code generation. It generates new LLVM-based +code generators "on the fly" for the designed TTA processors and loads them in +to the compiler backend as runtime libraries to avoid per-target recompilation +of larger parts of the compiler chain. + +Just-in-time Adaptive Decoder Engine (Jade) +------------------------------------------- + +`Jade <https://github.com/orcc/jade>`_ (Just-in-time Adaptive Decoder Engine) is +a generic video decoder engine using LLVM for just-in-time compilation of video +decoder configurations. Those configurations are designed by MPEG Reconfigurable +Video Coding (RVC) committee. MPEG RVC standard is built on a stream-based +dataflow representation of decoders. It is composed of a standard library of +coding tools written in RVC-CAL language and a dataflow configuration --- block +diagram --- of a decoder. + +Jade project is hosted as part of the Open RVC-CAL Compiler (`Orcc +<http://orcc.sf.net>`_) and requires it to translate the RVC-CAL standard +library of video coding tools into an LLVM assembly code. + +LDC - the LLVM-based D compiler +------------------------------- + +`D <http://dlang.org>`_ is a language with C-like syntax and static typing. It +pragmatically combines efficiency, control, and modeling power, with safety and +programmer productivity. D supports powerful concepts like Compile-Time Function +Execution (CTFE) and Template Meta-Programming, provides an innovative approach +to concurrency and offers many classical paradigms. +`LDC <http://wiki.dlang.org/LDC>`_ uses the frontend from the reference compiler +combined with LLVM as backend to produce efficient native code. LDC targets +x86/x86_64 systems like Linux, OS X and Windows and also Linux/PPC64. Ports to +other architectures like ARM are underway. Additional Information diff --git a/docs/SourceLevelDebugging.rst b/docs/SourceLevelDebugging.rst index 78ce4e0e53..857479508a 100644 --- a/docs/SourceLevelDebugging.rst +++ b/docs/SourceLevelDebugging.rst @@ -1811,11 +1811,11 @@ values, we can clarify the contents of the ``BUCKETS``, ``HASHES`` and | HEADER.header_data_len | uint32_t | HEADER_DATA | HeaderData |-------------------------| - | BUCKETS | uint32_t[bucket_count] // 32 bit hash indexes + | BUCKETS | uint32_t[n_buckets] // 32 bit hash indexes |-------------------------| - | HASHES | uint32_t[hashes_count] // 32 bit hash values + | HASHES | uint32_t[n_hashes] // 32 bit hash values |-------------------------| - | OFFSETS | uint32_t[hashes_count] // 32 bit offsets to hash value data + | OFFSETS | uint32_t[n_hashes] // 32 bit offsets to hash value data |-------------------------| | ALL HASH DATA | `-------------------------' @@ -2080,23 +2080,23 @@ array to be: HeaderData.atoms[0].form = DW_FORM_data4; This defines the contents to be the DIE offset (eAtomTypeDIEOffset) that is - encoded as a 32 bit value (DW_FORM_data4). This allows a single name to have - multiple matching DIEs in a single file, which could come up with an inlined - function for instance. Future tables could include more information about the - DIE such as flags indicating if the DIE is a function, method, block, - or inlined. +encoded as a 32 bit value (DW_FORM_data4). This allows a single name to have +multiple matching DIEs in a single file, which could come up with an inlined +function for instance. Future tables could include more information about the +DIE such as flags indicating if the DIE is a function, method, block, +or inlined. The KeyType for the DWARF table is a 32 bit string table offset into the - ".debug_str" table. The ".debug_str" is the string table for the DWARF which - may already contain copies of all of the strings. This helps make sure, with - help from the compiler, that we reuse the strings between all of the DWARF - sections and keeps the hash table size down. Another benefit to having the - compiler generate all strings as DW_FORM_strp in the debug info, is that - DWARF parsing can be made much faster. +".debug_str" table. The ".debug_str" is the string table for the DWARF which +may already contain copies of all of the strings. This helps make sure, with +help from the compiler, that we reuse the strings between all of the DWARF +sections and keeps the hash table size down. Another benefit to having the +compiler generate all strings as DW_FORM_strp in the debug info, is that +DWARF parsing can be made much faster. After a lookup is made, we get an offset into the hash data. The hash data - needs to be able to deal with 32 bit hash collisions, so the chunk of data - at the offset in the hash data consists of a triple: +needs to be able to deal with 32 bit hash collisions, so the chunk of data +at the offset in the hash data consists of a triple: .. code-block:: c @@ -2105,7 +2105,7 @@ After a lookup is made, we get an offset into the hash data. The hash data HashData[hash_data_count] If "str_offset" is zero, then the bucket contents are done. 99.9% of the - hash data chunks contain a single item (no 32 bit hash collision): +hash data chunks contain a single item (no 32 bit hash collision): .. code-block:: none diff --git a/docs/TableGen/LangRef.rst b/docs/TableGen/LangRef.rst index c9e1efba03..bd28a9031d 100644 --- a/docs/TableGen/LangRef.rst +++ b/docs/TableGen/LangRef.rst @@ -286,7 +286,7 @@ given values. .. productionlist:: SimpleValue: "(" `DagArg` `DagArgList` ")" DagArgList: `DagArg` ("," `DagArg`)* - DagArg: `Value` [":" `TokVarName`] + DagArg: `Value` [":" `TokVarName`] | `TokVarName` The initial :token:`DagArg` is called the "operator" of the dag. diff --git a/docs/TestingGuide.rst b/docs/TestingGuide.rst index 4d8c8ce307..79cedee764 100644 --- a/docs/TestingGuide.rst +++ b/docs/TestingGuide.rst @@ -224,16 +224,7 @@ Below is an example of legal RUN lines in a ``.ll`` file: ; RUN: diff %t1 %t2 As with a Unix shell, the RUN lines permit pipelines and I/O -redirection to be used. However, the usage is slightly different than -for Bash. In general, it's useful to read the code of other tests to figure out -what you can use in yours. The major differences are: - -- You can't do ``2>&1``. That will cause :program:`lit` to write to a file - named ``&1``. Usually this is done to get stderr to go through a pipe. You - can do that with ``|&`` so replace this idiom: - ``... 2>&1 | FileCheck`` with ``... |& FileCheck`` -- You can only redirect to a file, not to another descriptor and not - from a here document. +redirection to be used. There are some quoting rules that you must pay attention to when writing your RUN lines. In general nothing needs to be quoted. :program:`lit` won't @@ -243,7 +234,7 @@ everything enclosed as one value. In general, you should strive to keep your RUN lines as simple as possible, using them only to run tools that generate textual output you can then examine. -The recommended way to examine output to figure out if the test passes it using +The recommended way to examine output to figure out if the test passes is using the :doc:`FileCheck tool <CommandGuide/FileCheck>`. *[The usage of grep in RUN lines is deprecated - please do not send or commit patches that use it.]* diff --git a/docs/Vectorizers.rst b/docs/Vectorizers.rst index 0894b1eb3f..d565c2122c 100644 --- a/docs/Vectorizers.rst +++ b/docs/Vectorizers.rst @@ -6,10 +6,10 @@ Auto-Vectorization in LLVM :local: LLVM has two vectorizers: The :ref:`Loop Vectorizer <loop-vectorizer>`, -which operates on Loops, and the :ref:`Basic Block Vectorizer -<bb-vectorizer>`, which optimizes straight-line code. These vectorizers +which operates on Loops, and the :ref:`SLP Vectorizer +<slp-vectorizer>`, which optimizes straight-line code. These vectorizers focus on different optimization opportunities and use different techniques. -The BB vectorizer merges multiple scalars that are found in the code into +The SLP vectorizer merges multiple scalars that are found in the code into vectors while the Loop Vectorizer widens instructions in the original loop to operate on multiple consecutive loop iterations. @@ -21,19 +21,13 @@ The Loop Vectorizer Usage ----- -LLVM's Loop Vectorizer is now available and will be useful for many people. -It is not enabled by default, but can be enabled through clang using the -command line flag: +LLVM's Loop Vectorizer is now enabled by default for -O3. +We plan to enable parts of the Loop Vectorizer on -O2 and -Os in future releases. +The vectorizer can be disabled using the command line: .. code-block:: console - $ clang -fvectorize -O3 file.c - -If the ``-fvectorize`` flag is used then the loop vectorizer will be enabled -when running with ``-O3``, ``-O2``. When ``-Os`` is used, the loop vectorizer -will only vectorize loops that do not require a major increase in code size. - -We plan to enable the Loop Vectorizer by default as part of the LLVM 3.3 release. + $ clang ... -fno-vectorize file.c Command line flags ^^^^^^^^^^^^^^^^^^ @@ -245,6 +239,17 @@ See the table below for a list of these functions. | | | fmuladd | +-----+-----+---------+ +The loop vectorizer knows about special instructions on the target and will +vectorize a loop containing a function call that maps to the instructions. For +example, the loop below will be vectorized on Intel x86 if the SSE4.1 roundps +instruction is available. + +.. code-block:: c++ + + void foo(float *f) { + for (int i = 0; i != 1024; ++i) + f[i] = floorf(f[i]); + } Partial unrolling during vectorization ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -288,25 +293,15 @@ And Linpack-pc with the same configuration. Result is Mflops, higher is better. .. image:: linpack-pc.png -.. _bb-vectorizer: +.. _slp-vectorizer: -The Basic Block Vectorizer -========================== - -Usage ------- - -The Basic Block Vectorizer is not enabled by default, but it can be enabled -through clang using the command line flag: - -.. code-block:: console - - $ clang -fslp-vectorize file.c +The SLP Vectorizer +================== Details ------- -The goal of basic-block vectorization (a.k.a. superword-level parallelism) is +The goal of SLP vectorization (a.k.a. superword-level parallelism) is to combine similar independent instructions within simple control-flow regions into vector instructions. Memory accesses, arithemetic operations, comparison operations and some math functions can all be vectorized using this technique @@ -318,10 +313,50 @@ into vector operations. .. code-block:: c++ - int foo(int a1, int a2, int b1, int b2) { - int r1 = a1*(a1 + b1)/b1 + 50*b1/a1; - int r2 = a2*(a2 + b2)/b2 + 50*b2/a2; - return r1 + r2; + void foo(int a1, int a2, int b1, int b2, int *A) { + A[0] = a1*(a1 + b1)/b1 + 50*b1/a1; + A[1] = a2*(a2 + b2)/b2 + 50*b2/a2; } +The SLP-vectorizer has two phases, bottom-up, and top-down. The top-down vectorization +phase is more aggressive, but takes more time to run. + +Usage +------ + +The SLP Vectorizer is not enabled by default, but it can be enabled +through clang using the command line flag: + +.. code-block:: console + + $ clang -fslp-vectorize file.c + +LLVM has a second basic block vectorization phase +which is more compile-time intensive (The BB vectorizer). This optimization +can be enabled through clang using the command line flag: + +.. code-block:: console + + $ clang -fslp-vectorize-aggressive file.c + + +The SLP vectorizer is in early development stages but can already vectorize +and accelerate many programs in the LLVM test suite. + +======================= ============ +Benchmark Name Gain +======================= ============ +Misc/flops-7 -32.70% +Misc/matmul_f64_4x4 -23.23% +Olden/power -21.45% +Misc/flops-4 -14.90% +ASC_Sequoia/AMGmk -13.85% +TSVC/LoopRerolling-flt -11.76% +Misc/flops-6 -9.70% +Misc/flops-5 -8.54% +Misc/flops -8.12% +TSVC/NodeSplitting-dbl -6.96% +Misc-C++/sphereflake -6.74% +Ptrdist/yacr2 -6.31% +======================= ============ diff --git a/docs/WritingAnLLVMBackend.rst b/docs/WritingAnLLVMBackend.rst index 6d6c2a1070..a03a5e42c2 100644 --- a/docs/WritingAnLLVMBackend.rst +++ b/docs/WritingAnLLVMBackend.rst @@ -760,7 +760,7 @@ target description file (``IntRegs``). def LDrr : F3_1 <3, 0b000000, (outs IntRegs:$dst), (ins MEMrr:$addr), "ld [$addr], $dst", - [(set IntRegs:$dst, (load ADDRrr:$addr))]>; + [(set i32:$dst, (load ADDRrr:$addr))]>; The fourth parameter is the input source, which uses the address operand ``MEMrr`` that is defined earlier in ``SparcInstrInfo.td``: @@ -788,7 +788,7 @@ class is defined: def LDri : F3_2 <3, 0b000000, (outs IntRegs:$dst), (ins MEMri:$addr), "ld [$addr], $dst", - [(set IntRegs:$dst, (load ADDRri:$addr))]>; + [(set i32:$dst, (load ADDRri:$addr))]>; Writing these definitions for so many similar instructions can involve a lot of cut and paste. In ``.td`` files, the ``multiclass`` directive enables the @@ -803,11 +803,11 @@ pattern ``F3_12`` is defined to create 2 instruction classes each time def rr : F3_1 <2, Op3Val, (outs IntRegs:$dst), (ins IntRegs:$b, IntRegs:$c), !strconcat(OpcStr, " $b, $c, $dst"), - [(set IntRegs:$dst, (OpNode IntRegs:$b, IntRegs:$c))]>; + [(set i32:$dst, (OpNode i32:$b, i32:$c))]>; def ri : F3_2 <2, Op3Val, (outs IntRegs:$dst), (ins IntRegs:$b, i32imm:$c), !strconcat(OpcStr, " $b, $c, $dst"), - [(set IntRegs:$dst, (OpNode IntRegs:$b, simm13:$c))]>; + [(set i32:$dst, (OpNode i32:$b, simm13:$c))]>; } So when the ``defm`` directive is used for the ``XOR`` and ``ADD`` @@ -856,7 +856,7 @@ format instruction having three operands. def XNORrr : F3_1<2, 0b000111, (outs IntRegs:$dst), (ins IntRegs:$b, IntRegs:$c), "xnor $b, $c, $dst", - [(set IntRegs:$dst, (not (xor IntRegs:$b, IntRegs:$c)))]>; + [(set i32:$dst, (not (xor i32:$b, i32:$c)))]>; The instruction templates in ``SparcInstrFormats.td`` show the base class for ``F3_1`` is ``InstSP``. @@ -1124,7 +1124,7 @@ a pattern with the store DAG operator. .. code-block:: llvm def STrr : F3_1< 3, 0b000100, (outs), (ins MEMrr:$addr, IntRegs:$src), - "st $src, [$addr]", [(store IntRegs:$src, ADDRrr:$addr)]>; + "st $src, [$addr]", [(store i32:$src, ADDRrr:$addr)]>; ``ADDRrr`` is a memory mode that is also defined in ``SparcInstrInfo.td``: @@ -1185,7 +1185,7 @@ instruction. SDValue CPTmp0; SDValue CPTmp1; - // Pattern: (st:void IntRegs:i32:$src, + // Pattern: (st:void i32:i32:$src, // ADDRrr:i32:$addr)<<P:Predicate_store>> // Emits: (STrr:void ADDRrr:i32:$addr, IntRegs:i32:$src) // Pattern complexity = 13 cost = 1 size = 0 diff --git a/docs/index.rst b/docs/index.rst index 8f22ef2a77..6b182dac56 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -22,7 +22,6 @@ Several introductory papers and presentations. :hidden: LangRef - GetElementPtr :doc:`LangRef` Defines the LLVM intermediate representation. @@ -48,10 +47,6 @@ Several introductory papers and presentations. .. __: http://llvm.org/pubs/2002-12-LattnerMSThesis.html -:doc:`GetElementPtr` - Answers to some very frequent questions about LLVM's most frequently - misunderstood instruction. - `Publications mentioning LLVM <http://llvm.org/pubs>`_ .. @@ -72,7 +67,6 @@ representation. CMake HowToBuildOnARM CommandGuide/index - DeveloperPolicy GettingStarted GettingStartedVS FAQ @@ -87,6 +81,7 @@ representation. ReleaseNotes Passes YamlIO + GetElementPtr :doc:`GettingStarted` Discusses how to get up and running quickly with the LLVM infrastructure. @@ -108,9 +103,6 @@ representation. Tutorials about using LLVM. Includes a tutorial about making a custom language with LLVM. -:doc:`DeveloperPolicy` - The LLVM project's policy towards developers and their contributions. - :doc:`LLVM Command Guide <CommandGuide/index>` A reference manual for the LLVM command line utilities ("man" pages for LLVM tools). @@ -149,25 +141,9 @@ representation. :doc:`YamlIO` A reference guide for using LLVM's YAML I/O library. -IRC -=== - -Users and developers of the LLVM project (including subprojects such as Clang) -can be found in #llvm on `irc.oftc.net <irc://irc.oftc.net/llvm>`_. - -This channel has several bots. - -* Buildbot reporters - - * llvmbb - Bot for the main LLVM buildbot master. - http://lab.llvm.org:8011/console - * bb-chapuni - An individually run buildbot master. http://bb.pgr.jp/console - * smooshlab - Apple's internal buildbot master. - -* robot - Bugzilla linker. %bug <number> - -* clang-bot - A `geordi <http://www.eelis.net/geordi/>`_ instance running - near-trunk clang instead of gcc. +:doc:`GetElementPtr` + Answers to some very frequent questions about LLVM's most frequently + misunderstood instruction. Programming Documentation ========================= @@ -184,6 +160,7 @@ For developers of applications which use LLVM as a library. ExtendingLLVM HowToSetUpLLVMStyleRTTI ProgrammersManual + Extensions :doc:`LLVM Language Reference Manual <LangRef>` Defines the LLVM intermediate representation and the assembly form of the @@ -196,6 +173,9 @@ For developers of applications which use LLVM as a library. Introduction to the general layout of the LLVM sourcebase, important classes and APIs, and some tips & tricks. +:doc:`Extensions` + LLVM-specific extensions to tools and formats LLVM seeks compatibility with. + :doc:`CommandLine` Provides information on using the command line parsing library. @@ -248,6 +228,7 @@ For API clients and LLVM developers. WritingAnLLVMPass TableGen/LangRef HowToUseAttributes + NVPTXUsage :doc:`WritingAnLLVMPass` Information on how to write LLVM transformations and analyses. @@ -316,6 +297,10 @@ For API clients and LLVM developers. :doc:`HowToUseAttributes` Answers some questions about the new Attributes infrastructure. +:doc:`NVPTXUsage` + This document describes using the NVPTX back-end to compile GPU kernels. + + Development Process Documentation ================================= @@ -324,12 +309,16 @@ Information about LLVM's development process. .. toctree:: :hidden: + DeveloperPolicy MakefileGuide Projects LLVMBuild HowToReleaseLLVM Packaging +:doc:`DeveloperPolicy` + The LLVM project's policy towards developers and their contributions. + :doc:`Projects` How-to guide and templates for new projects that *use* the LLVM infrastructure. The templates (directory organization, Makefiles, and test @@ -349,46 +338,75 @@ Information about LLVM's development process. :doc:`Packaging` Advice on packaging LLVM into a distribution. +Community +========= + +LLVM has a thriving community of friendly and helpful developers. +The two primary communication mechanisms in the LLVM community are mailing +lists and IRC. + Mailing Lists -============= +------------- If you can't find what you need in these docs, try consulting the mailing lists. -`LLVM Announcements List`__ - This is a low volume list that provides important announcements regarding - LLVM. It gets email about once a month. - - .. __: http://lists.cs.uiuc.edu/mailman/listinfo/llvm-announce - -`Developer's List`__ +`Developer's List (llvmdev)`__ This list is for people who want to be included in technical discussions of LLVM. People post to this list when they have questions about writing code for or using the LLVM tools. It is relatively low volume. .. __: http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -`Bugs & Patches Archive`__ - This list gets emailed every time a bug is opened and closed, and when people - submit patches to be included in LLVM. It is higher volume than the LLVMdev - list. - - .. __: http://lists.cs.uiuc.edu/pipermail/llvmbugs/ - -`Commits Archive`__ +`Commits Archive (llvm-commits)`__ This list contains all commit messages that are made when LLVM developers - commit code changes to the repository. It is useful for those who want to - stay on the bleeding edge of LLVM development. This list is very high volume. + commit code changes to the repository. It also serves as a forum for + patch review (i.e. send patches here). It is useful for those who want to + stay on the bleeding edge of LLVM development. This list is very high + volume. .. __: http://lists.cs.uiuc.edu/pipermail/llvm-commits/ -`Test Results Archive`__ +`Bugs & Patches Archive (llvmbugs)`__ + This list gets emailed every time a bug is opened and closed. It is + higher volume than the LLVMdev list. + + .. __: http://lists.cs.uiuc.edu/pipermail/llvmbugs/ + +`Test Results Archive (llvm-testresults)`__ A message is automatically sent to this list by every active nightly tester when it completes. As such, this list gets email several times each day, making it a high volume list. .. __: http://lists.cs.uiuc.edu/pipermail/llvm-testresults/ +`LLVM Announcements List (llvm-announce)`__ + This is a low volume list that provides important announcements regarding + LLVM. It gets email about once a month. + + .. __: http://lists.cs.uiuc.edu/mailman/listinfo/llvm-announce + +IRC +--- + +Users and developers of the LLVM project (including subprojects such as Clang) +can be found in #llvm on `irc.oftc.net <irc://irc.oftc.net/llvm>`_. + +This channel has several bots. + +* Buildbot reporters + + * llvmbb - Bot for the main LLVM buildbot master. + http://lab.llvm.org:8011/console + * bb-chapuni - An individually run buildbot master. http://bb.pgr.jp/console + * smooshlab - Apple's internal buildbot master. + +* robot - Bugzilla linker. %bug <number> + +* clang-bot - A `geordi <http://www.eelis.net/geordi/>`_ instance running + near-trunk clang instead of gcc. + + Indices and tables ================== diff --git a/docs/tutorial/LangImpl1.rst b/docs/tutorial/LangImpl1.rst index eb84e4c923..a2c5eeebf4 100644 --- a/docs/tutorial/LangImpl1.rst +++ b/docs/tutorial/LangImpl1.rst @@ -5,8 +5,6 @@ Kaleidoscope: Tutorial Introduction and the Lexer .. contents:: :local: -Written by `Chris Lattner <mailto:sabre@nondot.org>`_ - Tutorial Introduction ===================== @@ -57,7 +55,7 @@ in the various pieces. The structure of the tutorial is: - Because a lot of people are interested in using LLVM as a JIT, we'll dive right into it and show you the 3 lines it takes to add JIT support. LLVM is also useful in many other ways, but this is one - simple and "sexy" way to shows off its power. :) + simple and "sexy" way to show off its power. :) - `Chapter #5 <LangImpl5.html>`_: Extending the Language: Control Flow - With the language up and running, we show how to extend it with control flow operations (if/then/else and a 'for' loop). This diff --git a/docs/tutorial/LangImpl2.rst b/docs/tutorial/LangImpl2.rst index 0d62894a24..7262afa8f3 100644 --- a/docs/tutorial/LangImpl2.rst +++ b/docs/tutorial/LangImpl2.rst @@ -5,8 +5,6 @@ Kaleidoscope: Implementing a Parser and AST .. contents:: :local: -Written by `Chris Lattner <mailto:sabre@nondot.org>`_ - Chapter 2 Introduction ====================== diff --git a/docs/tutorial/LangImpl3.rst b/docs/tutorial/LangImpl3.rst index 01935a443b..9d5f90839e 100644 --- a/docs/tutorial/LangImpl3.rst +++ b/docs/tutorial/LangImpl3.rst @@ -5,8 +5,6 @@ Kaleidoscope: Code generation to LLVM IR .. contents:: :local: -Written by `Chris Lattner <mailto:sabre@nondot.org>`_ - Chapter 3 Introduction ====================== diff --git a/docs/tutorial/LangImpl4.rst b/docs/tutorial/LangImpl4.rst index 8484c57f9d..96c06d124e 100644 --- a/docs/tutorial/LangImpl4.rst +++ b/docs/tutorial/LangImpl4.rst @@ -5,8 +5,6 @@ Kaleidoscope: Adding JIT and Optimizer Support .. contents:: :local: -Written by `Chris Lattner <mailto:sabre@nondot.org>`_ - Chapter 4 Introduction ====================== diff --git a/docs/tutorial/LangImpl5.rst b/docs/tutorial/LangImpl5.rst index 8405e1a917..80d5f37bc4 100644 --- a/docs/tutorial/LangImpl5.rst +++ b/docs/tutorial/LangImpl5.rst @@ -5,8 +5,6 @@ Kaleidoscope: Extending the Language: Control Flow .. contents:: :local: -Written by `Chris Lattner <mailto:sabre@nondot.org>`_ - Chapter 5 Introduction ====================== diff --git a/docs/tutorial/LangImpl6.rst b/docs/tutorial/LangImpl6.rst index 30f4e90d03..a5a60bffe0 100644 --- a/docs/tutorial/LangImpl6.rst +++ b/docs/tutorial/LangImpl6.rst @@ -5,8 +5,6 @@ Kaleidoscope: Extending the Language: User-defined Operators .. contents:: :local: -Written by `Chris Lattner <mailto:sabre@nondot.org>`_ - Chapter 6 Introduction ====================== diff --git a/docs/tutorial/LangImpl7.rst b/docs/tutorial/LangImpl7.rst index 602dcb5f6f..6dde2fe41d 100644 --- a/docs/tutorial/LangImpl7.rst +++ b/docs/tutorial/LangImpl7.rst @@ -5,8 +5,6 @@ Kaleidoscope: Extending the Language: Mutable Variables .. contents:: :local: -Written by `Chris Lattner <mailto:sabre@nondot.org>`_ - Chapter 7 Introduction ====================== diff --git a/docs/tutorial/LangImpl8.rst b/docs/tutorial/LangImpl8.rst index 4058991f19..3534b2e0c9 100644 --- a/docs/tutorial/LangImpl8.rst +++ b/docs/tutorial/LangImpl8.rst @@ -5,8 +5,6 @@ Kaleidoscope: Conclusion and other useful LLVM tidbits .. contents:: :local: -Written by `Chris Lattner <mailto:sabre@nondot.org>`_ - Tutorial Conclusion =================== diff --git a/docs/tutorial/OCamlLangImpl1.rst b/docs/tutorial/OCamlLangImpl1.rst index daa482507d..94ca3a5aa4 100644 --- a/docs/tutorial/OCamlLangImpl1.rst +++ b/docs/tutorial/OCamlLangImpl1.rst @@ -5,9 +5,6 @@ Kaleidoscope: Tutorial Introduction and the Lexer .. contents:: :local: -Written by `Chris Lattner <mailto:sabre@nondot.org>`_ and `Erick -Tryzelaar <mailto:idadesub@users.sourceforge.net>`_ - Tutorial Introduction ===================== diff --git a/docs/tutorial/OCamlLangImpl2.rst b/docs/tutorial/OCamlLangImpl2.rst index 07490e1f67..83a22ab22d 100644 --- a/docs/tutorial/OCamlLangImpl2.rst +++ b/docs/tutorial/OCamlLangImpl2.rst @@ -5,9 +5,6 @@ Kaleidoscope: Implementing a Parser and AST .. contents:: :local: -Written by `Chris Lattner <mailto:sabre@nondot.org>`_ and `Erick -Tryzelaar <mailto:idadesub@users.sourceforge.net>`_ - Chapter 2 Introduction ====================== diff --git a/docs/tutorial/OCamlLangImpl3.rst b/docs/tutorial/OCamlLangImpl3.rst index d2a47b486c..fd9f0e5cd3 100644 --- a/docs/tutorial/OCamlLangImpl3.rst +++ b/docs/tutorial/OCamlLangImpl3.rst @@ -5,9 +5,6 @@ Kaleidoscope: Code generation to LLVM IR .. contents:: :local: -Written by `Chris Lattner <mailto:sabre@nondot.org>`_ and `Erick -Tryzelaar <mailto:idadesub@users.sourceforge.net>`_ - Chapter 3 Introduction ====================== diff --git a/docs/tutorial/OCamlLangImpl4.rst b/docs/tutorial/OCamlLangImpl4.rst index 865a03dfb7..b13b2afa88 100644 --- a/docs/tutorial/OCamlLangImpl4.rst +++ b/docs/tutorial/OCamlLangImpl4.rst @@ -5,9 +5,6 @@ Kaleidoscope: Adding JIT and Optimizer Support .. contents:: :local: -Written by `Chris Lattner <mailto:sabre@nondot.org>`_ and `Erick -Tryzelaar <mailto:idadesub@users.sourceforge.net>`_ - Chapter 4 Introduction ====================== diff --git a/docs/tutorial/OCamlLangImpl5.rst b/docs/tutorial/OCamlLangImpl5.rst index 203fb6f73b..b8ae3c58dd 100644 --- a/docs/tutorial/OCamlLangImpl5.rst +++ b/docs/tutorial/OCamlLangImpl5.rst @@ -5,9 +5,6 @@ Kaleidoscope: Extending the Language: Control Flow .. contents:: :local: -Written by `Chris Lattner <mailto:sabre@nondot.org>`_ and `Erick -Tryzelaar <mailto:idadesub@users.sourceforge.net>`_ - Chapter 5 Introduction ====================== diff --git a/docs/tutorial/OCamlLangImpl6.rst b/docs/tutorial/OCamlLangImpl6.rst index 7665647736..36bffa8e96 100644 --- a/docs/tutorial/OCamlLangImpl6.rst +++ b/docs/tutorial/OCamlLangImpl6.rst @@ -5,9 +5,6 @@ Kaleidoscope: Extending the Language: User-defined Operators .. contents:: :local: -Written by `Chris Lattner <mailto:sabre@nondot.org>`_ and `Erick -Tryzelaar <mailto:idadesub@users.sourceforge.net>`_ - Chapter 6 Introduction ====================== diff --git a/docs/tutorial/OCamlLangImpl7.rst b/docs/tutorial/OCamlLangImpl7.rst index 07da3a8ff9..cfb49312c5 100644 --- a/docs/tutorial/OCamlLangImpl7.rst +++ b/docs/tutorial/OCamlLangImpl7.rst @@ -5,9 +5,6 @@ Kaleidoscope: Extending the Language: Mutable Variables .. contents:: :local: -Written by `Chris Lattner <mailto:sabre@nondot.org>`_ and `Erick -Tryzelaar <mailto:idadesub@users.sourceforge.net>`_ - Chapter 7 Introduction ====================== diff --git a/docs/tutorial/OCamlLangImpl8.rst b/docs/tutorial/OCamlLangImpl8.rst index 4058991f19..3534b2e0c9 100644 --- a/docs/tutorial/OCamlLangImpl8.rst +++ b/docs/tutorial/OCamlLangImpl8.rst @@ -5,8 +5,6 @@ Kaleidoscope: Conclusion and other useful LLVM tidbits .. contents:: :local: -Written by `Chris Lattner <mailto:sabre@nondot.org>`_ - Tutorial Conclusion =================== |