doc/doxygen: improve doc

doc/doxygen/chapters/api/scheduling_context_hypervisor.doxy

@@ -152,7 +152,8 @@ the others we can pass 0.0)
 \ingroup API_Scheduling_Context_Hypervisor
 Unregister the context from the hypervisor.
 
-@name The user’s input in the resizing process
+@name Users’ Input In The Resizing Process
+\anchor UsersInputInTheResizingProcess
 \ingroup API_Scheduling_Context_Hypervisor
 
 The user can totally forbid the resizing of a certain context or can

doc/doxygen/chapters/c_extensions.doxy

@@ -17,13 +17,13 @@ may need to install a specific <c>-dev</c> package of your distro, such
 as <c>gcc-4.6-plugin-dev</c> on Debian and derivatives.  In addition,
 the plug-in's test suite is only run when <a href="http://www.gnu.org/software/guile/">GNU Guile</a> is found at
 <c>configure</c>-time.  Building the GCC plug-in
-can be disabled by configuring with <c>--disable-gcc-extensions</c>.
+can be disabled by configuring with \ref disable-gcc-extensions.
 
 Those extensions include syntactic sugar for defining
 tasks and their implementations, invoking a task, and manipulating data
 buffers.  Use of these extensions can be made conditional on the
 availability of the plug-in, leading to valid C sequential code when the
-plug-in is not used (\ref Conditional_Extensions).
+plug-in is not used (\ref UsingCExtensionsConditionally).
 
 When StarPU has been installed with its GCC plug-in, programs that use
 these extensions can be compiled this way:
@@ -64,10 +64,10 @@ choose any of its implementations.
 </ul>
 
 Tasks and their implementations must be <em>declared</em>.  These
-declarations are annotated with attributes (@pxref{Attribute
-Syntax, attributes in GNU C,, gcc, Using the GNU Compiler Collection
-(GCC)}): the declaration of a task is a regular C function declaration
-with an additional <c>task</c> attribute, and task implementations are
+declarations are annotated with attributes
+(http://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax):
+the declaration of a task is a regular C function declaration with an
+additional <c>task</c> attribute, and task implementations are
 declared with a <c>task_implementation</c> attribute.
 
 The following function attributes are provided:
@@ -84,17 +84,17 @@ actual definition of a task's body is automatically generated by the
 compiler.
 
 Under the hood, declaring a task leads to the declaration of the
-corresponding <c>codelet</c> (\ref Codelet_and_Tasks).  If one or
+corresponding <c>codelet</c> (\ref CodeletAndTasks).  If one or
 more task implementations are declared in the same compilation unit,
 then the codelet and the function itself are also defined; they inherit
 the scope of the task.
 
 Scalar arguments to the task are passed by value and copied to the
-target device if need be---technically, they are passed as the
-<c>cl_arg</c> buffer (\ref Codelets_and_Tasks).
+target device if need be---technically, they are passed as the buffer
+starpu_task::cl_arg (\ref CodeletAndTasks).
 
 Pointer arguments are assumed to be registered data buffers---the
-buffer argument of a task); <c>const</c>-qualified
+handles argument of a task (starpu_task::handles) ; <c>const</c>-qualified
 pointer arguments are viewed as read-only buffers (::STARPU_R), and
 non-<c>const</c>-qualified buffers are assumed to be used read-write
 (::STARPU_RW).  In addition, the <c>output</c> type attribute can be
