2012-09-24 Jia Liu <proljc@gmail.com>

       * doc/lto.texi: Separate sections.
       * doc/plugins.texi: Likewise.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@191659 138bc75d-0d04-0410-961f-82ee72b054a4

3 files changed, 60 insertions, 0 deletions

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 8af0732838b..ae9f84c3784 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2012-09-24  Jia Liu  <proljc@gmail.com>
+
+	* doc/lto.texi: Separate sections.
+	* doc/plugins.texi: Likewise.
+
 2012-09-24  Richard Guenther  <rguenther@suse.de>
 
 	PR middle-end/52173
diff --git a/gcc/doc/lto.texi b/gcc/doc/lto.texi
index 68f875935fe..d035a5160c6 100644
--- a/gcc/doc/lto.texi
+++ b/gcc/doc/lto.texi
@@ -12,6 +12,24 @@
 @cindex wpa
 @cindex ltrans
 
+Link Time Optimization (LTO) gives GCC the capability of
+dumping its internal representation (GIMPLE) to disk,
+so that all the different compilation units that make up
+a single executable can be optimized as a single module.
+This expands the scope of inter-procedural optimizations
+to encompass the whole program (or, rather, everything
+that is visible at link time).
+
+@menu
+* LTO Overview::            Overview of LTO.
+* LTO object file layout::  LTO file sections in ELF.
+* IPA::                     Using summary information in IPA passes.
+* WHOPR::                   Whole program assumptions,
+                            linker plugin and symbol visibilities.
+* Internal flags::          Internal flags controlling @code{lto1}.
+@end menu
+
+@node LTO Overview
 @section Design Overview
 
 Link time optimization is implemented as a GCC front end for a
@@ -134,6 +152,7 @@ compilation process.  Additionally, it avoids the need to load the
 whole program into memory.
 
 
+@node LTO object file layout
 @section LTO file sections
 
 LTO information is stored in several ELF sections inside object files.
@@ -246,6 +265,7 @@ format.
 @end itemize
 
 
+@node IPA
 @section Using summary information in IPA passes
 
 Programs are represented internally as a @emph{callgraph} (a
@@ -448,6 +468,7 @@ inter-procedural constant propagation pass and the
 devirtualization pass.  The inliner also uses jump functions to
 perform inlining of callbacks.
 
+@node WHOPR
 @section Whole program assumptions, linker plugin and symbol visibilities
 
 Link-time optimization gives relatively minor benefits when used
@@ -536,6 +557,7 @@ guess based on @option{-fwhole-program}.  Without the linker
 plugin GCC also assumes that symbols are declared @code{hidden}
 and not referred by non-LTO code by default.
 
+@node Internal flags
 @section Internal flags controlling @code{lto1}
 
 The following flags are passed into @command{lto1} and are not
diff --git a/gcc/doc/plugins.texi b/gcc/doc/plugins.texi
index 039c480351f..f072a5f1785 100644
--- a/gcc/doc/plugins.texi
+++ b/gcc/doc/plugins.texi
@@ -7,6 +7,30 @@
 @chapter Plugins
 @cindex Plugins
 
+GCC plugin is a loadable module that provides extra
+features to the compiler, which they can further pass
+around as a shareable module.
+
+GCC plugins provide developers with a rich subset of
+the GCC API to allow them to extend GCC as they see fit.
+Whether it is writing an additional optimization pass,
+transforming code, or analyzing information, plugins
+can be quite useful.
+
+@menu
+* Plugins loading::      How can we load plugins.
+* Plugin API::           The APIs for plugins.
+* Plugins pass::         How a plugin interact with the pass manager.
+* Plugins GC::           How a plugin Interact with GCC Garbage Collector.
+* Plugins description::  Giving information about a plugin itself.
+* Plugins attr::         Registering custom attributes or pragmas.
+* Plugins recording::    Recording information about pass execution.
+* Plugins gate::         Controlling which passes are being run.
+* Plugins tracking::     Keeping track of available passes.
+* Plugins building::     How can we build a plugin.
+@end menu
+
+@node Plugins loading
 @section Loading Plugins
 
 Plugins are supported on platforms that support @option{-ldl
@@ -28,6 +52,7 @@ loaded from the @file{plugin} directory, so @option{-fplugin=@var{name}} is
 the same as @option{-fplugin=`gcc -print-file-name=plugin`/@var{name}.so},
 using backquote shell syntax to query the @file{plugin} directory.
 
+@node Plugin API
 @section Plugin API
 
 Plugins are activated by the compiler at specific events as defined in
@@ -213,6 +238,7 @@ pointer as data from GCC), plugins may register their own pragmas
 using functions like @code{c_register_pragma} or
 @code{c_register_pragma_with_expansion}.
 
+@node Plugins pass
 @section Interacting with the pass manager
 
 There needs to be a way to add/reorder/remove passes dynamically. This
@@ -265,6 +291,7 @@ plugin_init (struct plugin_name_args *plugin_info,
 @end smallexample
 
 
+@node Plugins GC
 @section Interacting with the GCC Garbage Collector
 
 Some plugins may want to be informed when GGC (the GCC Garbage
@@ -295,6 +322,7 @@ before using @code{PLUGIN_GGC_MARKING}, @code{PLUGIN_REGISTER_GGC_ROOTS}
 or @code{PLUGIN_REGISTER_GGC_CACHES}.
 
 
+@node Plugins description
 @section Giving information about a plugin
 
 A plugin should give some information to the user about itself. This
@@ -312,6 +340,7 @@ Such a structure is passed as the @code{user_data} by the plugin's
 init routine using @code{register_callback} with the
 @code{PLUGIN_INFO} pseudo-event and a null callback.
 
+@node Plugins attr
 @section Registering custom attributes or pragmas
 
 For analysis (or other) purposes it is useful to be able to add custom
@@ -369,6 +398,7 @@ It is suggested to pass @code{"GCCPLUGIN"} (or a short name identifying
 your plugin) as the ``space'' argument of your pragma.
 
 
+@node Plugins recording
 @section Recording information about pass execution
 
 The event PLUGIN_PASS_EXECUTION passes the pointer to the executed pass
@@ -383,6 +413,7 @@ and/or @code{PLUGIN_EARLY_GIMPLE_PASSES_END} to manipulate global state
 in your plugin(s) in order to get context for the pass execution.
 
 
+@node Plugins gate
 @section Controlling which passes are being run
 
 After the original gate function for a pass is called, its result
@@ -393,6 +424,7 @@ A nonzero value of the gate status means that the pass is to be executed.
 You can both read and write the gate status via the passed pointer.
 
 
+@node Plugins tracking
 @section Keeping track of available passes
 
 When your plugin is loaded, you can inspect the various
@@ -404,6 +436,7 @@ When a pass is first added to one of the pass lists, the event
 @code{gcc_data} pointing to the new pass.
 
 
+@node Plugins building
 @section Building GCC plugins
 
 If plugins are enabled, GCC installs the headers needed to build a