From: Mikhail Glushenkov Date: Tue, 16 Jun 2009 00:14:20 +0000 (+0000) Subject: Regenerate. X-Git-Url: http://plrg.eecs.uci.edu/git/?a=commitdiff_plain;h=502106a713f0e58700065161b2017bb57a6846df;p=oota-llvm.git Regenerate. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73449 91177308-0d34-0410-b5e6-96231b3b80d8 --- diff --git a/docs/CompilerDriver.html b/docs/CompilerDriver.html index 08dc20b6e10..f4391ad92d8 100644 --- a/docs/CompilerDriver.html +++ b/docs/CompilerDriver.html @@ -21,21 +21,22 @@ The ReST source lives in the directory 'tools/llvmc/doc'. -->
  • Compiling with LLVMC
  • Predefined options
  • Compiling LLVMC plugins
    • -
  • Customizing LLVMC: the compilation graph
    • -
  • Describing options
    -

    Actions

    +

    Actions

    A tool often needs to react to command-line options, and this is precisely what the actions property is for. The next example illustrates this feature:

    @@ -515,7 +542,7 @@ Example: (unpack_values
    -

    Language map

    +

    Language map

    If you are adding support for a new language to LLVMC, you'll need to modify the language map, which defines mappings from file extensions to language names. It is used to choose the proper toolchain(s) for a @@ -538,9 +565,9 @@ multiple output languages, for nodes "inside" the graph the input and output languages should match. This is enforced at compile-time.

    -

    More advanced topics

    +

    More advanced topics

    -

    Hooks and environment variables

    +

    Hooks and environment variables

    Normally, LLVMC executes programs from the system PATH. Sometimes, this is not sufficient: for example, we may want to specify tool paths or names in the configuration file. This can be easily achieved via @@ -573,7 +600,7 @@ the case expression (

    -

    How plugins are loaded

    +

    How plugins are loaded

    It is possible for LLVMC plugins to depend on each other. For example, one can create edges between nodes defined in some other plugin. To make this work, however, that plugin should be loaded first. To @@ -589,7 +616,7 @@ with 0. Therefore, the plugin with the highest priority value will be loaded last.

    -

    Debugging

    +

    Debugging

    When writing LLVMC plugins, it can be useful to get a visual view of the resulting compilation graph. This can be achieved via the command line option --view-graph. This command assumes that Graphviz and diff --git a/docs/CompilerDriverTutorial.html b/docs/CompilerDriverTutorial.html index a5780173795..897f9a9f895 100644 --- a/docs/CompilerDriverTutorial.html +++ b/docs/CompilerDriverTutorial.html @@ -50,21 +50,25 @@ command-line LLVMC usage, refer to the Using LLVMC to generate toolchain drivers

    LLVMC plugins are written mostly using TableGen, so you need to be familiar with it to get anything done.

    -

    Start by compiling plugins/Simple/Simple.td, which is a primitive -wrapper for gcc:

    +

    Start by compiling example/Simple, which is a primitive wrapper for +gcc:

     $ cd $LLVM_DIR/tools/llvmc
-$ make DRIVER_NAME=mygcc BUILTIN_PLUGINS=Simple
+
+  # NB: A less verbose way to compile standalone LLVMC-based drivers is
+  # described in the reference manual.
+
+$ make LLVMC_BASED_DRIVER_NAME=mygcc LLVMC_BUILTIN_PLUGINS=Simple
 $ cat > hello.c
 [...]
 $ mygcc hello.c
 $ ./hello.out
 Hello
    -

    Here we link our plugin with the LLVMC core statically to form an -executable file called mygcc. It is also possible to build our -plugin as a standalone dynamic library; this is described in the -reference manual.

    +

    Here we link our plugin with the LLVMC core statically to form an executable +file called mygcc. It is also possible to build our plugin as a dynamic +library to be loaded by the llvmc executable (or any other LLVMC-based +standalone driver); this is described in the reference manual.

    Contents of the file Simple.td look like this:

     // Include common definitions