First commit : 0.14.0 version (with roadmap in doc instead of

[cloog.git] / doc / cloog.texi

\input texinfo
@c %
@c %  /**-----------------------------------------------------------------**
@c %   **                              CLooG                              **
@c %   **-----------------------------------------------------------------**
@c %   **                            cloog.texi                           **
@c %   **-----------------------------------------------------------------**
@c %   **                   First version: july 6th 2002                  **
@c %   **-----------------------------------------------------------------**/
@c %
@c % release 1.0: september 17th 2002
@c % release 1.1: december   5th 2002
@c % release 1.2: april     22th 2003
@c % release 2.0: november  21th 2005 (and now in texinfo instead of LaTeX)
@c %
@c %/**************************************************************************
@c % *               CLooG : the Chunky Loop Generator (experimental)         *
@c % **************************************************************************/
@c %/* CAUTION: the english used is probably the worst you ever read, please
@c % *          feel free to correct and improve it !
@c % */

@c %\textit{"I found the ultimate transformation functions, optimization for
@c %static control programs is now a closed problem, I have \textnormal{just}
@c %to generate the target code !"} 



@c % /*************************************************************************
@c %  *                              PART I: HEADER                           *
@c %  *************************************************************************/
@c %**start of header
@setfilename cloog.info
@settitle CLooG - a loop generator for scanning polyhedra

@set EDITION 2.0
@set VERSION 0.14.0
@set UPDATED November 17th 2005
@setchapternewpage odd

@c %**end of header

@c % /*************************************************************************
@c %  *                 PART II: SUMMARY DESCRIPTION AND COPYRIGHT            *
@c %  *************************************************************************/

@copying
This manual is for CLooG version @value{VERSION}, a software
which generates loops for scanning Z-polyhedra. That is, CLooG produces a
code visiting each integral point of a union of parametrized
polyhedra. CLooG is designed to avoid control overhead and to produce a very
effective code.

It would be quite kind to refer the following paper in any publication that
results from the use of the CLooG software or its library:

@example
@@InProceedings@{Bas04,
@ @ author =@ @ @ @ @{C. Bastoul@},
@ @ title =@ @ @ @ @ @{Code Generation in the Polyhedral Model
@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ Is Easier Than You Think@},
@ @ booktitle = @{PACT'13 IEEE International Conference on
@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ Parallel Architecture and Compilation Techniques@},
@ @ year =@ @ @ @ @ @ 2004,
@ @ pages =@ @ @ @ @ @{7--16@},
@ @ month =@ @ @ @ @ @{september@},
@ @ address =@ @ @ @{Juan-les-Pins@}
@}
@end example

Copyright @copyright{} 2002-2005 C@'edric Bastoul.

@c quotation
Permission is granted to copy, distribute and/or modify this document under
the terms of the GNU Free Documentation License, Version 1.2 
published by the Free Software Foundation. To receive a copy of the
GNU Free Documentation License, write to the Free Software Foundation, Inc.,
59 Temple Place, Suite 330, Boston, MA  02111-1307 USA.
@c end quotation
@end copying

@c % /*************************************************************************
@c %  *                 PART III: TITLEPAGE, CONTENTS, COPYRIGHT              *
@c %  *************************************************************************/
@titlepage
@title CLooG
@subtitle A Loop Generator For Scanning Polyhedra
@subtitle Edition @value{EDITION}, for CLooG @value{VERSION}
@subtitle @value{UPDATED}
@author C@'edric Bastoul
     
@c The following two commands start the copyright page.
@page
@noindent (September 2001)
@table @code
@item C@'edric Bastoul
SCHEDULES GENERATE !!! I just need to apply them now, where can I find
a good code generator ?!
     
@item Paul Feautrier
Hmmm. I fear that if you want something powerful enough, you'll have to
write it yourself !
@end table

@vskip 0pt plus 1filll
@insertcopying
@end titlepage
     
@c Output the table of contents at the beginning.
@contents

@c % /*************************************************************************
@c %  *                     PART IV: TOP NODE AND MASTER MENU                 *
@c %  *************************************************************************/
@ifnottex
@node Top
@top CLooG
     
@insertcopying
@end ifnottex

@menu
* Introduction::
* CLooG Software::
* CLooG Library::
@c * Hacking::
* Installing::
* Documentation::
* References::
@end menu
 


@c % /*************************************************************************
@c %  *                       PART V: BODY OF THE DOCUMENT                    *
@c %  *************************************************************************/

@c %  ****************************** INTRODUCTION ******************************
@node Introduction
@chapter Introduction
CLooG is a free software and library generating loops for scanning Z-polyhedra.
That is, it finds a code (e.g. in C, FORTRAN...) that reaches each integral
point of one or more parameterized polyhedra. CLooG has been originally
written to solve the code generation problem for optimizing compilers based on
the polytope model. Nevertheless it is used now in various area, e.g., to build
control automata for high-level synthesis or to find the best polynomial
approximation of a function. CLooG may help in any situation where scanning
polyhedra matters. It uses the best state-of-the-art code generation
algorithm known as the Quiller@'e et al. algorithm (@pxref{Qui00})
with our own improvements and extensions (@pxref{Bas04}).
The user has full control on generated code quality.
On one hand, generated code size has to be tuned for sake of
readability or instruction cache use. On the other hand, we must ensure that
a bad control management does not hamper performance of the generated code,
for instance by producing redundant guards or complex loop bounds.
CLooG is specially designed to avoid control overhead and to produce a very
efficient code.

CLooG stands for @emph{Chunky Loop Generator}: it is a part of the Chunky
project, a research tool for data locality improvement (@pxref{Bas03a}).
It is designed
also to be the back-end of automatic parallelizers like LooPo (@pxref{Gri04}).
Thus it is very
compilable code oriented and provides powerful program transformation
facilities. Mainly, it allows the user to specify very general schedules where, 
e.g., unimodularity or invertibility of the transformation doesn't matter.

The current version is still under
evaluation, and there is no guarantee that the upward compatibility
will be respected (but the previous API has been stable for two years,
we hope this one will be as successful -and we believe it-).
A lot of reports are necessary to freeze the library
API and the input file shape. Most API changes from 0.12.x to 0.14.x
have been requested by the users themselves.
Thus you are very welcome and encouraged
to post reports on bugs, wishes, critics, comments, suggestions or
successful experiences in the forum of @code{http://www.CLooG.org}
(preferably) or to send them to cedric.bastoul@@inria.fr directly.

@menu
* Basics::
* Scattering::
@end menu

@node Basics
@section Basically, what's the point ?
If you want to use CLooG, this is because you want to scan or to find
something inside the integral points of a set of polyhedra. There are many
reasons for that. Maybe you need the generated code itself because it
actually implements a very smart program transformation you found.
Maybe you want to use the generated code
because you know that the solution of your problem belongs to the integral
points of those damned polyhedra and you don't know which one. Maybe you just
want to know if a polyhedron has integral points depending on some parameters,
which is the lexicographic minimum, maximum, the third on the basis of the
left etc. Probably you have your own reasons to use CLooG.

Let us illustrate a basic use of CLooG. Suppose we have a set of affine
constraints that describes a part of a whatever-dimensional space,
called a @strong{domain}, and we
want to scan it. Let us consider for instance the following set of constraints
where @samp{i}
and @samp{j} are the unknown (the two dimensions of the space) and
@samp{m} and @samp{n} are the parameters (some symbolic constants):
@example
@group
2<=i<=n
2<=j<=m
j<=n+2-i
@end group
@end example
Let us also consider that we have a partial knowledge of the parameter values,
called the @strong{context}, expressed as affine constraints as well,
for instance:
@example
@group
m>=2
n>=2
@end group
@end example
Note that using parameters is optional, if you are not comfortable with
parameter manipulation, just replace them with any scalar value that fits
@code{m>=2} and @code{n>=2}.
A graphical representation of this part of the 2-dimensional space, where
the integral points are represented using heavy dots would be for instance:

@image{./images/basic,6cm}

The affine constraints of both the domain and the context are what we will
provide to CLooG as input (in a particular shape that will be described later).
The output of CLooG is a pseudo-code to scan the integral points of the
input domain according to the context:
@example
@group
for (i=2;i<=n;i++) @{
  for (j=2;j<=min(m,-i+n+2);j++) @{    
    S1(i,j) ;
  @}
@}
@end group
@end example
If you felt such a basic example is yet interesting, there is a good chance
that CLooG is appropriate for you. CLooG can do much more: scanning several
polyhedra or unions of polyhedra at the same time, applying general affine
transformations to the polyhedra, generate compilable code etc. Welcome
to the CLooG's user's guide !

@node Scattering
@section Defining a Scanning Order: Scattering Functions
In CLooG, domains only define the set of integral points to scan and their
coordinates. In particular, CLooG is free to choose the scanning order for
generating the most efficient code. This means, for optimizing/parallelizing
compiler people, that CLooG doesn't make any speculation on dependences on and
between statements (by the way, it's not its job !).
For instance, if an user give to
CLooG only two domains @code{S1:1<=i<=n}, @code{S2:1<=i<=n} and the context
@code{n>=1}, the following pseudo-codes are considered to be equivalent:

@example
@group
/* A convenient target pseudo-code. */
for (i=1;i<=N;i++) @{
 S1(i) ;
@}
for (i=1;i<=N;i++) @{
 S2(i) ;
@}
@end group
@end example

@example
@group
/* Another convenient target pseudo-code. */
for (i=1;i<=N;i++) @{
 S1(i) ;
 S2(i) ;
@}
@end group
@end example

The default behaviour
of CLooG is to generate the second one, since it is optimized in control. 
It is right if there are no data dependences
between @code{S1} and @code{S2}, but wrong otherwise. 

Thus it is often useful to force scanning to respect a given order. This can be
done in CLooG by using @strong{scattering functions}. Scattering is a
shortcut for scheduling, allocation, chunking functions and the like we can
find in the restructuring compilation litterature. There are a lot of reasons
to scatter the integral points of the domains (i.e. the statement instances
of a program, for compilation people), parallelization or optimization are good
examples. For instance, if the user wants for any reason to set some
precedence constraints between the statements of our example above
in order to force the generation of the
first code, he can do it easily by setting (for example) the following
scheduling functions:

@tex
$$\theta _{S1}(i) =  (1)$$
$$\theta _{S2}(j) =  (2)$$
@end tex

@ifnottex
@example
@group
T_S1(i) = (1)
T_S2(j) = (2)
@end group
@end example
@end ifnottex

This scattering means that each integral point of the domain @code{S1}
is scanned at logical date @code{1} while each integral point of the domain
@code{S2} is scanned at logical date @code{2}. As a result, the whole
domain @code{S1} is scanned before domain @code{S2} and the first code in our
example is generated.

The user can set every kind of affine scanning order thanks to the
scattering functions. Each domain has its own scattering function and
each scattering function may be multi-dimensional. A multi-dimentional logical
date may be seen as classical date (year,month,day,hour,minute,etc.) where
the first dimensions are the most significant. Each scattering dimension
may depend linearly on the original dimensions (e.g., @code{i}), the
parameters (e.g., @code{n}) ans scalars (e.g., @code{2}).

A very useful example of multi-dimensional scattering functions is, for
compilation people, the scheduling of the original program.
The basic data to use for code generation are statement iteration domains.
As we saw, these data are not sufficient to rebuild the original
program (what is the ordering between instances of different statements ?).
The missing data can be put in the scattering functions as the original
scheduling. The method to compute it is quite simple (@pxref{Fea92}). The idea is to
build an abstract syntax tree of the program and to read the scheduling for
each statement. For instance, let us consider the following implementation of
a Cholesky factorization:

@example
@group
/* A Cholesky factorization kernel. */
for (i=1;i<=N;i++) @{
  for (j=1;j<=i-1;j++) @{
    a[i][i] -= a[i][j] ;           /* S1 */
  @}
  a[i][i] = sqrt(a[i][i]) ;        /* S2 */
  for (j=i+1;j<=N;j++) @{
    for (k=1;k<=i-1;k++) @{
      a[j][i] -= a[j][k]*a[i][k] ; /* S3 */
    @}
    a[j][i] /= a[i][i] ;           /* S4 */
    @}
  @}
@}
@end group
@end example

The corresponding abstract syntax tree is given in the following figure.
It directly gives the scattering functions (schedules) for all the
statements of the program.

@image{./images/tree,6cm}

@tex
$$
\hbox{$ \cases{ \theta _{S1}(i,j)^T    &$=  (0,i,0,j,0)^T$\cr
                \theta _{S2}(i)        &$=  (0,i,1)^T$\cr
                \theta _{S3}(i,j,k)^T  &$=  (0,i,2,j,0,k,0)^T$\cr
                \theta _{S4}(i,j)^T    &$=  (0,i,2,j,1)^T$}$}
$$
@end tex

@ifnottex
@example
@group
T_S1(i,j)^T   = (0,i,0,j,0)^T
T_S2(i)       = (0,i,1)^T
T_S3(i,j,k)^T = (0,i,2,j,0,k,0)^T
T_S4(i,j)^T   = (0,i,2,j,1)^T
@end group
@end example
@end ifnottex

These schedules depend on the iterators and give for each instance of each
statement a unique execution date. Using such scattering functions allow
CLooG to re-generate the input code. 





@c %  ***********************Using the CLooG Software **************************
@node CLooG Software
@chapter Using the CLooG Software


@menu
* A First Example::
* Writing The Input File::
* Calling CLooG::
* CLooG Options::
* Full Example::
@end menu

@c %/*************************************************************************
@c % *                              A FIRST EXAMPLE                          *
@c % *************************************************************************/
@node A First Example
@section A First Example
CLooG takes as input a file that must be written accordingly to a grammar
described in depth in a further section (@pxref{Writing The Input File}). 
Moreover it supports many options to tune the target code presentation or
quality as discussed in a dedicated section (@pxref{Calling CLooG}).
However, a basic use
of CLooG is not very complex and we present in this section how to generate the
code corresponding to a basic example discussed earlier (@pxref{Basics}).

The problem is to find the code that scans a 2-dimensional polyhedron
where @samp{i} and @samp{j} are the unknown (the two dimensions of the space)
and @samp{m} and @samp{n} are the parameters (the symbolic constants),
defined by the following set of constraints:
@example
@group
2<=i<=n
2<=j<=m
j<=n+2-i
@end group
@end example
@noindent We also consider a partial knowledge of the parameter values,
expressed thanks to the following affine constraints:
@example
@group
m>=2
n>=2
@end group
@end example

An input file that corresponds to this problem, and asks for a generated
code in C, may be the following. Note that we do not describe here precisely
the structure and the components of this file (@pxref{Writing The Input File}
 for such information, if you feel it necessary):

@example
# ---------------------- CONTEXT ----------------------
c # language is C

# Context (constraints on two parameters)
2 4                   # 2 lines and 4 columns
# eq/in m  n  1         eq/in: 1 for inequality >=0, 0 for equality =0
    1   1  0 -2       # 1*m + 0*n -2*1 >= 0, i.e. m>=2
    1   0  1 -2       # 0*m + 1*n -2*1 >= 0, i.e. n>=2

1 # We want to set manually the parameter names
m n                   # parameter names

# --------------------- STATEMENTS --------------------
1 # Number of statements

1 # First statement: one domain
# First domain
5 6                   # 5 lines and 6 columns
# eq/in i  j  m  n  1 
    1   1  0  0  0 -2 # i >= 2
    1  -1  0  0  1  0 # i <= n
    1   0  1  0  0 -2 # j >= 2
    1   0 -1  1  0  0 # j <= m
    1  -1 -1  0  1  2 # n+2-i>=j
0  0  0               # for future options

1 # We want to set manually the iterator names
i j                   # iterator names

# --------------------- SCATTERING --------------------
0 # No scattering functions
@end example

This file may be called @samp{basic.cloog}
(this example is provided in the CLooG distribution as
@code{test/manual_basic.cloog}) and we can ask CLooG to process it
and to generate the code by a simple calling to CLooG with this file as input:
@samp{cloog basic.cloog}. By default, CLooG will print the generated code in
the standard output:

@example
@group
/* Generated by CLooG v@value{VERSION} in 0.00s. */
for (i=2;i<=n;i++) @{
  for (j=2;j<=min(m,-i+n+2);j++) @{    
    S1(i,j) ;
  @}
@}
@end group
@end example

@c %/*************************************************************************
@c % *                                Input file                             *
@c % *************************************************************************/
@node Writing The Input File
@section Writing The Input File
The input text file contains a problem description, i.e. the context,
the domains and the scattering functions.
Because CLooG is very 'compilable code generation oriented', we can associate
some additional informations to each domain. We call this association a
@emph{statement}. The set of all informations is 
called a @emph{program}. The input file respects the grammar below
(terminals are preceeded by "_"):

@example
File             ::= Program
Program          ::= Context Statements Scattering
Context          ::= Language      Domain         Naming
Statements       ::= Nb_statements Statement_list Naming
Scattering       ::= Nb_functions  Domain_list    Naming
Naming           ::= Option Name_list
Name_list        ::= _String   Name_list      | (void)
Statement_list   ::= Statement Statement_list | (void)
Domain_list      ::= _Domain   Domain_list    | (void)
Statement        ::= Iteration_domain 0 0 0
Iteration_domain ::= Domain_union
Domain_union     ::= Nb_domains Domain_list
Option           ::= 0 | 1
Language         ::= c | f
Nb_statements    ::= _Integer
Nb_domains       ::= _Integer
Nb_functions     ::= _Integer
@end example

@itemize @bullet
@item  @samp{Context} represents the informations that are
       shared by all the statements. It consists on
       the language used (which can be @samp{c} for C or @samp{f} for FORTRAN 90)
       and the global constraints on parameters.
       These constraints are essential
       since they give to CLooG the number of parameters. If there is no
       parameter or no constraints on parameters, just give a constraint
       always satisfied like @math{1 \geq 0}. @samp{Naming} sets the parameter
       names.
       If the naming option @samp{Option} is 1, parameter names will be read
       on the next line. There must be exactly as many names as parameters.
       If the naming option @samp{Option} is 0, parameter names are
       automatically generated. The name of the first parameter will
       be @samp{M}, and the name of the @math{(n+1)^{th}} parameter directly
       follows the name of the @math{n^{th}} parameter in ASCII code.
       It is the user responsibility to ensure that parameter names,
       iterators and scattering dimension names are different. 
@item  @samp{Statements} represents the informations on the statements.
       @samp{Nb_statements} is the number of statements in the program, 
       i.e. the number of @samp{Statement} items in the @samp{Statement_list}.
       @samp{Statement} represents the informations on a given statement.
       To each statement is associated a domain
       (the statement iteration domain: @samp{Iteration_domain}) and three
       zeroes that represents future options.
       @samp{Naming} sets the iterator names. If the naming option
       @samp{Option} is 1, the iterator names
       will be read on the next line. There must be exactly as many names as
       nesting level in the deepest iteration domain. If the naming option
       @samp{Option} is 0, iterator names are automatically generated.
       The iterator name of the outermost loop will be @samp{i}, and the
       iterator name of the loop at level @math{n+1} directly follows the 
       iterator name of the loop at level @math{n} in ASCII code. 
@item  @samp{Scattering} represents the informations on scattering functions.
       @samp{Nb_functions} is the number of functions (it must be
       equal to the number of statements or 0 if there is no scattering
       function). The function themselves are represented through
       @samp{Domain_list}.
       @samp{Naming} sets the scattering dimension names. If the naming option
       @samp{Option} is 1, the scattering dimension names will be read on the
       next line.
       There must be exactly as many names as scattering dimensions. If the
       naming option @samp{Option} is 0, scattering dimension names are automatically
       generated. The name of the @math{n^{th}} scattering dimention
       will be @samp{cn}.
@end itemize

@menu
* Domain Representation::
* Scattering Representation::
@end menu

@node Domain Representation
@subsection Domain Representation
As shown by the grammar, the input file describes the various informations
thanks to characters, integers and domains. Each domain is defined by a set of
constraints in the PolyLib format (@pxref{Wil93}). They have the
following syntax:
@enumerate
@item some optional comment lines beginning with @samp{#},
@item the row and column numbers, possibly followed by comments,
@item the constraint rows, each row corresponds to a constraint the
      domain have to satisfy. Each row must be on a single line and is possibly
      followed by comments. The constraint is an equality @math{p(x) = 0} if the
      first element is 0, an inequality  @math{p(x) \geq 0} if the first element
      is 1. The next elements are the unknown coefficients, followed by
      the parameter coefficients. The last element is the constant factor.
@end enumerate
For instance, assuming that @samp{i}, @samp{j} and @samp{k} are iterators and
@samp{m} and @samp{n} are parameters, the domain defined by the following
constraints :

@tex
$$
\hbox{$ \cases{ -i     + m &$\geq 0$\cr
                    -j + n &$\geq 0$\cr
                 i + j - k &$\geq 0$}$}
$$
@end tex

@ifnottex
@example
@group
   -i + m >= 0
   -j + n >= 0
i + j - k >= 0
@end group
@end example
@end ifnottex

@noindent can be written in the input file as follows :

@example
@group
# This is the domain
3 7                      # 3 lines and 7 columns
# eq/in i  j  k  m  n  1 
    1  -1  0  0  1  0  0 #    -i + m >= 0
    1   0 -1  0  0  1  0 #    -j + n >= 0
    1   1  1 -1  0  0  0 # i + j - k >= 0
@end group
@end example

Each iteration domain @samp{Iteration_domain} of a given statement
is a union of polyhedra
@samp{Domain_union}. A union is defined by its number of elements
@samp{Nb_domains} and the elements themselves @samp{Domain_list}.
For instance, let us consider the following pseudo-code:

@example
@group
for (i=1;i<=n;i++) @{
  if ((i >= m) || (i <= 2*m))
    S1 ;
  for (j=i+1;j<=m;j++)
    S2 ;
@} 
@end group
@end example

@noindent The iteration domain of @samp{S1} can be divided into two
polyhedra and written in the input file as follows:

@example
@group
2 # Number of polyhedra in the union
# First domain
3 5                # 3 lines and 5 columns
# eq/in i  m  n  1 
    1   1  0  0 -1 #  i >= 1
    1  -1  0  1  0 #  i <= n
    1   1 -1  0  0 #  i >= m
# Second domain
3 5                # 3 lines and 5 columns
# eq/in i  m  n  1 
    1   1  0  0 -1 #  i >= 1
    1  -1  0  1  0 #  i <= n
    1  -1  2  0  0 #  i <= 2*m
@end group
@end example

@node Scattering Representation
@subsection Scattering Function Representation
Scattering functions are depicted in the input file thanks a representation
very close to the domain one.
An integer gives the number of functions @samp{Nb_functions} and each function
is represented by a domain. Each line of the domain corresponds to an equality
defining a dimension of the function. Note that at present
(CLooG @value{VERSION})
@strong{all functions must have the same scattering dimension number}. If a
user wants to set scattering functions with different dimensionality, he has
to complete the smaller one with zeroes to reach the maximum dimensionality.
For instance, let us consider the following code and
scheduling functions:

@example
@group
for (i=1;i<=n;i++) @{
  if ((i >= m) || (i <= 2*m))
    S1 ;
  for (j=i+1;j<=m;j++)
    S2 ;
@} 
@end group
@end example

@tex
$$
\hbox{$ \cases{ \theta _{S1}(i)      &$=  (i,0)^T$\cr
                \theta _{S2}(i,j)^T  &$=  (n,i+j)^T$}$}
$$
@end tex

@ifnottex
@example
@group
T_S1(i)     = (i,0)^T
T_S2(i,j)^T = (n,i+j)^T
@end group
@end example
@end ifnottex


@noindent This scheduling can be written in the input file as follows:

@example
@group
2 # Number of scattering functions
# First function
2 7                          # 2 lines and 7 columns
# eq/in c1 c2  i  m  n  1 
    0    1  0 -1  0  0  0    #  c1 = i
    0    0  1  0  0  0  0    #  c2 = 0
# Second function
2 8                          # 2 lines and 8 columns
# eq/in c1 c2  i  j  m  n  1 
    0    1  0  0  0  0 -1  0 #  c1 = n
    0    0  1 -1 -1  0  0  0 #  c2 = i+j
@end group
@end example
The complete input file for the user who wants to generate the code for this
example with the preceding scheduling would be
(this file is provided in the CLooG distribution
as @code{test/manual_scattering.cloog}:

@example
# ---------------------- CONTEXT ----------------------
c # language is C

# Context (no constraints on two parameters)
1 4                   # 1 lines and 4 columns
# eq/in m  n  1
    1   0  0  0       # 0 >= 0, always true

1 # We want to set manually the parameter names
m n                   # parameter names

# --------------------- STATEMENTS --------------------
2 # Number of statements

2 # First statement: two domains
# First domain
3 5                   # 3 lines and 5 columns
# eq/in i  m  n  1
    1   1  0  0 -1    # i >= 1
    1  -1  0  1  0    # i <= n
    1   1 -1  0  0    # i >= m
# Second domain
3 5                   # 3 lines and 5 columns
# eq/in i  m  n  1 
    1   1  0  0 -1    # i >= 1
    1  -1  0  1  0    # i <= n
    1  -1  2  0  0    # i <= 2*m
0  0  0               # for future options
 
1 # Second statement: one domain
4 6                   # 4 lines and 6 columns
# eq/in i  j  m  n  1 
    1   1  0  0  0 -1 # i >= 1
    1  -1  0  0  1  0 # i <= n
    1  -1  1  0  0 -1 # j >= i+1
    1   0 -1  1  0  0 # j <= m
0  0  0               # for future options

1 # We want to set manually the iterator names
i j                   # iterator names

# --------------------- SCATTERING --------------------
2 # Scattering functions
# First function
2 7                   # 2 lines and 7 columns
# eq/in p1 p2  i  m  n  1 
    0    1  0 -1  0  0  0    # p1 = i
    0    0  1  0  0  0  0    # p2 = 0
# Second function
2 8                   # 2 lines and 8 columns
# eq/in p1 p2  i  j  m  n  1 
    0    1  0  0  0  0 -1  0 # p1 = n
    0    0  1 -1 -1  0  0  0 # p2 = i+j

1 # We want to set manually the scattering dimension names
p1 p2                 # scattering dimension names
@end example


@c %/*************************************************************************
@c % *                             Calling CLooG                             *
@c % *************************************************************************/
@node Calling CLooG
@section Calling CLooG
CLooG is called by the following command:
@example
       cloog [ options | file ]
@end example
The default behavior of CLooG is to read the input informations from a file and
to print the generated code or pseudo-code on the standard output.
CLooG's behavior and the output code shape is under the user control thanks
to many options which are detailed a further section (@pxref{CLooG Options}).
@code{file} is the input file. @code{stdin} is a special value: when used,
input is standard input. For instance, we can call CLooG to treat the
input file @code{basic.cloog} with default options by typing:
@code{cloog basic.cloog} or @code{more basic.cloog | cloog stdin}.

@c %/*************************************************************************
@c % *                             CLooG Options                             *
@c % *************************************************************************/
@node CLooG Options
@section CLooG Options

@menu
* Last Depth to Optimize Control::
* First Depth to Optimize Control::
* Once Time Loop Elimination::
* Equality Spreading::
* Constant Spreading::
* First Level for Spreading::
* C PreProcessor Friendly::
* Statement Block::
* Loop Strides::
* Compilable Code::
* Output::
* Help::
* Version ::
@end menu

@node Last Depth to Optimize Control
@subsection Last Depth to Optimize Control @code{-l <depth>}

@code{-l <depth>}: this option sets the last loop depth to be optimized in
control. The higher this depth, the less control overhead.
For instance, with some input file, a user can generate
different pseudo-codes with different @code{depth} values as shown below.
@example
@group
/* Generated using a given input file and @strong{option -l 1} */
for (i=0;i<=M;i++) @{
  S1 ;
  for (j=0;j<=N;j++) @{
    S2 ;
  @}
  for (j=0;j<=N;j++) @{
    S3 ;
  @}
  S4 ;
@}
@end group
@end example
@example
@group
/* Generated using the same input file but @strong{option -l 2} */
for (i=0;i<=M;i++) @{
  S1 ;
  for (j=0;j<=N;j++) @{
    S2 ;
    S3 ;
  @}
  S4 ;
@}
@end group
@end example
     In this example we can see that this option can change the operation
     execution order between statements. Let us remind that CLooG does not
     make any speculation on dependences between statements
     (@pxref{Scattering}). Thus if nothing (i.e. scattering functions)
     forbids this, CLooG considers the above codes to be equivalent.
     If there is no scattering functions, the minimum value for @code{depth}
     is 1 (in the case of 0, the user doesn't really need a loop generator !),
     and the number of scattering dimensions otherwise (CLooG will warn the
     user if he doesn't respect such constraint).
     The maximum value for depth is -1 (infinity).
     Default value is infinity.

@node First Depth to Optimize Control
@subsection First Depth to Optimize Control @code{-f <depth>}

     @code{-f <depth>}: this option sets the first loop depth to be optimized
     in control. The lower this depth, the less control overhead (and the longer
     the generated code). For instance, with some input file, a user
     can generate different pseudo-codes with different @code{depth} values
     as shown below.
     The minimum value for @code{depth} is 1, and the
     maximum value is -1 (infinity).
     Default value is 1.
@example
@group
/* Generated using a given input file and @strong{option -f 3} */
for (i=1;i<=N;i++) @{
  for (j=1;j<=M;j++) @{
    S1 ;
    if (j >= 10) @{
      S2 ;
    @}
  @}
@}
@end group
@end example
@example
@group
/* Generated using the same input file but @strong{option -f 2} */
for (i=1;i<=N;i++) @{
  for (j=1;j<=9;j++) @{
    S1 ;
  @}
  for (j=10;j<=M;j++) @{
    S1 ;
    S2 ;
  @}
@}
@end group
@end example


@node Once Time Loop Elimination
@subsection Once Time Loop Elimination @code{-otl <boolean>}

     @code{-otl <boolean>}: this option allows (@code{boolean=1}) or
     forbids (@code{boolean=0}) the simplification of loops running
     once. Default value is 1.
@example
@group
/* Generated using a given input file and @strong{option -otl 0} */
for (j=i+1;j<=i+1;j++) @{
  S1 ;
@}
@end group
@end example
@example
@group
/* Generated using the same input file but @strong{option -otl 1} */
j = i+1 ;
S1 ;
@end group
@end example


@node Equality Spreading 
@subsection Equality Spreading @code{-esp <boolean>}

     @code{-esp <boolean>}: this option allows (@code{boolean=1}) or
     forbids (@code{boolean=0}) values spreading when there
     are equalities. Default value is 0.
@example
@group
/* Generated using a given input file and @strong{option -esp 0} */
i = M+2 ;
j = N ;
for (k=i;k<=j+M;k++) @{
  S1 ;
@}
@end group
@end example
@example
@group
/* Generated using the same input file but @strong{option -esp 1} */
for (k=M+2;k<=N+M;k++) @{
  S1(i = M+2, j = N) ;
@}
@end group
@end example


@node Constant Spreading 
@subsection Constant Spreading @code{-csp <boolean>}

     @code{-csp <boolean>}: this option allows (@code{boolean=1}) or
     forbids (@code{boolean=0}) values spreading when
     there are @emph{constant} equalities. That is, when the right member
     of the equality is a constant term. Default value is 1.
@example
@group
/* Generated using a given input file and @strong{option -csp 0} */
i = M+2 ;
j = N ;
for (k=i;j<=j+M;j++) @{
  S1 ;
@}
@end group
@end example
@example
@group
/* Generated using the same input file but @strong{option -csp 1} */
i = M+2 ;
for (k=i;k<=N+M;k++) @{
  S1(j = N) ;
@}
@end group
@end example


@node First Level for Spreading 
@subsection First Level for Spreading @code{-fsp <level>}

     @code{-fsp <level>}: it can be useful to set a
     first level to begin equality spreading. Particularly when using
     scattering functions, the user may want to see the scattering dimension
     values instead of spreading or hiding them. If user has set a
     spreading, @code{level} is
     the first level to start it. Default value is 1.
@example
@group
/* Generated using a given input file and @strong{option -fsp 1} */
for (j=0;j<=N+M;j++) @{
  S1(i = N) ;
@}
for (j=0;j<=N+M;j++) @{
  S1(i = M) ;
@}
@end group
@end example
@example
@group
/* Generated using the same input file but @strong{option -fsp 2} */
c1 = N ;
for (j=0;j<=c1+M;j++) @{
  S1(i = c1) ;
@}
c1 = M ;
for (j=0;j<=N+c1;j++) @{
  S1(i = c1) ;
@}
@end group
@end example


@node C PreProcessor Friendly 
@subsection C PreProcessor Friendly @code{-cpp <boolean>}

     @code{-cpp <boolean>}: this option ask CLooG for printing a less
     human-readable but compilable code by using the C preprocessor
     (@code{boolean=1}). In this case each statement is written as a
     function of the iterators corresponding to its domain dimensions:
     @code{Si(value_of_iterator_1,...,value_of_iterator_n)}. It follows
     that the user can easily add preprocessor macros to define each
     statement and use the generated textual code directly for compilation.
     When @code{boolean} is set to 0, the pretty printer has the default
     behaviour. Default value is 0.
@example
@group
/* Generated using a given input file and @strong{option -cpp 0} */
for (j=0;j<=N+M;j++) @{
  S1(i = N) ;
@}
@end group
@end example
@example
@group
/* Generated using the same input file but @strong{option -cpp 1} */
/* and a preprocessor macro set by the user */

#define S1(i,j) A[(j)]=3*(i)

for (j=0;j<=N+M;j++) @{
  S1(N,j) ;
@}
@end group
@end example

@node Statement Block  
@subsection Statement Block @code{-block <boolean>}

     @code{-block <boolean>}: this option allows (@code{boolean=1}) to
     create a statement block for each new iterator, even if there is only
     an equality. This can be useful in order to parse the generated
     pseudo-code. When @code{boolean} is set to 0 or when the generation
     language is FORTRAN, this feature is disabled. Default value is 0.
@example
@group
/* Generated using a given input file and @strong{option -block 0} */
i = M+2 ;
j = N ;
S1 ;
@end group
@end example
@example
@group
/* Generated using the same input file but @strong{option -block 1} */
@{ i = M+2 ;
  @{ j = N ;
    S1 ;
  @}
@}
@end group
@end example


@node Loop Strides 
@subsection Loop Strides @code{-strides <boolean>}

     @code{-strides <boolean>}: this options allows (@code{boolean=1}) to
     handle non-unit strides for loop increments. This can remove a lot of
     guards and make the generated code more efficient. Default value is 0.
@example
@group
/* Generated using a given input file and @strong{option -strides 0} */
for (i=1;i<=n;i++) @{
  if (i%2 == 0) @{
    S1(j = i/2) ;
  @}
  if (i%4 == 0) @{
    S2(j = i/4) ;
  @}
@}
@end group
@end example
@example
@group
/* Generated using the same input file but @strong{option -strides 1} */
for (i=2;i<=n;i+=2) @{
  S1(j = i/2) ;
  if (i%4 == 0) @{
    S2(j = i/4) ;
  @}
@}
@end group
@end example

@node Compilable Code
@subsection Compilable Code @code{-compilable <value>}

     @code{-compilable <value>}: this options allows (@code{value} is not 0)
     to generate a compilable code where all parameters have the integral value
     @code{value}. This option creates a macro for each statement. Since
     CLooG do not know anything about the statement sources, it fills the
     macros with a basic increment that computes the total number of
     scanned integral points. The user may change easily the macros according
     to his own needs. This option is possible only if the generated code is
     in C. Default value is 0.
@example
@group
/* Generated using a given input file and @strong{option -compilable 0} */
for (i=0;i<=n;i++) @{
  for (j=0;j<=n;j++) @{
    S1 ;
    S2 ;
  @}
  S3 ;
@}
@end group
@end example
@example
/* Generated using the same input file but @strong{option -compilable 10} */
/* DON'T FORGET TO USE -lm OPTION TO COMPILE. */

/* Useful headers. */
#include <stdio.h>
#include <stdlib.h>
#include <math.h>

/* Parameter value. */
#define PARVAL 10

/* Statement macros (please set). */
#define S1(i,j) @{total++;@}
#define S2(i,j) @{total++;@}
#define S3(i)   @{total++;@}

int main() @{
  /* Original iterators. */
  int i, j ;
  /* Parameters. */
  int n=PARVAL, total=0 ;

  for (i=0;i<=n;i++) @{
    for (j=0;j<=n;j++) @{
      S1(i,j) ;
      S2(i,j) ;
    @}
    S3(i) ;
  @}

  printf("Number of integral points: %d.\n",total) ;
  return 0 ;
@}
@end example

@node Output
@subsection Output @code{-o <output>}

     @code{-o <output>}: this option sets the output file. @code{stdout} is a
     special value: when used, output is standard output.
     Default value is @code{stdout}.

@node Help
@subsection Help @code{--help} or @code{-h}

     @code{--help} or @code{-h}: this option ask CLooG to print a short help.

@node Version
@subsection Version @code{--version} or @code{-v}

     @code{--version} or @code{-v}: this option ask CLooG to print some version
     informations.


@c %/*************************************************************************
@c % *                           A Full Example                              *
@c % *************************************************************************/
@node Full Example
@section A Full Example

Let us consider the allocation problem of a Gaussian elimination, i.e. we want
to distribute the various statement instances of the compute kernel onto
different processors. The original code is the following:
@example
@group
for (i=1;j<=N-1;i++) @{
  for (j=i+1;j<=N;j++) @{
    c[i][j] = a[j][i]/a[i][i] ;    /* S1 */
    for (k=i+1;k<=N;k++) @{
      a[j][k] -= c[i][j]*a[i][k] ; /* S2 */
    @}
  @}
@}
@end group
@end example

@noindent The best affine allocation functions can be found by any good automatic
parallelizer like LooPo (@pxref{Gri04}):

@tex
$$
\hbox{$ \cases{ \theta _{S1}(i,j)^T    &$=  (i)$\cr
                \theta _{S2}(i,j,k)^T  &$=  (k)$}$}
$$
@end tex

@ifnottex
@example
@group
T_S1(i,j)^T   = (i)
T_S2(i,j,k)^T = (k)
@end group
@end example
@end ifnottex

@noindent To ensure that on each processor, the set of statement instances is
executed according to the original ordering, we add as minor scattering
dimensions the original scheduling (@pxref{Scattering}):

@tex
$$
\hbox{$ \cases{ \theta _{S1}(i,j)^T    &$=  (i,0,i,0,j,0)^T$\cr
                \theta _{S2}(i,j,k)^T  &$=  (k,0,i,0,j,1,k,0)^T$}$}
$$
@end tex

@ifnottex
@example
@group
T_S1(i,j)^T   = (i,0,i,0,j,0)^T
T_S2(i,j,k)^T = (k,0,i,0,j,1,k,0)^T
@end group
@end example
@end ifnottex

@noindent To ensure that the scattering functions have the same dimensionality, we
complete the first function with zeroes
(this is a CLooG @value{VERSION} and previous versions requirement,
it should be removed in a future version, don't worry it's absolutly legal !):

@tex
$$
\hbox{$ \cases{ \theta _{S1}(i,j)^T    &$=  (i,0,i,0,j,0,0,0)^T$\cr
                \theta _{S2}(i,j,k)^T  &$=  (k,0,i,0,j,1,k,0)^T$}$}
$$
@end tex

@ifnottex
@example
@group
T_S1(i,j)^T   = (i,0,i,0,j,0,0,0)^T
T_S2(i,j,k)^T = (k,0,i,0,j,1,k,0)^T
@end group
@end example
@end ifnottex

@noindent The input file corresponding to this code generation problem
could be (this file is provided in the CLooG distribution
as @code{test/manual_gauss.cloog}:

@example
# ---------------------- CONTEXT ----------------------
c # language is C

# Context (no constraints on one parameter)
1 3                     # 1 line and 3 columns    
# eq/in n  1
    1   0  0            # 0 >= 0, always true

1 # We want to set manually the parameter name
n                       # parameter name

# --------------------- STATEMENTS --------------------
2 # Number of statements

1 # First statement: one domain
4 5                     # 4 lines and 3 columns
# eq/in i  j  n  1
    1   1  0  0 -1      # i >= 1
    1  -1  0  1 -1      # i <= n-1
    1  -1  1  0 -1      # j >= i+1
    1   0 -1  1  0      # j <= n
0  0  0                 # for future options
 
1
# Second statement: one domain
6 6                     # 6 lines and 3 columns
# eq/in i  j  k  n  1
    1   1  0  0  0 -1   # i >= 1
    1  -1  0  0  1 -1   # i <= n-1
    1  -1  1  0  0 -1   # j >= i+1
    1   0 -1  0  1  0   # j <= n
    1  -1  0  1  0 -1   # k >= i+1
    1   0  0 -1  1  0   # k <= n
0  0  0                 # for future options

0 # We let CLooG set the iterator names

# --------------------- SCATTERING --------------------
2 # Scattering functions
# First function
8 13                    # 3 lines and 3 columns
# eq/in p1 p2 p3 p4 p5 p6 p7 p8  i  j  n  1
    0    1  0  0  0  0  0  0  0 -1  0  0  0     # p1 = i
    0    0  1  0  0  0  0  0  0  0  0  0  0     # p2 = 0
    0    0  0  1  0  0  0  0  0 -1  0  0  0     # p3 = i
    0    0  0  0  1  0  0  0  0  0  0  0  0     # p4 = 0
    0    0  0  0  0  1  0  0  0  0 -1  0  0     # p5 = j
    0    0  0  0  0  0  1  0  0  0  0  0  0     # p6 = 0
    0    0  0  0  0  0  0  1  0  0  0  0  0     # p7 = 0
    0    0  0  0  0  0  0  0  1  0  0  0  0     # p8 = 0
# Second function
8 14                    # 3 lines and 3 columns
# eq/in p1 p2 p3 p4 p5 p6 p7 p8  i  j  k  n  1
    0    1  0  0  0  0  0  0  0  0  0 -1  0  0  # p1 = k
    0    0  1  0  0  0  0  0  0  0  0  0  0  0  # p2 = 0
    0    0  0  1  0  0  0  0  0 -1  0  0  0  0  # p3 = i
    0    0  0  0  1  0  0  0  0  0  0  0  0  0  # p4 = 0
    0    0  0  0  0  1  0  0  0  0 -1  0  0  0  # p5 = j
    0    0  0  0  0  0  1  0  0  0  0  0  0 -1  # p6 = 1
    0    0  0  0  0  0  0  1  0  0  0 -1  0  0  # p7 = k
    0    0  0  0  0  0  0  0  1  0  0  0  0  0  # p8 = 0

1 # We want to set manually the scattering dimension names
p1 p2 p3 p4 p5 p6 p7 p8 # scattering dimension names
@end example

Calling CLooG, with for instance the command line
@code{cloog -fsp 2 gauss.cloog} for a better view
of the allocation (the processor number is given by @code{p1}),
will result on the following target code that actually implements
the transformation. A minor processing on the dimension @code{p1}
to implement, e.g., MPI calls, which is not shown here may
result in dramatic speedups !

@example
if (n >= 2) @{
  p1 = 1 ;
  for (p5=2;p5<=n;p5++) @{
    S1(i = 1,j = p5) ;
  @}
@}
for (p1=2;p1<=n-1;p1++) @{
  for (p3=1;p3<=p1-1;p3++) @{
    for (p5=p3+1;p5<=n;p5++) @{
      S2(i = p3,j = p5,k = p1) ;
    @}
  @}
  for (p5=p1+1;p5<=n;p5++) @{
    S1(i = p1,j = p5) ;
  @}
@}
if (n >= 2) @{
  p1 = n ;
  for (p3=1;p3<=n-1;p3++) @{
    for (p5=p3+1;p5<=n;p5++) @{
      S2(i = p3,j = p5,k = n) ;
    @}
  @}
@}
@end example


@c %/*************************************************************************
@c % *                           A Full Example                              *
@c % *************************************************************************/
@node CLooG Library
@chapter Using the CLooG Library
The CLooG Library was implemented to allow the user to call CLooG
directly from his programs, without file accesses or system calls. The
user only needs to link his programs with C libraries. The CLooG
library mainly provides one function (@code{cloog_program_generate})
which takes as input the problem
description with some options, and returns the data structure corresponding
to the generated code (a @code{CloogProgram} structure) which is more or less
an abstract syntax tree.
The user can work with this data structure and/or use
our pretty printing function to write the final code in either C or FORTRAN.
Some other functions are provided for convenience reasons.
These functions as well as the data structures are described in this section.

@menu
* CLooG Data Structures::
* CLooG Functions::
* Example of Library Utilization::
@end menu


@node CLooG Data Structures
@section CLooG Data Structures Description
In this section, we describe the data structures used by the loop
generator to represent and to process a code generation problem.

@menu
* CloogMatrix::
* CloogDomain::
* CloogDomainList::
* CloogStatement::
* CloogBlock::
* CloogBlockList::
* CloogLoop::
* CloogNames::
* CloogProgram::
* CloogOptions::
@end menu


@node CloogMatrix
@subsection CloogMatrix
@example
@group
#define CloogMatrix Matrix
@end group
@end example

@noindent The @code{CloogMatrix} structure is directly the PolyLib
@code{Matrix} data structure (@pxref{Wil93}). This structure is devoted to
represent a set of constraints. It is 
defined in @code{polylib/types.h} as the following:

@example
@group
struct matrix
@{ unsigned NbRows ;    /* Number of rows. */
  unsigned NbColumns ; /* Number of columns. */
  Value ** p ;         /* Array of pointers to the matrix rows. */
  Value * p_Init ;     /* Matrix rows contiguously in memory. */
  int p_Init_size ;    /* For internal use. */
@}
typedef struct matrix Matrix;
@end group
@end example

@noindent The whole matrix is stored in memory row after row at the
@code{p_Init} address. @code{p} is an array of pointers where
@code{p[i]} points to the first element of the @math{i^{th}} row.
@code{NbRows} and @code{NbColumns} are respectively the number of
rows and columns of the matrix. 
Each row corresponds to a constraint. The first element of each row is an
equality/inequality tag. The
constraint is an equality @math{p(x) = 0} if the first element is 0, but it is
an inequality @math{p(x) \geq 0} if the first element is 1.
The next elements are the unknown coefficients, followed by the parameter
coefficients, then the scalar coefficient.
For instance, the following three constraints:

@tex
$$
\hbox{$ \cases{ -i + m       &$= 0$\cr
                -j + n       &$\geq 0$\cr
                 j + i - k   &$\geq 0$}$}
$$
@end tex

@ifnottex
@example
@group
    -i + m  = 0
    -j + n >= 0
 i + j - k >= 0
@end group
@end example
@end ifnottex

@noindent would be represented by the following rows:

@example
@group
# eq/in  i   j   k   m   n   cst
    0    0  -1   0   1   0    0 
    1   -1   0   0   0   1    0 
    1    1   1  -1   0   0    0 
@end group
@end example

@noindent To be able to provide different precision version (CLooG
supports 32 bits, 64 bits and arbitrary precision through the GMP library),
the @code{Value} type depends on the configuration options (it may be
@code{long int} for 32 bits version, @code{long long int} for 64 bits version,
and @code{mpz_t} for multiple precision version).
The @code{p_Init_size} field is needed by the PolyLib to free
the memory allocated by @code{mpz_init} in the multiple precision release.
Set this field to 0 if you are @emph{not} using multiple precision.
Set this field to the size of the @code{p_Init} array if you
initialized it yourself and if you are using the multiple precision version.


@node CloogDomain
@subsection CloogDomain
@example
@group
struct cloogdomain
@{ Polyhedron * polyhedron ;  /* The polyhedral domain. */
@} ;
typedef struct cloogdomain CloogDomain ;
@end group
@end example

@noindent The @code{CloogDomain} structure contains a PolyLib
@code{Polyhedron} data structure which represents a polyhedral domain
(a union of polyhedra) in both constraint representation and its dual
ray representation (@pxref{Wil93}).
It is defined in @code{polylib/types.h} as the following:

@example
@group
struct polyhedron
@{ unsigned Dimension,        /* Number of dimensions. */
           NbConstraints,    /* Number of constraints. */
           NbRays,           /* Number of rays. */
           NbEq,             /* Number of vertices (?). */
           NbBid ;           /* Number of extremal rays (?). */
  Value ** Constraint ;      /* Pointers to constraints. */
  Value ** Ray ;             /* Pointers to rays. */
  Value * p_Init ;           /* Constraints and rays contiguously. */
  int p_Init_size ;          /* For internal use. */
  struct polyhedron * next ; /* Next component of the union. */
@}
typedef struct polyhedron Polyhedron;
@end group
@end example

@noindent The constraint representation is quite the same as in
the @code{Matrix} data structure (@pxref{CloogMatrix}). The number of
rows is @code{NbConstraints} and the
number of columns in the @code{Polyhedron} structure is
@code{Dimension+2} (the @math{+2} comes from the equality/inequality
tag and the scalar coefficient). As in the @code{Matrix} structure,
The data are stored in memory contiguously at the
@code{p_Init} address and the @code{p_Init_size} field is used for
memory deallocation in the multiple precision case (@pxref{CloogMatrix}).
For a better understanding of the
dual ray representation, the user may refer to the PolyLib documentation.


@node CloogDomainList
@subsection CloogDomainList
@example
@group
struct cloogdomainlist
@{ CloogDomain * domain ;
  struct cloogdomainlist * next ;
@} ;
typedef struct cloogdomainlist CloogDomainList ;
@end group
@end example

@noindent The CloogDomainList structure represents a @code{NULL} terminated linked list
of domains.


@node CloogStatement
@subsection CloogStatement
@example
@group
struct cloogstatement
@{ int number ;                  /* The statement unique number. */
  void * usr ;                  /* Pointer for user's convenience. */
  struct cloogstatement * next ;/* Next element of the linked list. */
@} ;
typedef struct cloogstatement CloogStatement ;
@end group
@end example

@noindent The @code{CloogStatement} structure represents a @code{NULL}
terminated linked
list of statements. In CLooG, a statement is only defined by its unique
number (@code{number}). The user can use the pointer @code{usr} for his
own convenience to link his own statement representation to the
corresponding @code{CloogStatement} structure. The whole management of the
@code{usr} pointer is under the responsibility of the user, in particular,
CLooG never tries to print, to allocate or to free a memory block pointed
by @code{usr}. 


@node CloogBlock
@subsection CloogBlock
@example
@group
struct cloogblock
@{ CloogStatement * statement ; /* Statement list of the block. */
  CloogMatrix * scattering ;   /* Scattering function of the block. */
  int depth ;                  /* Original block depth.*/
@} ;
typedef struct cloogblock CloogBlock ;
@end group
@end example

@noindent The @code{CloogBlock} structure represents a statement block.
In a statement block, every statements have the same iteration
domain and the same scattering function (actually, the scattering
functions may differ only by a scalar
coefficient if it just precises the ordering of the statements within
the block). @code{statement} is the statement list where the
statement order matters, @code{scattering} is one of
the statement scattering functions and
@code{depth} is the number of dimensions of the
iteration domain (only the unknown, not the tag/parameters/scalar).


@node CloogBlockList
@subsection CloogBlockList
@example
@group
struct cloogdblocklist
@{ CloogBlock * block ;
  struct cloogblocklist * next ;
@} ;
typedef struct cloogblocklist CloogBlockList ;
@end group
@end example

@noindent The CloogBlockList structure represents a @code{NULL} terminated linked list
of blocks.


@node CloogLoop
@subsection CloogLoop 
@example
@group
struct cloogloop
@{ CloogDomain * domain ;       /* Iteration domain. */
  int stride ;                 /* Loop stride. */
  CloogBlock * block ;         /* Included statement block.*/
  struct cloogloop * inner ;   /* Loop at the next level. */
  struct cloogloop * next ;    /* Next loop at the same level. */
@} ;
typedef struct cloogloop CloogLoop ;
@end group
@end example

@noindent The @code{CloogLoop} structure represents a loop.
First of all, a
loop has an iteration domain (@code{domain}). The iterator's stride for loop
increment is @code{stride}. The loop can include a statement block
in the field @code{block}. If there is no included statement block,
@code{block} is set to @code{NULL}. @code{inner} is a pointer to the inner
loop, and @code{next} a pointer to the next loop in the textual order. If
there are no inner loop or no next loop, the corresponding pointer is set
to @code{NULL}.


@node CloogNames
@subsection CloogNames
@example
@group
struct cloognames
@{ int nb_scattering ;         /* Scattering dimension number. */
  int nb_iterators ;          /* Iterator number. */
  int nb_parameters ;         /* Parameter number. */
  char ** scattering ;        /* The scattering dimension names. */
  char ** iterators ;         /* The iterator names. */
  char ** parameters ;        /* The parameter names. */
@} ;
typedef struct cloognames CloogNames ;
@end group
@end example

@noindent The @code{CloogNames} structure represents the scattering dimension,
the iterator and the parameter names in the final program.
@code{nb_scattering} 
(respectively @code{nb_iterators} and @code{nb_parameters})
is the number of scattering dimensions number
(respectively the iterator and parameter number)
and of elements in the corresponding array of strings
@code{scattering}
(respectively @code{iterators} and @code{parameters}).
The @math{i^{th}} scattering dimension name will be associated with the
to the dimension @math{i} of the scattering function.
The @math{i^{th}} iterator name will be associated with the
dimension @math{i} of the iteration domain. 
The @math{i^{th}} parameter name will be associated with the
dimension @math{i} of the context polyhedron.
The user has to ensure that there are
enough scattering dimension, iterator and parameter names. 


@node CloogProgram
@subsection CloogProgram
@example
@group
struct cloogprogram
@{ char language ;              /* The language of the program. */
  int  scattdims ;             /* Scattering dimension number. */
  CloogNames  * names ;        /* Iterators and parameters names. */
  CloogDomain * context ;      /* The context of the program. */
  CloogLoop   * loop ;         /* The loops of the program. */
  CloogBlockList * blocklist ; /* The statement block list. */
@} ;
typedef struct cloogprogram CloogProgram ;
@end group
@end example

@noindent The @code{CloogProgram} structure represents a static control program kernel.
@code{language} precises the language (@code{c} for C or @code{f} for FORTRAN).
@code{scattdims} gives the number of scattering dimensions.
@code{context} is a pointer to the constraints on the program parameters,
it can't be the
@code{NULL} pointer even if there are no constraints on parameters. In such a
case, set a polyhedron with as many dimensions as there are parameters, with
an @emph{always true} constraint like @math{1 \geq 0} (this is necessary
since the number of parameters is deduced from the dimension number of
the context constraints). @code{loop} is a pointer
to the first loop of the program. @code{names} is a pointer to the various
element names (scattering dimension, iterators, parameters)
of the final program. @code{names} can be the @code{NULL}
pointer if the user do not want to use our pretty printing function.
@code{blocklist} is the linked list of all the statement block structures.
As an example, let us consider the following loop nest:
@example
@group
for (i=0; i<=n; i++) @{ 
  for (j=0; j<=n; j++) @{
    S1 ;
    S2 ;
  @}
  for (j=n+1; j<=2*n; j++) @{
    S3 ;
  @}
@}  
@end group
@end example
@noindent The next figure gives a possible representation in memory for this
program thanks to the CLooG data structures (it has been actually printed
by the @code{cloog_program_print} function). In this figure,
@samp{+-- CloogLoop} denotes an @samp{inner} loop, while a @samp{CloogLoop}
on the same column pointed by an arrow denotes a @samp{next} loop:

@smallexample
+-- CloogProgram
|       |       
|       Language: c
|       |       
|       Scattering dimension number: 0
|       |       
|       +-- CloogNames
|       |       |       
|       |       Scattering dimension number: 0
|       |       |       
|       |       +-- No scattering string
|       |       |       
|       |       Iterator number -----------: 2
|       |       |       
|       |       +-- Iterator strings ------: i j
|       |       |       
|       |       Parameter number ----------: 1
|       |       |       
|       |       +-- Parameter strings -----: n
|       |       
|       +-- Context
|       |       [   1    1   -2  ]
|       |       [   1    0    1  ]
|       |       
|       +-- CloogLoop
|       |       |       
|       |       +-- CloogDomain
|       |       |       [   1   -1    1    0  ]
|       |       |       [   1    1    0    0  ]
|       |       |       [   1    0    0    1  ]
|       |       |       
|       |       Stride: 1
|       |       |       
|       |       +-- Null CloogBlock
|       |       |       
|       |       +-- CloogLoop
|       |       |       |       
|       |       |       +-- CloogDomain
|       |       |       |       [   1    0    1    0    0  ]
|       |       |       |       [   1    0   -1    1    0  ]
|       |       |       |       [   1    0    0    0    1  ]
|       |       |       |       
|       |       |       Stride: 1
|       |       |       |       
|       |       |       +-- Null CloogBlock
|       |       |       |       
|       |       |       +-- CloogLoop
|       |       |       |       |       
|       |       |       |       +-- CloogDomain
|       |       |       |       |       [   1    0    0    0    1  ]
|       |       |       |       |       
|       |       |       |       Stride: 1
|       |       |       |       |       
|       |       |       |       +-- CloogBlock
|       |       |       |       |       |       
|       |       |       |       |       +-- CloogStatement 1 
|       |       |       |       |       |          |   
|       |       |       |       |       |          V   
|       |       |       |       |       |   CloogStatement 2 
|       |       |       |       |       |       
|       |       |       |       |       +-- Null scattering function
|       |       |       |       |       |       
|       |       |       |       |       Depth: 2
|       |       |       |       |       
|       |       |       |       
|       |       |       V
|       |       |   CloogLoop
|       |       |       |       
|       |       |       +-- CloogDomain
|       |       |       |       [   1    0   -1    2    0  ]
|       |       |       |       [   1    0    1   -1   -1  ]
|       |       |       |       [   1    0    0    0    1  ]
|       |       |       |       
|       |       |       Stride: 1
|       |       |       |       
|       |       |       +-- Null CloogBlock
|       |       |       |       
|       |       |       +-- CloogLoop
|       |       |       |       |       
|       |       |       |       +-- CloogDomain
|       |       |       |       |       [   1    0    0    0    1  ]
|       |       |       |       |       
|       |       |       |       Stride: 1
|       |       |       |       |       
|       |       |       |       +-- CloogBlock
|       |       |       |       |       |       
|       |       |       |       |       +-- CloogStatement 3 
|       |       |       |       |       |       
|       |       |       |       |       +-- Null scattering function
|       |       |       |       |       |       
|       |       |       |       |       Depth: 2
|       |       |       |       |       
|       |       |       |       
|       |       |       
|       |       
|       
@end smallexample


@node CloogOptions
@subsection CloogOptions
@example
@group
struct cloogoptions
@{ int l ;                     /* -l option.          */
  int f ;                     /* -f option.          */
  int strides ;               /* -strides option.    */
  int esp ;                   /* -esp option.        */
  int csp ;                   /* -csp option.        */
  int fsp ;                   /* -fsp option.        */
  int otl ;                   /* -otl option.        */
  int block ;                 /* -block option.      */
  int cpp ;                   /* -cpp option.        */
  int compilable ;            /* -compilable option. */
@} ;
typedef struct cloogoptions CloogOptions ;
@end group
@end example

@noindent The @code{CloogOptions} structure contains all the possible options to
rule CLooG's behaviour (@pxref{Calling CLooG}).
As a reminder, the default values are:
@itemize @bullet
@item @math{l = -1} (optimize control until the innermost loops),
@item @math{f = 1} (optimize control from the outermost loops),
@item @math{strides = 0} (use only unit strides),
@item @math{esp = 0} (do not spread complex equalities),
@item @math{csp = 1} (spread constant values),
@item @math{fsp = 1} (start to spread from the first iterators),
@item @math{otl = 1} (simplify loops running only once).
@item @math{block = 0} (do not make statement blocks when not necessary).
@item @math{cpp = 0} (do not generate a compilable part of code using preprocessor).
@item @math{compilable = 0} (do not generate a compilable code).
@end itemize 


@node CLooG Functions
@section CLooG Functions Description

@menu
* cloog_program_generate::
* cloog_program_scatter::
* cloog_program_pprint::
* cloog_program_read::
* From Matrices to Domains and Conversely::
* Allocation and Initialization Functions::
* Memory Deallocation Functions::
* Printing Functions::
@end menu


@node cloog_program_generate
@subsection cloog_program_generate
@example
@group
CloogProgram   * cloog_program_generate
( CloogProgram * program,       /* Input program. */
  CloogOptions * options        /* Options. */
) ;
@end group
@end example

@noindent The @code{cloog_program_generate} function generates
the data structure of the source code that scans the input
polyhedra pointed by @code{program}
according to the options pointed by @code{options}.
The process is made directly on the input structure pointed by
@code{program}, thus the original structure is no longer available
after a call to this function. It returns a pointer to a
@code{CloogProgram} structure containing the
solution in CLooG structures.

The input @code{CloogProgram} structure must have only one loop level
(no inner loops): there is one loop per statement block. For a given block,
the corresponding loop carries the iteration domain, the statement block,
and a loop stride initialized to 1. For instance, the input @code{CloogProgram} structure
that have been sent to @code{cloog_program_generate} to achieve the final
structure and code shown as example in the @code{CloogProgram} structure
description (@pxref{CloogProgram}) was the following one:

@smallexample
+-- CloogProgram
|       |       
|       Language: c
|       |       
|       Scattering dimension number: 0
|       |       
|       +-- CloogNames
|       |       |       
|       |       Scattering dimension number: 0
|       |       |       
|       |       +-- No scattering string
|       |       |       
|       |       Iterator number -----------: 2
|       |       |       
|       |       +-- Iterator strings ------: i j
|       |       |       
|       |       Parameter number ----------: 1
|       |       |       
|       |       +-- Parameter strings -----: n
|       |       
|       +-- Context
|       |       [    1     1    -2  ]
|       |       
|       +-- CloogLoop
|       |       |       
|       |       +-- CloogDomain
|       |       |       [    1     1     0     0     0  ]
|       |       |       [    1    -1     0     1     0  ]
|       |       |       [    1     0     1     0     0  ]
|       |       |       [    1     0    -1     1     0  ]
|       |       |       
|       |       Stride: 1
|       |       |       
|       |       +-- CloogBlock
|       |       |       |       
|       |       |       +-- CloogStatement 1 
|       |       |       |          |
|       |       |       |          V
|       |       |       |   CloogStatement 2 
|       |       |       |       
|       |       |       +-- Null scattering function
|       |       |       |       
|       |       |       Depth: 2
|       |       |       
|       |       V
|       |   CloogLoop
|       |       |       
|       |       +-- CloogDomain
|       |       |       [    1     1     0     0     0  ]
|       |       |       [    1    -1     0     1     0  ]
|       |       |       [    1     0     1    -1    -1  ]
|       |       |       [    1     0    -1     2     0  ]
|       |       |       
|       |       Stride: 1
|       |       |       
|       |       +-- CloogBlock
|       |       |       |       
|       |       |       +-- CloogStatement 3 
|       |       |       |       
|       |       |       +-- Null scattering function
|       |       |       |       
|       |       |       Depth: 2
|       |       |       
|       |       
|       
@end smallexample


@node cloog_program_pprint
@subsection cloog_program_pprint
@example
@group
void cloog_program_pprint
( FILE * file,                  /* Output file. */
  CloogProgram * program,       /* Program to print. */
  CloogOptions * options        /* Options. */
) ;
@end group
@end example

@noindent The function @code{cloog_program_pprint} is a pretty printer for
@code{CloogProgram} structures when it is a solution provided by
the @code{cloog_program_generate} function. It prints the code or pseudo-code in the
file pointed by @code{file} (possibly @code{stdout}) with regards to the
options pointed by @code{options}.


@node cloog_program_scatter
@subsection cloog_program_scatter
@example
@group
void cloog_program_scatter
( CloogProgram * program,       /* Input program. */
  CloogDomainList * scattering, /* Additional scattering functions. */
  char ** names ;               /* Additional dimension names. */
) ;
@end group
@end example

@noindent The function @code{cloog_program_scatter} applies scattering
functions to the @code{CloogProgram} structure pointed by @code{program}.
Original domains of @code{program} are freed. Scattering functions
are inside the @code{CloogDomainList} structure pointed by @code{scattering}.
There must be as many scattering functions in the @code{CloogDomainList}
structure as loops (i.e. iteration domains) in the @code{CloogProgram}
structure. The first scattering function of the list will be applied to the
iteration domain of the first loop in the program, and so on.
@code{names} gives the scattering dimension names as an array of strings. If
@code{names} is @code{NULL}, names are automatically generated: the name of
the @math{n^{th}} scattering dimension will be @code{cn}.


@node cloog_program_read
@subsection cloog_program_read
@example
CloogProgram * cloog_program_read(FILE *) ;
@end example
@noindent The @code{cloog_program_read} function
reads the program data from a CLooG input file
(@pxref{Writing The Input File}). It takes
as input a pointer to the file it has to read (possibly @code{stdin}), and
return a pointer to the read @code{CloogProgram} structure.


@node From Matrices to Domains and Conversely
@subsection From Matrices to Domains and Conversely
@example
CloogMatrix * cloog_domain_domain2matrix(CloogDomain *) ;
CloogDomain * cloog_domain_matrix2domain(CloogMatrix *) ;
@end example
@noindent Two functions are provided to translate a @code{CloogDomain}
data structure to a @code{CloogMatrix} data structure and conversely.
Each function takes as input a pointer to the data structure to translate
and returns as output a pointer to the translated data structure. The
input data structure if neither modified nor freed. They
may be quite useful for e.g. pretty printing since it is more convenient
in constraint (matrix) representation.


@node Allocation and Initialization Functions
@subsection Allocation and Initialization Functions
@example
CloogStructure * cloog_structure_malloc() ;
@end example
@noindent Each CLooG data structure has an allocation and initialization
function as shown above, where @code{Structure} and @code{structure} have to
be replaced by the name of the convenient structure (without @samp{Cloog} prefix) for
instance @code{CloogLoop * cloog_loop_malloc() ;}. These functions return
pointers to an allocated structure with fields set to convenient default
values. @strong{Using those functions is mandatory} to support internal
management fields and to avoid upward compatibility problems if
new fields appear. An exception is @code{cloog_matrix_malloc} since the
@code{CloogMatrix} comes directly from the PolyLib. It takes two parameters:
the number of rows and columns of the matrix we want to allocate:
@example
CloogMatrix * cloog_matrix_malloc(unsigned nbrows, unsigned nbcolumns);
@end example


@node Memory Deallocation Functions
@subsection Memory Deallocation Functions
@example
void cloog_structure_free(CloogStructure *) ;
@end example
@noindent Each CLooG data structure has a deallocation function as shown above,
 where @code{Structure} and @code{structure} have to
be replaced by the name of the convenient structure (without @samp{Cloog} prefix) for
instance @code{void cloog_loop_free(CloogLoop *) ;}. These functions
free the allocated memory for the structure provided as input. They free
memory recursively, i.e. they also free the allocated memory for the internal
structures.
@strong{Using those functions is mandatory} to avoid memory leaks on internal
management fields and to avoid upward compatibility problems if
new fields appear.


@node Printing Functions
@subsection Printing Functions
@example
void cloog_structure_print(FILE *, CloogStructure *) ;
@end example
@noindent Each CLooG data structure has a printing function as shown above,
 where @code{Structure} and @code{structure} have to
be replaced by the name of the convenient structure (without @samp{Cloog} prefix) for
instance @code{void cloog_loop_print(FILE *, CloogLoop *) ;}. These functions
print the pointed structure (and its fields recursively) to the file provided
as input (possibly @code{stdout}).


@node Example of Library Utilization
@section Example of Library Utilization
Here is a basic example showing how it is possible to use the CLooG library,
assuming that a standard installation has been done.
The following C program reads a CLooG input file on the standard input,
then prints the solution on the standard output.
Options are preselected to the default values of the CLooG software.
This example is provided in the @code{example} directory of the
CLooG distribution.
@example
/* example.c */
# include <stdio.h>
# include <cloog/cloog.h>

int main()
@{ CloogProgram * program ;
  CloogOptions * options ;
  
  /* Setting options and reading program informations. */
  options = cloog_options_malloc() ;
  program = cloog_program_read(stdin,options) ;

  /* Generating and printing the code. */
  program = cloog_program_generate(program,options) ;
  cloog_program_pprint(stdout,program,options) ;

  cloog_options_free(options) ;
  cloog_program_free(program) ;
  return 0;
@}
@end example

@noindent The compilation command could be:
@example
gcc example.c -lcloog -o example
@end example
@noindent A calling command with the input file test.cloog could be:
@example
more test.cloog | ./example
@end example


@c %  ******************************** HACKING *********************************
@c @node Hacking
@c @chapter Hacking CLooG

@c @menu
@c * Program organization::
@c * Special Options::
@c * CLooG Coding Standards::
@c @end menu

@c @node Program organization
@c @section Program organization

@c @node Special Options
@c @section Special Options

@c @node CLooG Coding Standards
@c @section CLooG Coding Standards


@c %  ****************************** INSTALLING ********************************
@node Installing
@chapter Installing CLooG

@menu
* License::
* Requirements::
* Basic Installation::
* Optional Features::
* Uninstallation::
@end menu

@node License
@section License
First of all, it would be very kind to refer the following paper in any
publication that result from the use of the CLooG software or its library,
@pxref{Bas04} (a bibtex entry is provided behind the title page of this
manual, along with copyright notice, and in the CLooG home
@code{http://www.CLooG.org}.

This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License version 2
as published by the Free Software Foundation.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.
@code{http://www.gnu.org/copyleft/gpl.html}


@node Requirements
@section Requirements

@menu
* PolyLib::
* GMP Library::
@end menu


@node PolyLib
@subsection PolyLib (mandatory)
To successfully install CLooG, the user need firstly to install PolyLib
version 5.22.1 or above (default 64 bits version is satisfying
as well as 32 bits or GMP multiple precision version).
Polylib can be downloaded freely
at @code{http://icps.u-strasbg.fr/PolyLib/} or
@code{http://www.irisa.fr/polylib/}. Once downloaded and unpacked
(e.g. using the @samp{tar -zxvf polylib-5.22.1.tar.gz} command),
the user can compile
it by typing the following commands on the PolyLib's root directory:

@itemize @bullet
@item @code{./configure}
@item @code{make}
@item And as root: @code{make install}
@end itemize

The PolyLib default installation is @code{/usr/local}. This directory may
not be inside your library path. To fix the problem, the user should set
@example
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
@end example
@noindent if your shell is, e.g., bash or
@example
setenv LD_LIBRARY_PATH $LD_LIBRARY_PATH:/usr/local/lib
@end example
@noindent if your shell is, e.g., tcsh. Add the line to your .bashrc or .tcshrc (or
whatever convenient file) to make this change permanent. Another solution
is to ask PolyLib to install in the standard path by using the prefix
option of the configure script:
@samp{./configure --prefix=/usr}.

CLooG makes intensive calls to polyhedral operations, and PolyLib
functions do the job. Polylib is a free library written in C for the
manipulation of polyhedra. The library is operating on objects like
vectors, matrices, lattices, polyhedra, Z-polyhedra, unions of
polyhedra and a lot of other intermediary structures. It provides
functions for all the important operations on these structures. 

@node GMP Library
@subsection GMP Library (optional)

To be able to deal with insanely large coefficient, the user will need to
install the GNU Multiple Precision Library (GMP for short) version 4.1.4
or above. It can be freely downloaded from @code{http://www.swox.com/gmp}.
The user can compile it by typing the following commands on the GMP root
directory:

@itemize @bullet
@item @code{./configure}
@item @code{make}
@item And as root: @code{make install}
@end itemize

The GMP default installation is @code{/usr/local}, the same method to
fix a library path problem applies as with PolyLib (@pxref{PolyLib}).

The PolyLib has to be built using the GMP library by specifying the option
@samp{--with-libgmp=PATH_TO_GMP} to the PolyLib configure script
(where @code{PATH_TO_GMP} is @code{/usr/local} if you did not change the GMP
installation directory). Then you have to set the convenient CLooG configure
script options to buid the GMP version (@pxref{Optional Features}).


@node Basic Installation
@section CLooG Basic Installation

Once downloaded and unpacked
(e.g. using the @samp{tar -zxvf cloog-@value{VERSION}.tar.gz} command),
you can compile CLooG by typing the following commands on the CLooG's root
directory:

@itemize @bullet
@item @code{./configure}
@item @code{make}
@item And as root: @code{make install}
@end itemize

Depending on the location of the PolyLib, you may need to set the
option @code{--with-polylib} of the configure script
(e.g. @samp{./configure --with-polylib=/usr/local} with a default PolyLib
installation).

The program binaries and object files can be removed from the
source code directory by typing @code{make clean}. To also remove the
files that the @code{configure} script created (so you can compile the
package for a different kind of computer) type @code{make distclean}.

Both the CLooG software and library have been successfully compiled
on the following systems:
@itemize @bullet
@item PC's under Linux, with the @code{gcc} compiler,
@item PC's under Windows (Cygwin), with the @code{gcc} compiler,
@item Sparc and UltraSparc Stations, with the @code{gcc} compiler.
@end itemize

@node Optional Features 
@section Optional Features  
The @code{configure} shell script attempts to guess correct values for
various system-dependent variables and user options used during compilation.
It uses those values to create the @code{Makefile}. Various user options
are provided by the CLooG's configure script. They are summarized in the
following list and may be printed by typing @code{./configure --help} in the
CLooG top-level directory.

@itemize @bullet
@item By default, the installation directory is @code{/usr/local}:
@code{make install} will install the package's files in
@code{/usr/local/bin}, @code{/usr/local/lib} and @code{/usr/local/include}.
The user can specify an installation prefix other than @code{/usr/local} by
giving @code{configure} the option @code{--prefix=PATH}.

@item By default, @code{configure} will look for the PolyLib in standard
locations. If necessary, the user can specify the PolyLib path by giving
@code{configure} the option @code{--with-polylib=PATH}.

@item By default, both CLooG software and library are compiled and installed.
By giving  @code{configure} the option @code{--without-cloog} the user
disable the compilation and installation of the CLooG software.
By giving @code{configure} the option
@code{--without-lib} the user disable the compilation and installation of the
CLooG library.

@item By default, CLooG is built in 64bits version if such version of the
PolyLib is found by @code{configure}. If the only existing version of the
PolyLib is the 32bits or if the user give to @code{configure} the option
@code{--with-bits=32}, the 32bits version of CLooG will be compiled. In the
same way, the option @code{--with-bits=gmp} have to be used to build
the multiple precision version.

@item By default, @code{configure} will look for the GMP library
(necessary to build the multiple precision version) in standard
locations. If necessary, the user can specify the GMP path by giving
@code{configure} the option @code{--with-gmp=PATH}.
@end itemize

@node Uninstallation 
@section Uninstallation  
The user can easily remove the CLooG software and library from his system
by typing (as root if necessary) from the CLooG top-level directory
@code{make uninstall}.

@c %  **************************** DOCUMENTATION ******************************
@node Documentation
@chapter Documentation
The CLooG distribution provides several documentation sources. First, the
source code itself is as documented as possible. The code comments use a
Doxygen-compatible presentation (something similar to what JavaDoc does for
JAVA). The user may install Doxygen
(see @code{http://www.stack.nl/~dimitri/doxygen}) to automatically
generate a technical documentation by typing @code{make doc} or
@code{doxygen ./autoconf/Doxyfile} at the CLooG top-level directory after
running the configure script (@pxref{Installing}). Doxygen will generate
documentation sources (in HTML, LaTeX and man) in the @code{doc/source}
directory of the CLooG distribution.

The Texinfo sources of the present document are also provided in the @code{doc}
directory. You can build it in either DVI format (by typing
@code{texi2dvi cloog.texi}) or PDF format
(by typing @code{texi2pdf cloog.texi}) or HTML format
(by typing @code{makeinfo --html cloog.texi}, using @code{--no-split}
option to generate a single HTML file) or info format
(by typing @code{makeinfo cloog.texi}).

@c %  ****************************** REFERENCES ********************************
@node References
@chapter References

@itemize
@item
@anchor{Bas03a}[Bas03a] C. Bastoul, P. Feautrier. Improving data locality
by chunking. CC'12 International Conference on Compiler Construction,
LNCS 2622, pages 320-335, Warsaw, april 2003. 

@item
@anchor{Bas03b}[Bas03b] C. Bastoul. Efficient code generation for automatic
parallelization and optimization. ISPDC'03 IEEE International Symposium on
Parallel and Distributed Computing, pages 23-30, Ljubljana, october 2003. 

@item
@anchor{Bas04}[Bas04] C. Bastoul. Code Generation in the Polyhedral Model
Is Easier Than You Think. PACT'13 IEEE International Conference on Parallel
Architecture and Compilation Techniques, pages 7-16, Juan-les-Pins,
september 2004.

@item
@anchor{Fea92}[Fea92] P. Feautrier Some efficient solutions to the affine
scheduling problem, part II: multidimensional time.
International Journal of Parallel Programming, 21(6):389--420, December 1992.

@item
@anchor{Gri04}[Gri04] M. Griebl. Automatic parallelization of loop programs
for distributed memory architectures. Habilitation Thesis. Facult@"at f@"ur
Mathematik und Informatik, Universit@"at Passau, 2004.
@emph{http://www.infosun.fmi.uni-passau.de/cl/loopo/}

@item
@anchor{Qui00}[Qui00] F. Quiller@'e, S. Rajopadhye, and D. Wilde.
Generation of efficient nested loops from polyhedra.
International Journal of Parallel Programming, 28(5):469-498,
october 2000.

@item
@anchor{Wil93}[Wil93] Doran K. Wilde.
A library for doing polyhedral operations.
Technical Report 785, IRISA, Rennes, France, 1993.

@end itemize




@c % /*************************************************************************
@c %  *                       PART VI: END OF THE DOCUMENT                    *
@c %  *************************************************************************/
@c @unnumbered Index
     
@c @printindex cp
     
@bye