@@ -181,7 +181,7 @@ matmul (const float *A, const float *B, __output float *C,
 
 Use of implicit CPU task implementations as above has the advantage that
 the code is valid sequential code when StarPU's GCC plug-in is not used
-(\ref Conditional_Extensions).
+(\ref UsingCExtensionsConditionally).
 
 CUDA and OpenCL implementations can be declared in a similar way:
 
@@ -196,8 +196,8 @@ static void matmul_opencl (const float *A, const float *B, float *C,
 \endcode
 
 The CUDA and OpenCL implementations typically either invoke a kernel
-written in CUDA or OpenCL (for similar code, \ref CUDA_Kernel, and
-\ref OpenCL_Kernel), or call a library function that uses CUDA or
+written in CUDA or OpenCL (for similar code, \ref CUDAKernel, and
+\ref OpenCLKernel), or call a library function that uses CUDA or
 OpenCL under the hood, such as CUBLAS functions:
 
 \code{.c}
@@ -227,7 +227,7 @@ implementation may run in parallel with the continuation of the caller.
 The next section describes how memory buffers must be handled in
 StarPU-GCC code.  For a complete example, see the
 <c>gcc-plugin/examples</c> directory of the source distribution, and
-\ref Vector_Scaling_Using_the_C_Extension.
+\ref VectorScalingUsingTheCExtension.
 
 
 \section InitializationTerminationAndSynchronization Initialization, Termination, and Synchronization
@@ -247,13 +247,13 @@ it provides greater control to user code over its resource usage.
 <dt><c>\#pragma starpu shutdown</c></dt>
 <dd>
 Shut down StarPU, giving it an opportunity to write profiling info to a
-file on disk, for instance (\ref Off-line_performance_feedback).
+file on disk, for instance (\ref Off-linePerformanceFeedback).
 </dd>
 
 <dt><c>\#pragma starpu wait</c></dt>
 <dd>
 Wait for all task invocations to complete, as with
-starpu_wait_for_all().
+starpu_task_wait_for_all().
 </dd>
 </dl>
 
@@ -262,7 +262,7 @@ starpu_wait_for_all().
 Data buffers such as matrices and vectors that are to be passed to tasks
 must be registered.  Registration allows StarPU to handle data
 transfers among devices---e.g., transferring an input buffer from the
-CPU's main memory to a task scheduled to run a GPU (\ref StarPU_Data_Management_Library).
+CPU's main memory to a task scheduled to run a GPU (\ref StarPUDataManagementLibrary).
 
 The following pragmas are provided:
 
@@ -332,14 +332,10 @@ these extensions when they are available---leading to hybrid CPU/GPU
 code---and discard them when they are not available---leading to valid
 sequential code.
 
-To that end, the GCC plug-in defines a C preprocessor macro when it is
-being used:
-
-@defmac STARPU_GCC_PLUGIN
-Defined for code being compiled with the StarPU GCC plug-in.  When
-defined, this macro expands to an integer denoting the version of the
-supported C extensions.
-@end defmac
+To that end, the GCC plug-in defines the C preprocessor macro ---
+<c>STARPU_GCC_PLUGIN</c> --- when it is being used. When defined, this
+macro expands to an integer denoting the version of the supported C
+extensions.
 
 The code below illustrates how to define a task and its implementations
 in a way that allows it to be compiled without the GCC plug-in:

doc/doxygen/chapters/fft_support.doxy

@@ -47,14 +47,14 @@ case, starpufft_cleanup() needs to be called to unregister the data.
 <li>
 To provide data handles (which is preferrable),
 use starpufft_start_handle() (preferred) or
-starpufft_execute_handle(). Several FFTs Several FFT tasks can be submitted
+starpufft_execute_handle(). Several FFTs tasks can be submitted
 for a given plan, which permits e.g. to start a series of FFT with just one
 plan. starpufft_start_handle() is preferrable since it does not wait for
 the task completion, and thus permits to enqueue a series of tasks.
 </li>
 </ul>
 
-All functions are defined in \ref FFT_Support.
+All functions are defined in \ref API_FFT_Support.
 
 \section Compilation Compilation
 

doc/doxygen/chapters/scheduling_context_hypervisor.doxy

@@ -101,7 +101,8 @@ sc_hypervisor_ioctl(sched_ctx,
 
 
 The <b>Idleness</b> based strategy resizes the scheduling contexts every time one of their workers stays idle
-for a period longer than the one imposed by the user (see \ref The_user_input_in_the_resizing_process)
+for a period longer than the one imposed by the user
+(see \ref UsersInputInTheResizingProcess "Users’ Input In The Resizing Process")
 
 \code{.c}
 int workerids[3] = {1, 3, 10};
@@ -123,7 +124,7 @@ The number of flops to be executed by a context are passed as
  (<c>sc_hypervisor_register_ctx(sched_ctx_id, flops)</c>) and the one
  to be executed by each task are passed when the task is submitted.
  The corresponding field is starpu_task::flops and the corresponding
- macro in the function starpu_insert_task() ::STARPU_FLOPS
+ macro in the function starpu_insert_task() is ::STARPU_FLOPS
  (<b>Caution</b>: but take care of passing a double, not an integer,
  otherwise parameter passing will be bogus). When the task is executed
  the resizing process is triggered.

doc/doxygen/chapters/scheduling_contexts.doxy

@@ -26,7 +26,7 @@ disposes of all the computation ressources available to StarPU (all
 the workers). If the application programmer plans to launch several
 parallel kernels simultaneusly, by default these kernels will be
 executed within this initial context, using a single scheduler
-policy(see \ref Task_scheduling_policy). Meanwhile, if the application
+policy(see \ref TaskSchedulingPolicy). Meanwhile, if the application
 programmer is aware of the demands of these kernels and of the
 specificity of the machine used to execute them, the workers can be
 divided between several contexts. These scheduling contexts will