diff --git a/doc/pdg/.gitignore b/doc/pdg/.gitignore
new file mode 100644
index 0000000000000000000000000000000000000000..144038366c79af13135b3357ed21da6c83ac23a1
--- /dev/null
+++ b/doc/pdg/.gitignore
@@ -0,0 +1,6 @@
+biblio.bib
+frama-c-book.cls
+frama-c-cover.pdf
+frama-c-left.pdf
+frama-c-right.pdf
+main.pdf
diff --git a/doc/pdg/Makefile b/doc/pdg/Makefile
new file mode 100644
index 0000000000000000000000000000000000000000..de8bc6307421bec04bd8fab929978e1191a8f78e
--- /dev/null
+++ b/doc/pdg/Makefile
@@ -0,0 +1,70 @@
+.PHONY: all clean
+
+all: main.pdf
+
+GENERATED=biblio.bib
+GENERATED+=frama-c-book.cls frama-c-cover.pdf frama-c-left.pdf frama-c-right.pdf
+include ../MakeLaTeXModern
+
+DWNLDDIR=../manuals
+DOCNAME=pdg-documentation-fr.pdf
+TEST_DIR=../../tests/pdg/
+
+BIB_FILE = ../slicing/bib-slicing.bib
+main.bbl : $(BIB_FILE)
+ @echo "=== Fichier .bib plus récent -> effacement du .bbl"
+ rm -f $(SRC).bbl
+
+main.pdf: $(FRAMAC_MODERN) $(BIB_FILE) \
+ main.tex pdg.tex macros_pdg.tex \
+ intro.tex conclusion.tex \
+ data.tex ctrl.tex calls.tex utilisation.tex mark.tex impact.tex \
+ ../images/cealistlogo.jpg \
+ exple-call.c call-f.pdf call-g.pdf \
+ ctrl-dpds.pdf ex-goto.pdf goto.pdf pdg-call.pdf
+
+###############################################################################
+
+GENERATED+=call-f.fig call-g.fig
+%.fig : %.dot
+ dot -Tfig $< > $@
+
+GENERATED+=call-f.pdf call-g.pdf
+%.pdf : %.fig
+ fig2dev -L pdf $< $@
+
+GENERATED+=call-f.dot call-g.dot
+call-%.dot : $(TEST_DIR)/call.%.dot
+ cp $< $@
+
+call-%.dot :
+ @echo
+ @echo "ERROR : $@ not found : you should run PDG tests to have it"
+ @echo " Run : cd ../.. ; make pdg_tests ; cd - "
+ @echo
+ exit 1
+
+GENERATED+=exple-call.c
+exple-%.c : $(TEST_DIR)/%.c
+ sed "1,/BDOC/d" $< > $@
+
+###############################################################################
+
+%.pdf: %.tex
+ pdflatex $*
+ bibtex $*
+ pdflatex $*
+ pdflatex $*
+
+install: main.pdf
+ @echo "copying main.pdf in $(DWNLDDIR)/$(DOCNAME)"
+ @rm -f "$(DWNLDDIR)/$(DOCNAME)"
+ @cp main.pdf "$(DWNLDDIR)/$(DOCNAME)"
+
+clean:
+ rm -rf *~ *.aux *.log *.nav *.out *.snm *.toc *.lof *.pp *.bnf \
+ *.haux *.hbbl *.htoc \
+ *.cb *.cb2 *.cm? *.bbl *.blg *.idx *.ind *.ilg \
+ $(GENERATED)
+
+###############################################################################
diff --git a/doc/pdg/calls.tex b/doc/pdg/calls.tex
new file mode 100644
index 0000000000000000000000000000000000000000..f50ff876f08f1daceddb482f80f1e291fd2892bd
--- /dev/null
+++ b/doc/pdg/calls.tex
@@ -0,0 +1,209 @@
+\chapter{Dépendances interprocédurales}\label{sec-intro-call}
+
+On a vu qu'un PDG est associé à une fonction.
+La question se pose donc de savoir
+comment calculer des dépendances interprocédurales, c'est-à -dire comment mettre
+en relation les appels de fonctions et les dépendances des fonctions appelées.
+
+Nous allons tout d'abord voir qu'un appel de fonction
+est représenté par plusieurs éléments dans le PDG (\S\ref{sec-call}).
+Puis, nous allons voir que pour mettre en relation des appels et les fonctions
+appelées, ils faut ajouter d'autres éléments à chaque fonction
+(\S\ref{sec-fct-inout}).
+
+\section{Appels de fonction}\label{sec-call}
+
+L'instruction contenant l'appel est représentée par plusieurs
+éléments dans le graphe de dépendances
+afin de pouvoir plus précisément mettre en relation les appels aux
+fonctions appelées.
+
+Les éléments créés sont les suivants~:
+\begin{itemize}
+\item un élément pour chaque paramètre de la fonction appelée;
+ les dépendances sont crées par une simulation
+ de l'affectation des arguments d'appel dans les paramètres formels,
+\item un élément représentant le contrôle du point d'entrée de la fonction
+ appelée (un peu comme si l'appel était dans un bloc et que ce noeud
+ représentait ce bloc),
+\item un élément pour chaque sortie, dépendant des entrées correspondantes.
+\end{itemize}
+
+Pour ne pas avoir à calculer les flots de données de toutes les fonctions de
+l'application, il a été décidé d'utiliser les dépendances ({\it from})
+calculées indépendamment par \ppc.
+La liste des entrées et des sorties, ainsi que les dépendances entre les unes et
+les autres sont extraites des spécifications des fonctions appelées, et non de
+leur PDG\footnote{c'est peut-être un problème
+si on fait de la coupure de branche, car les dépendances peuvent être réduites
+par une telle spécialisation.}.
+Ceci est vrai également pour les
+fonctions dont le code est absent de l'application étudiée
+car cela permet d'être cohérent avec les autres analyses.
+Cela permettra en particulier, d'utiliser d'éventuelles propriétés
+fournies par la suite par l'utilisateur.
+
+\begin{exemple}
+\begin{tabular}{m{0.35\textwidth} m{0.6\textwidth}}
+\begin{verbatim}
+struct {int a;
+ int b; } G;
+
+/*@ assigns \result {a},
+ G.a {G, a} */
+int g (int a);
+
+int f (int x, int y) {
+ G.b = x;
+ x = g (x+y);
+ return x + G.b;
+}
+\end{verbatim}
+&
+Ici, pour représenter l'appel à \verbtt{g} dans \verbtt{f} dans le PDG,
+on va avoir~:
+\begin{itemize}
+ \item un élément représentant le point d'entrée dans \verbtt{g},
+ \item un élément $e_1$ pour représenter \verbtt{a = x+y},
+ c'est-Ã -dire l'affectation de l'argument de l'appel
+ dans le paramètre formel de \verbtt{g},
+ \item un élément $e_2$ pour calculer la valeur de retour de \verbtt{g},
+ qui dépend de la valeur de $e_1$
+ (utilisation de la spécification de $g$),
+
+\item et enfin, un élément $e_3$ qui représente la seconde sortie de \verbtt{g}~:
+\verbtt{G.a} qui dépend du paramètre \verbtt{a} et donc de $e_1$
+ et de des éléments $\{ e_G \}$
+ correspondant Ã
+ la valeur de $G$ avant l'appel
+(selon la spécification de $g$).
+\end{itemize}
+\end{tabular}
+\end{exemple}
+
+On note que, contrairement à ce qui était fait dans la version précédente,
+on ne crée par d'élément pour l'entrée implicite $G$ de $g$ dans $f$.
+Cela permet d'améliorer la précision des dépendances lorsque
+l'ajout d'un tel noeud conduisait au regroupement de plusieurs données.
+
+Ainsi, dans l'exemple précédent, on ne crée pas d'élément pour
+représenter la valeur de $G$ avant l'appel, même si l'élément $e_3$ en dépend,
+et on conserve donc l'information que $G.b$ ne dépend que de l'affectation
+précédent l'appel.
+
+
+\section{Entrées/sorties d'une fonction}\label{sec-fct-inout}
+
+Pour relier un appel de fonction au PDG de la fonction appelée,
+il faut ajouter des éléments représentant ses entrées/sorties,
+c'est-Ã -dire~:
+
+\begin{itemize}
+ \item un élément correspondant au point de contrôle d'entrée
+dans la fonction,
+\item deux éléments pour chaque paramètre (cf. \S\ref{sec-decl-param}),
+\item un élément pour les entrées implicites (cf. \S\ref{sec-impl-in}),
+\item un élément pour la sortie de la fonction si celle-ci retourne
+ quelque chose.
+\end{itemize}
+
+On note que, contrairement à ce qui était fait dans la version précédente,
+on ne crée par d'élément pour les sorties implicites de la fonction.
+Cela permet d'améliorer la précision des dépendances lorsque
+l'ajout d'un tel noeud conduisait au regroupement de plusieurs données.
+
+C'est par exemple le cas lorsqu'une fonction calcule $G.a$,
+puis $G.a.x$ car un élément de sortie regrouperait les deux alors que
+si par la suite on s'intéresse juste à $G.a.x$ à la sortie de la fonction,
+le fait de ne pas avoir créé cet élément permet de retrouver l'information plus
+précise.
+
+\subsection{Entrées implicites}\label{sec-impl-in}
+
+Au cours du calcul du PDG, on mémorise l'utilisation des données
+qui ne sont pas préalablement définies.
+Cela permet par la suite que créer des éléments pour ces entrées dites
+implicites. On ne crée pas d'élément pour les variables locales non
+initialisées, mais un message d'avertissement est émis.
+Il est possible que ce soit une fausse alerte dans le cas où l'initialisation
+est faite dans une branche dont la condition est forcement vrai à chaque
+exécution où l'on passe par la suite par l'utilisation.
+
+Diverses stratégies de regroupement de ces entrées peuvent être utilisées.
+A ce jour, l'outil construit tous les éléments lui permettant d'avoir une
+meilleure précision. C'est-à -dire que deux éléments peuvent représenter les
+données qui ont une intersection.
+
+\subsection{Déclaration des paramètres formels}\label{sec-decl-param}
+
+En plus de l'élément représentant la valeur des paramètres,
+on crée un second élément qui représente sa déclaration,
+le premier dépendant du second.
+
+Cette représentation peut permettre d'avoir une meilleure précision
+dans le cas où certains calcul ne dépendent pas de la valeur du
+paramètre, mais uniquement de sa déclaration.
+
+\begin{exemple}
+\begin{tabular}{m{5cm} m{\linewidth - 6cm}}
+\begin{verbatim}
+int g (int a) {
+ G = 2 * a;
+ a = calcul_a ();
+ return a;
+}
+int f (void) {
+ int x = calcul_x ();
+ return g (x);
+}
+\end{verbatim}
+&
+On voit que la valeur de retour de \verbtt{g} ne nécessite pas la valeur initiale
+de \verbtt{a}, mais seulement sa déclaration. La valeur de retour de \verbtt{f}
+ne dépend donc pas de l'appel à \verbtt{calcul\_x}.
+\end{tabular}
+\end{exemple}
+
+Ce point n'est pas encore implémenté dans la version actuelle,
+car dans des cas plus complexe, il est délicat de savoir ce qu'il faut
+garder dans la fonction appelante. Le plus simple serait sans doute
+de transformer le paramètre formel en une variable locale,
+mais le filtrage permet à l'heure actuelle de garder ou d'effacer des
+éléments existants, mais pas d'effectuer des transformations de code...
+
+\section{Fonctions à nombre d'arguments variable}
+
+Pour l'instant, on ne calcule pas le PDG des fonctions à nombre
+d'arguments variable, c'est-Ã -dire que pour le reste de l'application,
+tout se passe comme si on n'avait pas le code source de ces fonctions.\\
+
+En revanche, les appels à de telles fonctions sont gérées de manière semblable Ã
+ce qui est fait pour les autres appels, c'est-Ã -dire~:
+\begin{itemize}
+ \item création d'un noeud d'entrée pour chaque argument d'appel,
+ (il y en a donc éventuellement plus que que paramètres formels dans le
+ déclaration de la fonction appelée)
+ \item utilisation des informations {\it from} pour créer les éventuelles
+ entrées implicites, les sorties, et les liens de dépendance.
+\end{itemize}
+
+\section{Exemple}
+
+\begin{exemple}
+
+\lstinputlisting[language=c]{exple-call.c}
+\end{exemple}
+
+Graphe de la fonction \verbtt{f}: \\
+
+\includegraphics[width=0.6\textwidth]{call-f}
+\\
+
+\clearpage
+
+Graphe de la fonction \verbtt{g}: \\
+
+\includegraphics[width=1\textwidth]{call-g}
+\\
+
+Les graphes sont ceux qui sont effectivement produits par l'outil.
diff --git a/doc/pdg/conclusion.tex b/doc/pdg/conclusion.tex
new file mode 100644
index 0000000000000000000000000000000000000000..646d2642d4a8a9dcebc3c31aa079b976331333a9
--- /dev/null
+++ b/doc/pdg/conclusion.tex
@@ -0,0 +1,22 @@
+\chapter{Conclusion}
+
+La version actuelle de ce greffon semble fonctionner.
+Elle est utilisée par les greffons {\sc Security}, {\sc Sparecode} et
+{\sc Slicing}. Ces résultats peuvent également être visualisés
+graphiquement en utilisant la fonction d'exportation
+au format {\tt .dot}.\\
+
+D'autres information relatives au développement peuvent être trouvées dans la documentation du code dont un point d'entrée
+est~:
+
+\centerline{\tt doc/code/pdg/index.html}
+
+\section{Limitations}
+
+Les fonctions ayant un nombre d'arguments variable
+ne sont pas traitées (mais les appels à de telles fonctions sont gérés).
+
+Par ailleurs, les calculs se basant sur l'analyse de valeur,
+et sur le calcul des dépendances fonctionnelles (\from)
+il hérite des limitations de ces modules.
+
diff --git a/doc/pdg/ctrl-dpds.fig b/doc/pdg/ctrl-dpds.fig
new file mode 100644
index 0000000000000000000000000000000000000000..d41477b617f390b1c3fb6fc1f10e5ea6da28a72b
--- /dev/null
+++ b/doc/pdg/ctrl-dpds.fig
@@ -0,0 +1,106 @@
+#FIG 3.2
+Portrait
+Center
+Metric
+A4
+100.00
+Single
+-2
+1200 2
+0 32 #ffffff
+6 4410 2610 5355 3195
+2 3 0 1 32 32 0 -1 20 0.000 0 0 0 0 0 5
+ 4417 2645 5314 2645 5314 3165 4417 3165 4417 2645
+2 3 0 1 0 0 0 0 -1 0.000 0 0 0 0 0 5
+ 4417 2645 5314 2645 5314 3165 4417 3165 4417 2645
+4 1 0 0 0 16 17 0.0000 6 180 810 4866 2976 START\001
+-6
+6 5715 6210 6120 6795
+2 3 0 1 32 32 0 -1 20 0.000 0 0 0 0 0 5
+ 5728 6236 6082 6236 6082 6755 5728 6755 5728 6236
+2 3 0 1 0 0 0 0 -1 0.000 0 0 0 0 0 5
+ 5728 6236 6082 6236 6082 6755 5728 6755 5728 6236
+4 1 0 0 0 16 17 0.0000 6 180 165 5905 6566 B\001
+-6
+6 7470 4860 7965 5445
+2 3 0 1 32 32 0 -1 20 0.000 0 0 0 0 0 5
+ 7488 4889 7960 4889 7960 5409 7488 5409 7488 4889
+2 3 0 1 0 0 0 0 -1 0.000 0 0 0 0 0 5
+ 7488 4889 7960 4889 7960 5409 7488 5409 7488 4889
+4 1 0 0 0 16 17 0.0000 6 180 300 7724 5220 S2\001
+-6
+6 5715 4860 6120 5445
+2 3 0 1 32 32 0 -1 20 0.000 0 0 0 0 0 5
+ 5740 4889 6094 4889 6094 5409 5740 5409 5740 4889
+2 3 0 1 0 0 0 0 -1 0.000 0 0 0 0 0 5
+ 5740 4889 6094 4889 6094 5409 5740 5409 5740 4889
+4 1 0 0 0 16 17 0.0000 6 180 150 5917 5220 Z\001
+-6
+6 4725 5715 5220 6255
+2 3 0 1 32 32 0 -1 20 0.000 0 0 0 0 0 5
+ 4748 5716 5220 5716 5220 6236 4748 6236 4748 5716
+2 3 0 1 0 0 0 0 -1 0.000 0 0 0 0 0 5
+ 4748 5716 5220 5716 5220 6236 4748 6236 4748 5716
+4 1 0 0 0 16 17 0.0000 6 180 285 4984 6047 Z1\001
+-6
+6 6435 5715 6975 6255
+2 3 0 1 32 32 0 -1 20 0.000 0 0 0 0 0 5
+ 6472 5716 6968 5716 6968 6236 6472 6236 6472 5716
+2 3 0 1 0 0 0 0 -1 0.000 0 0 0 0 0 5
+ 6472 5716 6968 5716 6968 6236 6472 6236 6472 5716
+4 1 0 0 0 16 17 0.0000 6 180 285 6720 6047 Z2\001
+-6
+6 4455 7155 5220 7740
+2 3 0 1 32 32 0 -1 20 0.000 0 0 0 0 0 5
+ 4464 7181 5196 7181 5196 7700 4464 7700 4464 7181
+2 3 0 1 0 0 0 0 -1 0.000 0 0 0 0 0 5
+ 4464 7181 5196 7181 5196 7700 4464 7700 4464 7181
+4 1 0 0 0 16 17 0.0000 6 180 675 4830 7511 STOP\001
+-6
+6 6480 3375 6885 3960
+2 3 0 1 32 32 0 -1 20 0.000 0 0 0 0 0 5
+ 6519 3401 6874 3401 6874 3921 6519 3921 6519 3401
+2 3 0 1 0 0 0 0 -1 0.000 0 0 0 0 0 5
+ 6519 3401 6874 3401 6874 3921 6519 3921 6519 3401
+4 1 0 0 0 16 17 0.0000 6 180 165 6696 3732 A\001
+-6
+6 4725 4185 5220 4725
+2 3 0 1 32 32 0 -1 20 0.000 0 0 0 0 0 5
+ 4745 4204 5194 4204 5194 4724 4745 4724 4745 4204
+2 3 0 1 0 0 0 0 -1 0.000 0 0 0 0 0 5
+ 4745 4204 5194 4204 5194 4724 4745 4724 4745 4204
+4 1 0 0 0 16 17 0.0000 6 180 300 4970 4535 S1\001
+-6
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3
+ 2 1 1.00 60.00 120.00
+ 5310 2925 6345 2925 6705 3420
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3
+ 2 1 1.00 60.00 120.00
+ 4500 3150 4275 5445 4680 7200
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3
+ 2 1 1.00 60.00 120.00
+ 6525 3600 5175 3600 4950 4185
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3
+ 2 1 1.00 60.00 120.00
+ 6885 3600 7245 3600 7650 4905
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3
+ 2 1 1.00 60.00 120.00
+ 5175 4455 5625 4455 5895 4905
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3
+ 2 1 1.00 60.00 120.00
+ 5760 5175 5310 5175 4950 5715
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3
+ 2 1 1.00 60.00 120.00
+ 6075 5175 6480 5175 6750 5715
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3
+ 2 1 1.00 60.00 120.00
+ 4950 6210 4995 6390 5715 6615
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3
+ 2 1 1.00 60.00 120.00
+ 6750 6210 6705 6390 6075 6615
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3
+ 2 1 1.00 60.00 120.00
+ 7650 5400 7650 6300 5175 7425
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3
+ 2 1 1.00 60.00 120.00
+ 5850 6750 5850 6975 5175 7290
diff --git a/doc/pdg/ctrl.tex b/doc/pdg/ctrl.tex
new file mode 100644
index 0000000000000000000000000000000000000000..a5bbd5d16174dd5e11243856d77c73963b2301ec
--- /dev/null
+++ b/doc/pdg/ctrl.tex
@@ -0,0 +1,747 @@
+\newcommand{\text}[1]{\mbox{#1}}
+\newcommand{\impl}{\Rightarrow}
+\newcommand{\et}{\wedge}
+\newcommand{\ou}{\vee}
+\newcommand{\define}{\Leftrightarrow{def}}
+\newcommand{\mssi}{\Leftrightarrow}
+
+\newcommand{\llb}{\llbracket}
+\newcommand{\ch}[1]{[#1]}
+\newcommand{\mch}[1]{[#1[}
+\newcommand{\allch}[1]{\llb #1] }
+\newcommand{\allmch}[1]{\llb #1[}
+
+\newcommand{\n}[1]{\ensuremath{\mathfrak{#1}}}
+\newcommand{\nE}{\n{E}}
+\renewcommand{\P}[1]{\ensuremath{\mathit{P}(\n{#1})}}
+\newcommand{\D}[2]{\ensuremath{\mathit{D}(\n{#1},\n{#2})}}
+\newcommand{\Pd}[1]{\ensuremath{\mathit{Pd}(\n{#1})}}
+\newcommand{\Pdi}[1]{\ensuremath{\mathit{Pd}^{\infty}(\n{#1})}}
+\newcommand{\Pda}[1]{\ensuremath{\mathit{Pd}^{+}(\n{#1})}}
+\newcommand{\dpdc}[1]{\ensuremath{\mathit{DpdC}(\n{#1})}}
+\newcommand{\codpdc}[1]{\ensuremath{\mathit{CoDpdC}(\n{#1})}}
+\renewcommand{\succ}[1]{\ensuremath{\mathit{Succ}(\n{#1})}}
+\newcommand{\succl}[1]{\ensuremath{\mathit{Succ_{L}}(\n{#1})}}
+
+\newcommand{\ssi}{si et seulement si }
+
+\chapter{Dépendances de contrôle}\label{sec-cdg}
+
+\section{Introduction}
+
+Intuitivement, un noeud \n{n} du PDG a une dépendance de contrôle sur un noeud
+\n{c}
+si le fait d'exécuter \n{n} dépend du résultat de l'exécution de \n{c}.
+Typiquement, \n{c} est un noeud qui a plusieurs successeurs, comme un {\sc if} par
+exemple,
+et en fonction de la branche qui est choisie, \n{n} est exécuté ou non.
+
+Nous allons voir qu'il existe de nombreuses façons de calculer ces
+dépendances de contrôle, mais que nous avons du les adapter car
+elle ne correspondent pas exactement à ce que l'on souhaitait faire.
+Le principal problème est que
+nous nous proposons d'analyser correctement
+toute fonction, même en présence de sauts quelconques, voire de boucles
+infinies; ce qui, comme nous allons le voir,
+pose des problèmes particuliers au niveau des dépendances de contrôle.
+
+\section{Etat de l'art}
+
+Commençons tout d'abord par rappeler quelques définitions
+et rapporter les résultats que l'on trouve dans la littérature.
+
+\subsection{CFG}
+
+Le \indexdef{graphe de flot de contrôle} est un graphe orienté qui définit l'ordre
+d'exécution des instructions. Un noeud \n{a} est connecté à un noeud \n{b}
+si l'instruction \n{b} peut suivre immédiatement
+l'instruction \n{a} dans une trace l'exécution.
+On dit que \n{b} est un \indexdef{successeur} de \n{a}.
+On représente l'ensemble des successeurs d'un noeud \n{a} par $\succ{a}$.
+On dit aussi que \n{a} est un \indexdef{prédécesseur} de \n{b}.\\
+
+Un noeud est considéré comme une entrée dans le CFG s'il n'a pas de prédécesseur.
+Il est généralement considéré qu'il y a un unique noeud d'entrée,
+et que tous les noeuds du CFG sont atteignables depuis ce point d'entrée.
+Cette hypothèse semble raisonnable car on s'intéresse au CFG d'une fonction
+qui a bien un seul point d'entrée, et les instructions non atteignables depuis
+le point d'entrée sont du
+code mort que l'on peut donc ignorer dans les analyses.\\
+
+Un noeud est considéré comme une sortie du CFG s'il n'a pas de successeur.
+Son unicité et son accessibilité sont discutées plus loin.
+
+
+\subsection{Postdominateurs}
+
+La plupart des algorithmes de calcul des dépendances de contrôle
+se basent
+sur un CFG dans lequel sont ajoutés deux noeuds spéciaux {\sc start} et
+{\sc stop} (on notera \nE{} ce dernier),
+et sur la notion de \indexdef{postdominateur} dont une définition est
+la suivante~:
+
+\begin{definition}{postdominateur}
+ Une instruction \n{a} est {\bf postdominée} par une instruction \n{b}
+ (\n{b} est un {\bf postdominateur} de \n{a})
+ si tous les chemins qui vont de \n{a} au noeud \nE{} contiennent \n{b}.
+\end{definition}
+
+En d'autres termes, si on passe par l'instruction \n{a},
+on passe forcement par tous ses postdominateurs avant de sortir.
+Ou encore,
+toutes les traces partant de \n{a} et allant à \nE{} passent par \n{b}.\\
+
+
+Certains auteurs définissent également
+le \indextxtdef{premier postdominateur}{postdominateur!premier}
+(appelé aussi \indextxtdef{postdominateur immédiat}{postdominateur!immédiat})
+de la façon suivante~:
+
+\begin{definition}{premier postdominateur}
+ \n{b} est le premier postdominateur de \n{a} \ssi~:
+\begin{itemize}
+ \item \n{b} postdomine \n{a},
+ \item et \n{b} est postdominé par tous les autres postdominateurs de \n{a}.
+\end{itemize}
+\n{b} est donc unique.
+\end{definition}
+
+Cela permet de construire un arbre (appelé PDT pour {\it Post-Dominator Tree})
+représentant cette relation dans lequel les noeuds sont les mêmes que
+ceux du CFG et le père de chaque noeud est son premier postdominateur.\\
+
+L'ensemble des postdominateurs d'un noeud \n{a} est donné par~:
+$$
+\Pd{a} = \{a\} \bigcup \bigcap_{s \in \succ{a}} \Pd{s}
+$$
+qui traduit le fait que \n{b} postdomine \n{a} \ssi $\n{b} = \n{a}$
+ou \n{b} postdomine tous les successeurs de \n{a}.
+La méthode de calcul consiste à initialiser tous les ensembles à $\top$,
+et à itérer jusqu'à stabilisation.
+La fonction étant décroissante, la convergence est assurée.\\
+
+
+La notion classique de postdominateurs suppose que le CFG ait un point unique de
+sortie \nE,
+et que celui-ci soit atteignable depuis tous les autres points du graphe.
+Si ce n'est pas le cas, Ã la fin de ce calcul,
+pour les \n{a} n'ayant pas de chemin vers \nE, on a~: $\Pd{a} = \top$.\\
+
+
+\subsection{Dépendances de contrôle}
+
+Intuitivement, on dit qu'une instruction \n{a} a une \indextxtdef{dépendance de
+contrôle}{dépendance!contrôle} sur une instruction \n{c}
+si, en fonction du choix que l'on fait en \n{c}, on passe ou non en \n{a}.
+Cela suppose donc qu'il y ait un choix à faire en \n{c},
+c'est-Ã -dire que le noeud correspondant dans le CFG
+ait plusieurs successeurs.\\
+
+Les dépendances de contrôle sont définies par \cite{Ferrante87}
+de la façon suivante~:
+
+\begin{definition}{dépendances de contrôle selon \cite{Ferrante87}}
+ Pour deux noeuds \n{a} et \n{b} du CFG, \n{b} dépend de \n{a} ssi~:
+\begin{itemize}
+ \item il existe un chemin P de \n{a} a \n{b}
+ tel que tout noeud Z de P, différent de \n{a} et de \n{b}, est postdominé
+ par \n{b},
+ \item et \n{a} n'est pas postdominé par \n{b}.
+\end{itemize}
+\end{definition}
+
+Ce qui signifie que~:
+\begin{itemize}
+ \item plusieurs chemins partent de \n{a},
+ \item qu'il existe un chemin qui passe par \n{b},
+ \item et qu'il existe aussi un chemin qui ne passe pas par \n{b}
+ (sinon, \n{a} serait postdominé par \n{b}).
+\end{itemize}
+
+Ce qui conduit à une autre
+définition, équivalente à la précédente~:
+
+\begin{definition}{dépendance de contrôle}
+ Une instruction \n{b} a une {\bf dépendance de contrôle} vis à vis de \n{a} si~:
+\begin{itemize}
+ \item \n{b} postdomine certains successeurs de \n{a},
+ \item \n{b} ne postdomine pas tous les successeurs de \n{a}.
+\end{itemize}
+\end{definition}
+
+Pour calculer le CDG, l'algorithme de référence est le suivant~:
+
+\begin{algo}{calcul du CDG selon \cite{Ferrante87}}
+\begin{itemize}
+\item soit ACFG le CFG (+ START et {\sc stop}) dans lequel sont ajoutés~:
+ \begin{itemize}
+ \item un noeud ENTRY,
+ \item une arrête (ENTRY,START),
+ \item une arrête (ENTRY,
+ {\sc stop}),
+ \end{itemize}
+\item soit S l'ensemble des arrêtes (\n{a},\n{b}) de ACFG
+ telles que \n{b} ne postdomine pas \n{a}, \\
+ (c'est-à -dire les arrêtes partant des noeuds \n{a} qui ont plusieurs successeurs)
+\item soit \n{l} le plus petit ancêtre commun à \n{a} et \n{b} dans PDT\\
+ (on peut montrer que soit \n{l}=\n{a}, soit \n{l} est le père de \n{a} dans PDT)
+ \begin{itemize}
+ \item si \n{l} est le père de \n{a} dans PDT, tous les noeuds du PDT sur le chemin
+ entre \n{l} et \n{b} (\n{b} compris, mais pas \n{l}) dépendent de \n{a},
+ \item si \n{l} = \n{a}, tous les noeuds du PDT sur le chemin
+ entre \n{a} et \n{b} (\n{a} et \n{b} compris) dépendent de \n{a}.
+ \end{itemize}
+\end{itemize}
+En fait, il est plus simple de dire que tous les noeuds du PDT sur le chemin
+entre \n{b} et le père de \n{a} (\n{b} compris, mais pas le père de \n{a}) dépendent de
+\n{a}.
+\end{algo}
+
+La relation de dépendance étant transitive, on peut choisir de calculer
+uniquement les dépendances directes ou d'inclure les dépendances indirectes.
+
+\begin{exemple}
+\begin{tabular}{m{8cm}m{4cm}}
+ Dans le CFG ci-contre, \n{b} a bien une dépendance de contrôle sur \n{a}.
+ On remarque que, par contre, Z1 ou Z2 ne dépendent pas directement de \n{a},
+ car ils ne postdominent pas S2. En revanche, il y a néanmoins une dépendance
+ indirecte, comme on pouvait s'y attendre, car Z dépend de \n{a}, et Z1 et Z2
+ dépendent de Z.
+&
+\includegraphics[width=0.3\textwidth]{ctrl-dpds}
+\end{tabular}
+\end{exemple}
+
+En fait, \n{a} dépend directement de c si
+\n{a} est forcement atteint si on passe par l'un des successeurs de c,
+mais il y a des chemins qui partent de c et qui ne passe pas pas \n{a}.
+
+\subsection{Cas particuliers}
+
+Ce qui a été présenté ci-dessus s'applique bien à des programmes bien
+structurés, mais nécessite des adaptations si on s'intéresse~:
+
+\begin{itemize}
+ \item aux instructions qui modifie le flot de contrôle telles que les sauts,
+ \item aux CFG qui contiennent des noeuds pour lesquels il n'y a pas de chemin
+ vers le noeud de sortie.
+\end{itemize}
+
+Nous allons étudier plus précisément ces deux points ci-dessous.
+
+\section{Nos définitions}
+
+\subsection{Chemins}
+
+Dans ce qui suit, on utilise beaucoup la notion de \indexdef{chemin}~:
+un chemin est une liste de noeuds du CFG telle que si deux noeuds \n{a} et \n{b}
+se suivent dans la liste, \n{b} est un successeur de \n{a}.
+Nous appelons \indexdef{trace} un chemin qui se termine par un noeud
+n'ayant pas de successeur, ou un chemin qui est infini.
+
+On définit quelques notations pour désigner les chemins~:
+\begin{itemize}
+ \item $\ch{a, b}$ un chemin allant de \n{a} Ã \n{b}
+ \item $\mch{a, b}$ une trace partant de \n{a} et passant par \n{b}
+ \item $\mch{a, -}$ une trace partant de \n{a},
+ \item $\ch{a, b, c}$ un chemin allant de \n{a} Ã \n{c} en passant par \n{b},
+ \item $\ch{a;s, b}$
+ un chemin allant de \n{a} Ã \n{b} en passant par $\n{s} \in \succ{a}$,
+ \item $\mch{a, \neg b}$
+ une trace partant de \n{a} et ne passant pas par \n{b},
+\end{itemize}
+et des ensembles de chemins :
+\begin{itemize}
+ \item $\allmch{a, -}$ toutes les traces partant de \n{a},
+ \item $\allmch{a, b}$ toutes les traces partant de \n{a} et passant
+ par \n{b},
+ \item ...
+\end{itemize}
+
+On dit qu'un noeud appartient à un chemin, et on écrit - un peu abusivement -
+$\n{x} \in \ch{a, b}$ si \n{x} apparaît au moins une fois
+dans la liste qui décrit le chemin.
+
+\subsection{Postdominateurs}
+
+Avec les notations ci-dessus,
+on peut définir \Pd{a} l'ensemble des postdominateurs de \n{a},
+de la façon suivante~:
+$$
+ \n{b} \in \Pd{a} \define \forall t \in \allch{a, \nE}, \n{b} \in t
+$$
+
+On remarque que si on applique la définition ci-dessus à un CFG
+qui contient des noeuds tels qu'il n'y a pas de chemin vers la sortie,
+on a ~:
+$$
+\forall \n{a}, \allch{a, \nE} = \emptyset \impl \forall \n{b}, \n{b} \in \Pd{a}
+$$
+c'est-à -dire que l'on considère que de tels noeuds sont postdominés par tous les
+autres, ce qui n'est pas très intéressant en terme de trace d'exécution~!\\
+
+Dans ce qui suit, on note \P{a} l'ensemble des noeuds qui sont forcement
+atteints quand on passe par \n{a},
+et nous laisserons volontairement cette notion
+un peu floue pour l'instant. Sa définition sera précisée en \S\ref{sec-pda}.
+
+\subsection{Dépendances de contrôle} \label{sec-dpdc-if}
+
+On définit \D{c}{s} comme
+l'ensemble des noeuds qui sont forcement atteints si on passe par
+\n{s}, mais pas forcement si on passe par \n{c}.
+Plus formellement~:
+$$
+\D{c}{s} = \P{s} - \P{c}
+$$
+Par exemple, dans une séquence simple, si \n{c} représente un
+\verbtt{if} et \n{s} la première instruction de l'une des branche, \D{c}{s}
+donne les instructions de cette branche qui dépendent de la condition.\\
+
+On définit alors $\dpdc{a}$,
+l'ensemble des dépendances de contrôle de \n{a}, par~:
+$$
+\n{c} \in \dpdc{a} \define \n{a} \in \bigcup_{ \n{s} \in \succ{c}} \D{c}{s}
+$$
+Il est sans doute plus naturel de définir \codpdc{c},
+l'ensemble des co-dépendances de contrôle de \n{c},
+comme l'ensemble des noeuds ayant une dépendance de contrôle sur \n{c},
+c'est-Ã -dire~:
+$$
+ \n{a} \in \codpdc{c} \define \n{c} \in \dpdc{a}
+$$
+On a alors~:
+$$
+\codpdc{c} = \bigcup_{ \n{s} \in \succ{c}} \D{c}{s}
+$$
+
+
+On remarque que cette définition ne suppose pas que \n{c} ait plusieurs
+successeurs, mais si \n{c} n'a qu'un successeur \n{s}~:
+$$
+\succ{c} = \{ \n{s} \} \impl
+\codpdc{c} = \{\n{x} | (\exists t \in \allmch{c, -}, \n{x} \notin t)
+\et (\forall t \in \allmch{s, -}, \n{x} \in t) \}
+$$
+or, comme \n{c} n'a qu'un successeur~:
+$$
+\forall t \in \allmch{c, -}, t = \mch{c; s, -}
+$$
+donc~:
+$$
+\forall t_s \in \allmch{s, -}, \n{x} \in t_s
+\impl \forall t_c \in \allmch{c, -}, \n{x} \in t_c
+$$
+$$
+\forall t_s \in \allmch{s, -}, \n{x} \in t_s
+\impl \nexists t_c \in \allmch{c, -}, \n{x} \notin t_c
+$$
+et donc, finalement~:
+$$
+\succ{c} = \{ \n{s} \} \impl \codpdc{c} = \{\}
+$$
+Donc, un noeud n'ayant qu'un seul successeur ne peut pas être une dépendance de
+contrôle. {\bf Attention}~: ceci n'est pas vrai pour les saut inconditionnels,
+car ceux-ci donne lieu à un traitement spécial décrit en \S\ref{sec-goto}.
+
+
+\section{Les sauts inconditionnels}\label{sec-goto}
+
+\subsection{Présentation du problème}
+
+Comme on l'a vu,
+la définitions précédente des dépendances de contrôle conduit Ã
+ne construire des dépendances que sur les noeuds ayant plusieurs successeurs,
+c'est-à -dire ceux qui présente une forme de choix dans le CFG.
+Or certaines instructions n'ayant qu'un successeur
+peuvent aussi, par leur présence, modifier le flot de contrôle.
+En C, c'est le cas par exemple des \verbtt{goto} explicites,
+mais aussi des \verbtt{break}, \verbtt{continue} ou \verbtt{return}.
+Dans CIL, c'est aussi le cas des boucles puisqu'elles sont toutes transformées
+en \verbtt{while(1)}.
+
+Lorsque l'on souhaite utiliser le CDG pour calculer une réduction,
+on aimerait
+qu'il contienne également les liens nécessaires sur ces instructions
+afin de déterminer si elles peuvent être supprimées,
+ou si elles doivent être présentes dans le programme réduit.\\
+
+L'exemple simple suivant, tiré de \cite{Choi94}, met en évidence ce problème~:
+
+\begin{exemple}
+\begin{tabular}{m{4cm}m{5cm}}
+\begin{clisting}
+1 : <entry>
+2 : if (Q) goto 5;
+3 : x = 4;
+4 : goto 6;
+5 : x = 5;
+6 : y = x;
+7 : <exit>
+\end{clisting}
+&
+\includegraphics[width=0.5\textwidth]{ex-goto}
+\end{tabular}
+
+\begin{tabular}{p{5cm} p{7cm}}
+Réduction (fausse) \\
+par rapport à <y,7>~:
+\begin{clisting}
+1 : <entry>
+2 : if (Q) goto 5;
+3 : x = 4;
+
+5 : x = 5;
+6 : y = x;
+7 : <exit>
+\end{clisting}
+&
+On voit que dans le graphe de dépendances (PDG), personne ne dépend de 4,
+et la réduction de ce programme par rapport au noeud 6 donne le résultat
+erroné ci-contre qui donne \verbtt{y=5} même lorsque $Q$ est faux.
+\end{tabular}
+\end{exemple}
+
+\subsection{Etat de l'art}
+
+La plupart des solutions proposées pour résoudre ce problème
+utilisent la notion de \indexdef{successeur lexical} (sous différents noms).
+
+\begin{definition}{successeur lexical immédiat selon \cite{agrawal94slicing}}
+A statement, S', is said to be {\bf the immediate lexical successor}
+of a statement, S, in a program, if deleting S from the program
+will cause the control to pass to S'
+whenever it reaches the corresponding location in the new program.
+
+If is a compound statement,
+such as an If or a While statement, delleting means
+delleting it allong with the statements that constitute its body.\\
+\end{definition}
+
+\cite{Choi94} présente une méthode qui ajoute un pseudo-lien dans le CFG
+entre les \verbtt{goto} et leur successeur lexical immédiat,
+et qui se sert de ce CFG modifié pour calculer les dépendances
+de contrôle selon la méthode classique.
+En fait, c'est un peu comme s'il remplaçait les \verb!goto L;!
+par \verbtt{if (1) goto L;} pour mettre en évidence le chemin
+qui apparaît dans le CFG si on supprime l'instruction.\\
+
+
+\cite{agrawal94slicing} donne un algorithme qui permet de traiter
+les \verbtt{goto} après un \slicing{} "normal".
+Il s'agit, pour chaque \verbtt{goto} (G) non visible,
+de déterminer si son premier postdominateur
+présent dans la réduction est différent du premier successeur lexical.
+Si c'est le cas, il faut rentre (G) visible ainsi que toutes ses dépendances.
+Ceci donne les mêmes résultats que l'algorithme précédent,
+mais il permet de ne modifier ni le CFG, ni le PDT.
+Par contre, le calcul doit être fait pour chaque réduction.\\
+
+\cite{harman98new} propose un algorithme qui donne des résultats
+plus précis que les deux précédents dans certains cas.\\
+
+Enfin, \cite{kumar02better} présente un algorithme qui prend
+en compte le problème spécifique des \verbtt{switch} et donne
+également de meilleurs résultats sur certains exemples.
+
+\subsection{Discussion}\label{sec-dpdc-goto}
+
+Dans un premier temps, l'algorithme de \cite{Choi94} semble simple Ã
+implémenter, mais il nous oblige à calculer un nouveau CFG et le PDT
+correspondant, ce que nous ne souhaitons pas faire car ces informations sont
+utilisées par différents modules de l'outil.
+Par ailleurs, l'algorithme de \cite{agrawal94slicing}
+est à appliquer à chaque nouvelle réduction, ce qui n'est pas très intéressant
+dans un environnement interactif, d'autant plus que l'on peut vouloir utiliser
+les dépendances de contrôle pour autre chose que le \slicing.\\
+
+Voyons donc plus précisément ce que l'on veut obtenir~:
+
+\begin{monenv}{Le problème}
+ \begin{tabularx}{\linewidth}{p{2cm}X}
+ \begin{center}
+ \includegraphics[width=1.5cm]{goto}
+ \end{center}
+&
+\begin{itemize}
+\item soit un programme P,
+\item soit \n{g} un noeud du CFG de P correspondant à un \verbtt{goto},
+\item soit \n{l} le noeud correspondant au successeur de \n{g} (label du \verbtt{goto}),
+\item soit P', le programme P dans lequel on remplace le \verbtt{goto}
+par un ';' (NOP),
+\item soit \n{g}' le noeud correspondant dans le CFG de P',
+\item soit \n{s} le successeur lexical de \n{g}.
+\end{itemize}
+\bigskip
+On veut qu'un noeud \n{a} ait une dépendance de contrôle sur \n{g}
+\ssi \n{a} postdomine soit \n{g}, soit \n{s}, mais pas les deux.
+\end{tabularx}
+\end{monenv}
+Examinons les différents cas~:
+\begin{enumerate}
+ \item si \n{s}=\n{l}, cela signifie que le \verbtt{goto} ne sert à rien,
+ personne ne dépend donc de \n{g},
+ \item si \n{l} postdomine \n{s}, \n{s} dépend de \n{g}, ainsi que tous les postdominateurs
+ de \n{s} qui ne postdomine pas \n{l},
+ \item si \n{l} ne postdomine pas \n{s},
+ tous les \n{a} qui postdominent \n{s}, mais pas \n{l} ou l'inverse, dépendent de \n{g}.
+\end{enumerate}
+
+Donc, de manière générale, on peut calculer~:
+$$
+ \codpdc{g} = (\P{s} \cup \P{l}) - (\P{s} \cap \P{l})
+$$
+ce qui nous donne bien les noeuds atteints par l'une ou l'autre des branches,
+mais pas par les deux.
+
+On peut d'ailleurs montrer qu'on obtient la même chose que si on calcule \codpdc{g^*}
+sur CFG$^*$ où CFG$^*$ est le CFG dans lequel le noeud \n{g} est remplacé par un
+noeud \n{g^*} correspondant à une instruction
+\verbtt{if (true) goto L;}\\
+
+
+
+\section{Boucle infinie et exit}
+
+Comme on l'a vu,
+la plupart des définitions de dépendance de contrôle se basent
+sur le CFG, la notion de postdominateurs, et utilisent l'hypothèse
+que le CFG a un unique noeud de sortie \nE{} atteignable depuis tous les
+autres points du graphe. Or, comme l'explique très bien \cite{ranganath04new},
+cette hypothèse ne tient plus dans les programmes contenant
+des boucles infinies ou des \verbtt{exit} (ou même des exceptions,
+mais pour le langage C, nous n'avons pas le problème).
+Cet article présente également avec beaucoup de détails
+différents types de dépendances et des algorithmes pour les calculer,
+mais il s'avère probablement trop complexe pour ce que l'on souhaite faire.\\
+
+Le fait qu'une fonction n'atteigne pas forcement un point de sortie pose deux
+problèmes différents~:
+\begin{itemize}
+ \item la préservation de la non-terminaison,
+ \item le calcul des dépendances de contrôle pour les instructions
+ n'ayant pas de chemin vers la sortie.
+\end{itemize}
+
+\subsection{Préservation de la non-terminaison}
+
+La question qui se pose est de savoir s'il faut ajouter des dépendances de
+contrôle sur les instructions qui, potentiellement, ne terminent pas.
+
+\begin{exemple}
+ \begin{tabular}{p{4.5cm}p{\linewidth-5.5cm}}
+\begin{clisting}
+while (f(x) > 0) x++;
+L: y = 3;
+\end{clisting}
+&
+Si l'on s'intéresse au calcul de {\tt y} en {\tt L}, on peut se demander si
+cette instruction a une dépendance de contrôle sur la boucle,
+car si dans certains cas, la boucle ne termine pas,
+{\tt L} n'est pas atteint le même nombre de fois
+dans le programme source P, et dans le programme P' dans lequel la boucle est
+remplacée par un NOP.
+
+\end{tabular}
+\end{exemple}
+
+Pour prendre en compte ce type de problème et permettre d'effectuer par la suite
+des analyses sensibles à la non-terminaison ({\it non-terminaison sensitive}),
+il faut ajouter des dépendances à toutes les instructions qui suivent
+une construction qui peut ne pas terminer comme un appel de fonction,
+ou une boucle dont on ne sait pas déterminer la terminaison.
+Dans l'absolu, il faudrait aussi s'intéresser aux autres instructions qui ont
+une terminaison anormale (\verbtt{Segmentation Fault} par exemple) mais il semble
+raisonnable de considérer que ces instructions ne sont jamais présentes exprès,
+et que leur absence doit être vérifiée par ailleurs.
+
+\subsection{Postdominateurs généralisés}
+
+\subsubsection{Définition}
+
+En cas de boucle infinie, le CFG contient des noeuds pour lesquels
+il n'existe pas de chemin vers la sortie.
+Or, pour un tel noeud \n{a},
+les postdominateurs tels que définis plus haut me peuvent pas être utilisé
+pour déterminer les dépendances de contrôle.
+En effet, on ne peut pas parler des instructions qui vont être
+forcement exécutées entre \n{a} et \nE{} car il n'existe pas de telles traces.\\
+
+La plupart des travaux existants travaillent dans ce cas sur un CFG augmenté
+dans lequel le noeud \nE{} est ajouté, ainsi que des arrêtes pour le rendre
+accessible. Outre le fait que certaines analyses n'aient pas besoin de cette
+hypothèse, et qu'une telle modification vienne ``polluer'' le CFG,
+il semble difficile (impossible ?) de ne pas ajouter
+de dépendances parasites dans le cas des boucles infinies.\\
+
+Pourtant, même si \n{a} est dans une boucle infinie,
+on a intuitivement une notion de postdominateurs. On aimerait bien dire
+qu'une instruction \n{b} postdomine une instruction \n{a} \ssi \n{b} appartient
+Ã tous les chemins {\bf partant de \n{a}}, c'est-Ã -dire~:
+
+\begin{definition}{postdominateurs généralisés}
+$$ \n{b} \in \Pdi{a} \define \forall t \in \allmch{a, -}, \n{b} \in t $$
+\end{definition}
+
+
+On ne considère donc plus uniquement les chemins qui atteignent la sortie,
+mais toutes les traces d'exécution possible.
+
+
+\subsubsection{Méthode de calcul}
+
+
+Intuitivement, si on souhaite connaître tous les noeuds qui ont b comme
+postdominateurs en considérant tous les chemins,
+on peut calculer les ensembles suivants~:
+$$
+E_b (a) = \left\{
+\begin{array}{ll}
+ {b} & \text{si } b = a\\
+ \bigcap_{s \in \succ{a}} E_b(s) & \text{sinon.}
+\end{array}\right.
+$$
+en partant d'ensembles initialement vides.
+Ce calcul termine car il est croissant.
+
+A la fin du calcul, on a :
+$$
+ \forall b, E_a (b) = \{ a \} \vee E_a (b) = \bot
+$$
+et $E_a (b) = \{ a \}$ veut bien dire que $a$ est dans tous les chemins entre
+$b$ et $a$.\\
+
+On peut faire ce calcul pour tous les points du CFG, et faire l'union de tous
+les résultats obtenus~:
+$$
+\Pdi(a) = \bigcup_{b \in CFG} E_b(a)
+$$
+Bien sûr, ce n'est pas la manière la plus efficace de faire le calcul,
+mais on voit trivialement que c'est le résultat que l'on souhaite obtenir.\\
+
+Il suffit maintenant de trouver un calcul équivalent,
+moins coûteux, mais qui termine néanmoins...
+
+En fait, il suffit de faire directement
+l'union des résultats au fur et à mesure du calcul,
+mais comment prouver la terminaison~?
+
+\subsubsection{Discussion}
+
+On remarque que cette définition ne donne pas
+les mêmes postdominateurs que précédemment
+dès qu'il y a une boucle dans le CFG, même qui la sortie \nE{} est accessible
+depuis tous les noeuds,
+car il existe alors un chemin possible qui consiste à boucler indéfiniment.
+Par conséquent, les instructions situées après la boucle ne postdomine pas les
+instructions de la boucle puisqu'il existe un chemin pour lequel on y passe pas.
+Cela traduit le fait que l'exécution de ces instructions dépend du fait que la
+boucle termine...
+
+Si on utilise cette définition des postdominateurs pour calculer des dépendances
+de contrôle, on va donc ajouter des liens entre la boucle et tout ce qui suit.
+Ces nouvelles dépendances traduisent la possible non-terminaison de la boucle,
+et peuvent donc servir dans le cadre d'une analyse préservant la non-terminaison
+comme on l'a vu précédemment.
+Mais on ne souhaite pas nécessairement ajouter toutes ces dépendances,
+car en pratique, on peut montrer par ailleurs que la plupart des boucles
+d'un programme terminent.
+
+\subsection{Postdominateurs augmentés}\label{sec-pda}
+
+On peut essayer de faire un mélange des postdominateurs classiques et des
+postdominateurs généralisés en supposant que toutes les boucles ayant une
+sortie se terminent (attention : on considère pour l'instant qu'il y a un chemin
+possible entre cette sortie et \nE), mais en considérant néanmoins
+les traces infinies dans les cas où une boucle n'a pas de sortie.
+
+\begin{definition}{postdominateurs augmentés}
+$$
+\Pda{a} = \left\{
+\begin{array}{ll}
+\{ b | \forall t \in \allmch{a, -}, b \in t \}
+ & \text{si } \allch{a, \nE} = \{\}\\
+\{ b | \forall t \in \allmch{a, \nE}, b \in t \}
+ & \text{sinon.}
+\end{array}\right.
+$$
+\end{definition}
+
+
+\subsubsection{Méthode de calcul}
+
+\newcommand{\ToRet}[1]{\ensuremath{\mathit{ToRet}(\n{#1})}}
+
+Pour faire ce calcul, il faut être capable de distinguer les chemins qui mènent
+Ã \nE{} des autres.
+On note \ToRet{a} la propriété qui dit que \n{a} a un chemin vers \nE.
+
+Après un calcul classique des postdominateurs (en partant de \nE),
+les postdominateurs des noeuds tels que \ToRet{a} sont établis.
+Reste à calculer l'information pour les autres noeuds, c'est-à -dire ceux qui
+ont les postdominateurs à $\top$.
+
+Pour ceux-là , on fait un calcul similaire~:
+$$
+\Pda{x} = \{\n{x}\} \bigcup \bigcap^a_{s \in \succ{x}} \Pda{s}
+$$
+en redéfinissant simplement l'intersection utilisée de la façon suivante~:
+$$
+\Pda{a} \cap^a \Pda{b} = \left\{
+\begin{array}{ll}
+ \Pda{a} \cap \Pda{b} & \text{si } \ToRet{a} = \ToRet{b}\\
+ \Pda{a} & \text{si } \ToRet{a} \et \neg\ToRet{b}\\
+ \Pda{b} & \text{si } \neg\ToRet{a} \et \ToRet{b}\\
+\end{array}\right.
+$$
+
+
+\subsubsection{Discussion}
+
+On remarque qu'avec cette définition, il existe des noeuds \n{a} tels que~:
+$$
+\succ{a} = \{\n{s1}, \n{s2}\} \et \Pda{a} \neq \Pda{s1} \cap \Pda{s2}
+$$
+dans le cas où on atteint la sortie à partir de l'un des successeurs, mais pas
+de l'autre.
+
+Par exemple, si on considère un noeud \n{c} correspondant à un {\sc IF}
+dont l'une des branche est une boucle infinie et que l'autre permet d'atteindre
+la sortie, la boucle infinie dépendra de \n{c}, alors que l'accès à la sortie
+n'en dépendra pas.
+
+
+\section{En résumé}
+
+Pour calculer les dépendances de contrôle, on commence donc par calculer les
+postdominateurs augmentés définis en \S\ref{sec-pda}.
+Puis, pour chaque saut, on calcule ses co-dépendances de contrôle de la façon
+suivante~:
+
+\begin{itemize}
+ \item pour un {\sc IF},
+ on applique la définition donné en \S\ref{sec-dpdc-if},
+ c'est-Ã -dire~:
+$$
+\codpdc{c} = \bigcup_{ \n{s} \in \succ{c}} \Pda{s} - \Pda{c}
+$$
+
+ \item pour un saut inconditionnel (\verbtt{goto}, \verbtt{break}, etc),
+ comme mentionné en \S\ref{sec-dpdc-goto}, on calcule~:
+$$
+\codpdc{g} = (\Pda{s} \cup \Pda{l}) - (\Pda{s} \cap \Pda{l})
+\text{ où } \left\{\begin{array}{l}
+\n{s} = \succl{g} \\
+\n{l} = \succ{g}
+\end{array}\right.
+$$
+Si on considère \n{s} et \n{l} comme deux pseudo-successeurs de \n{g},
+les pseudo-postdominateurs de \n{g} sont donnés par
+$(\Pda{s} \cap \Pda{l})$, et on retrouve bien la formule précédente.
+
+ \item pour les boucles, comme dans CIL, elles sont toutes infinies,
+on traite la séquence \verbtt{while(1) S;}
+comme si on avait \verbtt{L : S; goto L;}
+
+\end{itemize}
diff --git a/doc/pdg/data.tex b/doc/pdg/data.tex
new file mode 100644
index 0000000000000000000000000000000000000000..4cee0f9f7a085c2caeccefe1d805e5b3cca092cc
--- /dev/null
+++ b/doc/pdg/data.tex
@@ -0,0 +1,138 @@
+\chapter{Dépendances liées aux données}
+
+Le calcul de dépendances de données et d'adresse consiste principalement
+à retrouver les éléments de flot correspondant aux données utilisées dans les
+expressions.
+Mais comme les données peuvent être incluses les unes dans les
+autres, il ne suffit pas de retrouver les éléments de flot qui calculent
+exactement ces données, mais aussi ceux qui ont une intersection possible.
+
+Par exemple, dans la séquence~:\\
+ \centerline{\verbtt{d = d0; x = d.a;}}
+
+il faut être capable de voir que \verbtt{x} dépend de \verbtt{d0}.
+
+Autre exemple~: dans la séquence~:\\
+\centerline{\verbtt{d0.a = a; d0.b = b; d = d0;}}
+
+il faut voir que \verbtt{d} dépend éventuellement de la valeur initiale de \verbtt{d0}
+(si \verbtt{d0} contient d'autres champs que \verbtt{.a} et \verbtt{.b}), mais aussi
+de \verbtt{a}, et de \verbtt{b}.\\
+
+\section{Recherche arrière}
+
+Le premier calcul mis en {\oe}uvre procédait par recherche en arrière
+des éléments de la table ayant une intersection avec les données présentes en
+partie droite de l'instruction. Mais cette recherche était compliquée en cas de
+dépendances partielles comme dans le second exemple ci-dessus. Cette solution a
+donc été abandonnée.
+
+\section{Propagation avant d'un état}\label{sec-propagation-etat}
+
+La méthode finalement choisie pour calculer ces dépendances
+consiste à propager en avant, par une analyse du type flot de données,
+un \indexdef{état des données}
+qui contient pour chaque donnée, une liste de liens vers les éléments
+du graphe qui ont permis de déterminer sa valeur en ce point.
+
+Cet état doit avoir les propriétés suivantes~:
+\begin{itemize}
+\item on veut pouvoir associer un nouveau noeud à une donnée
+en précisant s'il faut faire l'union avec l'ensemble précédemment stocké.
+Par exemple~;
+\begin{itemize}
+\item pour l'instruction \verbtt{x = 3;} on construit un nouvel élément
+dans le PDG, et on mémorise dans l'état que \verbtt{x} est maintenant associé
+à cet élément. L'ancienne association est perdue.
+\item pour l'instruction \verbtt{*p = 3;} si \verbtt{p} peut pointer sur \verbtt{x},
+il faut mémoriser que \verbtt{x} peut être défini par l'élément du PDG
+correspondant, mais comme ce n'est pas sûr, il faut faire l'union avec
+ce qui était précédemment stocké pour \verbtt{x}.
+\end{itemize}
+\item lorsque l'on demande l'ensemble associé à une donnée,
+le résultat doit contenir au moins ce qu'on a stocké
+(il peut contenir plus d'élément en cas de perte de précision),
+\item la consultation ne doit pas modifier l'état,
+\item il faut savoir faire l'union de deux états.
+\end{itemize}
+
+La structure de donnée du module \verbtt{Lmap} de \ppc correspond à ces critères,
+et peut donc être utilisée pour ce calcul.\\
+
+\section{Propagation arrière d'un état}
+
+Une autre solution aurait pu être de propager en arrière
+un état contenant les utilisations
+de variables, et mettre à jour le graphe en rencontrant la définition.
+Le coût de ce calcul semble être le même que le précèdent,
+mais la propagation avant nous permet d'avoir, Ã chaque point de programme,
+un état donnant la correspondance entre une donnée et les éléments du graphe,
+même si cette donnée n'est pas utilisée à ce point.
+Cette information nous permet par la suite de définir des critères
+de \slicing moins restrictifs.
+
+\section{Traitement de l'affectation}
+
+Le principe de l'algorithme du traitement d'une affectation
+\verbtt{lval = exp;} est donc le suivant~:
+
+\begin{itemize}
+\item recherche des données $\{d_v\}$
+utilisées dans \verbtt{exp} à l'aide des résultats de l'analyse d'alias préalable,
+\item calcul de {\it dpdv},
+c'est-à -dire l'union des ensembles associées à ces données $d_v$ dans l'état,
+\item recherche des données $\{d_a\}$
+utilisées pour calculer l'adresse de {\it lval},
+\item calcul de {\it dpda}
+c'est-à -dire l'union des ensembles associées à ces données $d_a$ dans l'état,
+\item recherche de l'élément $e$
+correspondant à cette instruction dans le graphe,
+ et création de cet élément s'il n'existe pas,
+\item ajout des dépendances {\it dpdv} et {\it dpda} à $e$,
+\item recherche des données $\{d_x\}$
+potentiellement modifiées par cette affectation,
+\item calcul du nouvel état (après l'instruction)
+en ajoutant dans l'ancien état un lien entre les $\{d_x\}$ et $e$.
+\end{itemize}
+
+\section{Déclarations}
+
+Les déclarations de variable doivent être traitées séparément
+des valeurs, car on peut parfois dépendre de l'adresse d'une variable
+sans dépendre de ce qu'elle contient.
+
+C'est par exemple le cas lorsque la variable apparaît à gauche
+d'une affectation (\verbtt{x = 3;})
+ou encore quand on n'utilise que son adresse (\verbtt{p = \&x;}).
+
+On garde donc une table qui permet de retrouver les éléments
+du graphe de dépendances qui correspondent aux déclarations.
+
+
+\section{Calcul de conditions}
+
+Les noeuds du graphe de dépendances représentant
+les calculs de condition des \verbtt{if} ou \verbtt{switch}
+ont des dépendances de donnée sur les données utilisées.
+
+\section{Dépendances de donnée dans les boucles}
+
+Pour les boucles {\it explicites}, il suffirait d'effectuer deux tours
+de la boucle pour obtenir toutes les dépendances de donnée car le premier
+capture les dépendances avec les données provenant d'avant la boucle,
+ou interne à un tour, et le second capture les dépendances entre un tour et le
+suivant.
+
+Mais comme les boucles peuvent être introduites par la présence de sauts
+quelconques,
+le plus simple est dans un premier temps d'itérer jusqu'à obtenir un point fixe
+sur l'état des données. Il faut noter que les noeuds ne sont créés que lors de la
+première itération, les suivantes n'ajoutant que de nouvelles dépendances entre
+ces noeuds. Le nombre de noeuds étant fini (de l'ordre de grandeur du nombre
+d'instruction de la fonction), l'atteignabilité du point fixe est
+garantie.
+
+\section{Appels de fonction}
+
+Le traitement des appels de fonction est présenté
+dans le chapitre \ref{sec-intro-call}
diff --git a/doc/pdg/ex-goto.fig b/doc/pdg/ex-goto.fig
new file mode 100644
index 0000000000000000000000000000000000000000..aa846c27d6b2dfef2503555170d7640267570887
--- /dev/null
+++ b/doc/pdg/ex-goto.fig
@@ -0,0 +1,113 @@
+#FIG 3.2
+Landscape
+Center
+Metric
+A4
+100.00
+Single
+-2
+1200 2
+6 3195 2160 8010 5130
+6 3195 2385 4950 4950
+6 3195 2385 3780 2790
+1 1 0 1 0 7 50 -1 -1 0.000 1 0.0000 3465 2565 270 180 3465 2565 3735 2745
+4 1 0 50 -1 0 12 0.0000 4 150 390 3465 2610 entry\001
+-6
+6 3195 3105 3780 3510
+1 1 0 1 0 7 50 -1 -1 0.000 1 0.0000 3465 3285 270 180 3465 3285 3735 3465
+4 1 0 50 -1 0 12 0.0000 4 135 90 3465 3330 2\001
+-6
+6 3195 3825 3780 4230
+1 1 0 1 0 7 50 -1 -1 0.000 1 0.0000 3465 4005 270 180 3465 4005 3735 4185
+4 1 0 50 -1 0 12 0.0000 4 135 90 3465 4050 5\001
+-6
+6 4365 3105 4950 3510
+1 1 0 1 0 7 50 -1 -1 0.000 1 0.0000 4635 3285 270 180 4635 3285 4905 3465
+4 1 0 50 -1 0 12 0.0000 4 135 90 4635 3330 3\001
+-6
+6 4365 3825 4950 4230
+6 4590 3915 4680 4050
+4 1 0 50 -1 0 12 0.0000 4 135 90 4635 4050 4\001
+-6
+1 1 0 1 0 7 50 -1 -1 0.000 1 0.0000 4635 4005 270 180 4635 4005 4905 4185
+-6
+6 3195 4545 3780 4950
+1 1 0 1 0 7 50 -1 -1 0.000 1 0.0000 3465 4725 270 180 3465 4725 3735 4905
+4 1 0 50 -1 0 12 0.0000 4 135 90 3465 4770 6\001
+-6
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ 3465 2745 3465 3105
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ 3465 3465 3465 3825
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ 3465 4185 3465 4545
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ 4635 3465 4635 3825
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ 3735 3285 4365 3285
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ 4545 4185 3735 4725
+-6
+6 5715 2385 7470 4950
+6 5715 2385 6300 2790
+1 1 0 1 0 7 50 -1 -1 0.000 1 0.0000 5985 2565 270 180 5985 2565 6255 2745
+4 1 0 50 -1 0 12 0.0000 4 150 390 5985 2610 entry\001
+-6
+6 5715 3105 6300 3510
+1 1 0 1 0 7 50 -1 -1 0.000 1 0.0000 5985 3285 270 180 5985 3285 6255 3465
+4 1 0 50 -1 0 12 0.0000 4 135 90 5985 3330 2\001
+-6
+6 5715 3825 6300 4230
+1 1 0 1 0 7 50 -1 -1 0.000 1 0.0000 5985 4005 270 180 5985 4005 6255 4185
+4 1 0 50 -1 0 12 0.0000 4 135 90 5985 4050 5\001
+-6
+6 6885 3105 7470 3510
+1 1 0 1 0 7 50 -1 -1 0.000 1 0.0000 7155 3285 270 180 7155 3285 7425 3465
+4 1 0 50 -1 0 12 0.0000 4 135 90 7155 3330 3\001
+-6
+6 5715 4545 6300 4950
+1 1 0 1 0 7 50 -1 -1 0.000 1 0.0000 5985 4725 270 180 5985 4725 6255 4905
+4 1 0 50 -1 0 12 0.0000 4 135 90 5985 4770 6\001
+-6
+6 6885 3825 7470 4230
+6 7110 3915 7200 4050
+4 1 0 50 -1 0 12 0.0000 4 135 90 7155 4050 4\001
+-6
+1 1 0 1 0 7 50 -1 -1 0.000 1 0.0000 7155 4005 270 180 7155 4005 7425 4185
+-6
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ 5985 2745 5985 3105
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ 5985 3465 5985 3825
+2 1 1 2 0 7 50 -1 -1 4.000 0 0 -1 1 0 2
+ 0 0 1.00 60.00 120.00
+ 5985 4185 5985 4545
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ 6255 3285 6885 3285
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ 6255 3285 7155 3825
+-6
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ 7515 4860 7965 4860
+2 1 1 2 0 7 50 -1 -1 4.000 0 0 -1 1 0 2
+ 0 0 1.00 60.00 120.00
+ 7515 5085 7965 5085
+2 1 1 2 0 7 50 -1 -1 4.000 0 0 -1 1 0 2
+ 0 0 1.00 60.00 120.00
+ 6975 3375 6255 4725
+4 1 0 50 -1 2 12 0.0000 4 135 375 4365 2295 CFG\001
+4 1 0 50 -1 2 12 0.0000 4 135 390 6885 2295 PDG\001
+4 1 0 50 -1 2 10 0.0000 4 150 675 7065 4860 CDG edge\001
+4 1 0 50 -1 2 10 0.0000 4 150 690 7065 5085 DDG edge\001
+-6
diff --git a/doc/pdg/goto.fig b/doc/pdg/goto.fig
new file mode 100644
index 0000000000000000000000000000000000000000..ac14cc5a0d07c360da3514b4e19bb0a49bfe7832
--- /dev/null
+++ b/doc/pdg/goto.fig
@@ -0,0 +1,35 @@
+#FIG 3.2
+Portrait
+Center
+Metric
+A4
+100.000000
+Single
+-2
+1200 2
+0 32 #ffffff
+6 0 0 0 0
+1 1 0 1 32 32 0 0 20 0.000000 1 0.0 5722 1299 767 472 0 0 0 0
+1 1 0 1 0 -1 0 0 -1 0.000000 1 0.0 5722 1299 767 472 0 0 0 0
+4 1 0 0 0 16 22.762205 0.0 6 0.0 0.0 5722 1393 G\001
+-6
+6 0 0 0 0
+1 1 0 1 32 32 0 0 20 0.000000 1 0.0 5090 3622 767 472 0 0 0 0
+1 1 0 1 0 -1 0 0 -1 0.000000 1 0.0 5090 3622 767 472 0 0 0 0
+4 1 0 0 0 16 22.762205 0.0 6 0.0 0.0 5090 3716 S\001
+-6
+6 0 0 0 0
+2 1 0 1 0 0 0 0 -1 0.000000 0 0 0 1 0 4
+ 0 0 3.149606 236.220472 236.220472
+ 6490 1299 6962 1299 6962 5756 6490 5756
+-6
+6 0 0 0 0
+1 1 0 1 32 32 0 0 20 0.000000 1 0.0 5722 5756 767 472 0 0 0 0
+1 1 0 1 0 -1 0 0 -1 0.000000 1 0.0 5722 5756 767 472 0 0 0 0
+4 1 0 0 0 16 22.762205 0.0 6 0.0 0.0 5722 5851 L\001
+-6
+6 0 0 0 0
+2 1 1 1 0 0 0 0 -1 12.598425 0 0 0 1 0 4
+ 0 0 3.149606 236.220472 377.952756
+ 5722 1771 5722 2460 5090 2460 5090 3149
+-6
diff --git a/doc/pdg/impact.tex b/doc/pdg/impact.tex
new file mode 100644
index 0000000000000000000000000000000000000000..0913b6f62d7edd6102b9aa3f8016ed7a20b4da8d
--- /dev/null
+++ b/doc/pdg/impact.tex
@@ -0,0 +1,205 @@
+\chapter{Aide à l'analyse d'impact}\label{sec-impact}
+
+Le document \cite{baudinImpact} spécifie un outil d'aide à l'analyse d'impact
+après avoir analysé les besoins dans ce domaine.
+L'exploitation du graphe de dépendances est présenté comme étant
+un composant important de cet outil.
+Nous reprenons ici les éléments de spécification
+décrits dans le paragraphe 5.3 de ce document,
+auxquels nous ajoutons quelques nouveaux critères.\\
+
+
+\section{Définition d'ensembles}\label{sec-ensembles}\label{sec-defR}
+
+\newcommand{\remitem}[1]{\begin{itemize}\item #1 \end{itemize}}
+\newcommand{\warnitem}[1]{\begin{itemize}\item[$\blacktriangle$] #1
+ \end{itemize}}
+\newcommand{\question}[1]{\begin{itemize}\item[{\bf ?}] #1 \end{itemize}}
+\newcommand{\smilitem}[1]{\begin{itemize}\item[$\smiley$] #1 \end{itemize}}
+\newcommand{\frownitem}[1]{\begin{itemize}\item[$\frownie$] #1 \end{itemize}}
+
+
+Il s'agit de définir des sous-ensembles d'instructions
+répondant à différents critères.
+
+Donnons tout d'abord quelques notations :
+\begin{itemize}
+\item S : un ensemble d'instructions,
+\item L : un point de programme,
+\item V : une zone mémoire (le V se réfère à {\bf V}ariable,
+mais il peut s'agir d'une donnée quelconque comme un champ de structure ou
+un élément de tableau),
+\end{itemize}
+
+Les ensembles sont tous relatifs à un point de programme $L$,
+et peuvent se classer en deux catégories~:
+\begin{itemize}
+\item ceux qui contiennent des instructions situées {\bf avant} $L$~:
+ils portent un indice 0,
+\item et ceux qui contiennent des instructions situées {\bf après} $L$~:
+ils portent un indice 1.\\
+\end{itemize}
+
+\begin{description}
+\item[$R_0(S,L)$] : sous-ensemble d'instructions de S depuis lesquelles
+L est accessible.
+\warnitem{mais L ne postdomine pas forcement toutes les instructions de cet ensemble.}
+
+\item[$R_{1}(S,L)$] : sous-ensemble d'instructions de S
+qui sont (éventuellement) accessibles depuis L.
+
+\item[$R_{L0}(S,L)$] : accessibilité à un point du code.
+\remitem{il s'agit du sous-ensemble des instructions de $R_0(S,L)$
+qui conditionnent le passage en L,
+c'est-Ã -dire les instructions de branchement
+et les dépendances de ces conditions de branchement.
+}
+
+%\item[$R_{L1}(S,L)$] : ?
+
+\item[$R_{V0}(S,L,V)$] : contenu d'une zone mémoire en un point du code.
+\remitem{il s'agit du critère traditionnel de \slicing,
+c'est-Ã -dire que cet ensemble contient les instructions de $S$ qui
+ont une influence sur la valeur de $V$ en $L$.
+}
+
+\item[$R_{V1}(S,L,V)$] : utilisation d'une zone mémoire.
+\remitem{il s'agit du sous-ensemble des instructions de $R_{1}(S,L)$
+influencées par la valeur qu'à la zone mémoire $V$ a en $L$.}
+
+\item[$R_{DV0}(S,L,V)$] : définition de la valeur d'une variable à un point de
+programme.
+\remitem{il s'agit de l'ensemble des instructions qui {\bf définissent}
+tout ou partie de la valeur de $V$ en $L$. Ces instructions
+sont donc nécessairement des affectations ou des appels de fonction.
+
+On note que~: $R_{DV0}(S,L,V) \subseteq R_{V0}(S,L,V)$
+}
+\warnitem{
+Il serait probablement utile d'avoir un élément spécial
+qui indique qu'il existe
+un ou plusieurs chemin menant à $L$ pour le(s)quel(s)
+$V$ n'est pas entièrement défini.
+}
+
+\item[$R_{DV1}(S,L,V)$] : modification de la valeur d'une variable.
+\remitem{il s'agit de trouver les instructions $I_i$ accessibles depuis L
+qui modifient la valeur de $V$,
+et telles qu'il existe un chemin entre $L$ et $I_i$
+le long duquel $V$ n'est pas modifiée.
+Cela signifie que ces instructions sont les premières à modifier la valeur
+de $V$ sur les chemins partant de $L$.}
+\remitem{Il n'est pas sûr que cet ensemble soit très utile.
+L'ensemble $R_{P1}(S,L,V)$ ci-dessous en sans doute plus intéressant.
+}
+
+\item[$R_{P0}(S,L,V)$] :
+portée arrière de la valeur d'une variable à un point de programme.
+\remitem{il s'agit d'un sous-ensemble de $R_{L0}(S,L)$
+contenant les instructions $I_i$ pour lesquelles la valeur de $V$
+n'a été modifiée sur aucun chemin entre le point qui précède $I_i$ et $L$.
+C'est-à -dire que la valeur de $V$ en $L$ est la même qu'avant chacune de ces
+instructions, et qu'elle n'est pas modifiée entre les deux.
+}
+
+\item[$R_{P1}(S,L,V)$] :
+portée de la valeur d'une variable à un point de programme~.
+\remitem{il s'agit d'un sous-ensemble de $R_{1}(S,L)$
+contenant les instructions $I_i$ pour lesquelles la valeur de $V$
+n'a été modifiée sur aucun chemin entre $L$ et le point de programme
+qui précède $I_i$.
+}
+
+\item[$R_{PV0}(S,L,V)$] : utilisation arrière d'une zone mémoire dans sa portée.
+\remitem{il s'agit du sous-ensemble des instructions $R_{P0}(S,L,V)$
+qui sont influencées, directement ou non, par $V$.
+}
+
+\item[$R_{PV1}(S,L,V)$] : utilisation d'une zone mémoire dans sa portée.
+\remitem{il s'agit du sous-ensemble
+ des instructions influencées, directement ou non,
+ par la valeur de $V$ en $L$
+ qui sont dans la portée de cette valeur.
+
+ On a donc : $R_{PV1}(S,L,V) = R_{V1}(S,L,V) \cap R_{P1}(S,L,V)$
+ }
+
+\end{description}
+
+\begin{exemple1}
+On montre ici différents ensembles relatifs au point $L$
+et à la variable $v$~:
+\end{exemple1}
+
+\begin{center}
+\begin{scriptsize}
+\begin{tabular}{|l||c|c|c|c|c|c||c|c|c|c|c| }
+\hline
+S & $R_{0}$ & $R_{L0}$ & $R_{V0}$ & $R_{DV0}$ & $R_{P0}$ & $R_{VP0}$
+ & $R_{1}$ & $R_{V1}$ & $R_{DV1}$ & $R_{P1}$ & $R_{VP1}$ \\
+\hline
+\verb!! & & & & & & & & & & & \\
+\verb!v = a; ! & X & X & X & X & & & & & & & \\
+\verb!x = b; ! & X & & X & & & & & & & & \\
+\verb!z = c; ! & X & & & & & & & & & & \\
+\verb!if (c1>v) { ! & X & X & X & & & & & & & & \\
+\verb! z++; ! & & & & & & & & & & & \\
+\verb! } ! & & & & & & & & & & & \\
+\verb!else { ! & & & & & & & & & & & \\
+\verb! if (c2) ! & X & X & X & & & & & & & & \\
+\verb! v += x; ! & X & X & X & X & & & & & & & \\
+\verb! if (c3) { ! & X & X & X & & X & & & & & & \\
+\verb! z += v; ! & X & X & & & X & X & & & & & \\
+\hline
+{\tt\bf L:}
+ \verb! y = v; ! & & & & & & & X & X & & X & X \\
+\verb! z++; ! & & & & & & & X & & & X & \\
+\verb! v++; ! & & & & & & & X & X & & X & X \\
+\verb! } ! & & & & & & & & & & & \\
+\verb! z += 2*y; ! & & & & & & & X & X & & & \\
+\verb! } ! & & & & & & & & & & & \\
+\verb!z += x; ! & & & & & & & X & X & & & \\
+\verb!v = 0; ! & & & & & & & & & X & & \\
+\verb!! & & & & & & & & & & & \\
+\hline
+\end{tabular}\end{scriptsize}\end{center}
+\begin{exemple2}
+\end{exemple2}
+
+La construction des ensembles ci-dessus exploite le CFG (le flot de contrôle)
+et le PDG (les dépendances).\\
+
+La construction des ensembles ci-dessous exploite en plus la sémantique du
+programme car elle utilise une contrainte $C(...v_i...)$ portant
+sur les valeurs des données en $L$~:
+
+\begin{description}
+\item[$R_{C0}(S,L,C(...v_i...))$] :
+accessibilité contrainte à un point.
+\remitem{il s'agit de déterminer l'ensemble des instructions
+qui, si elles sont présentes, rendent fausse la contrainte $C$ au point $L$.
+En fait, il s'agit de déplacer $C$ pour essayer de couper des branches.
+La condition de branchement sera alors éventuellement
+remplacée par un \verbtt{assert}.
+}
+\smilitem{Dans la séquence \verbtt{int x = 0; x=x-1; L:} pour laquelle
+on a une contrainte $x \ge 0$, il ne s'agit pas de supprimer l'instruction
+\verbtt{x=x-1;} mais bien de dire que cette branche est impossible...}
+
+\item[$R_{C1}(S,L,C(...v_i...))$] : accessibilité contrainte depuis un point.
+\remitem{il s'agit de déterminer le sous-ensemble des instructions de
+$R_{1}(S,L)$ qui ne peuvent pas être atteintes si l'état en L est tel que
+$C$ est satisfaite.\\
+
+
+On notera que certaines instructions n'appartenant ni à $R_{L0}$, ni à $R_{1}$
+peuvent également ne pas être atteintes du fait de la contrainte.\\
+
+}
+\end{description}
+
+\section{Exploitation du graphe pour le calcul d'ensembles}
+
+La plupart des ensembles définis en \ref{sec-ensembles}
+peuvent être calculés simplement en exploitant le flot de contrôle
+et les fonction du graphe de dépendances présentées en \$\ref{sec-find}.
diff --git a/doc/pdg/intro.tex b/doc/pdg/intro.tex
new file mode 100644
index 0000000000000000000000000000000000000000..8336e2eca54b41a5e94587291088e31301e9763f
--- /dev/null
+++ b/doc/pdg/intro.tex
@@ -0,0 +1,246 @@
+\chapter{Introduction}
+
+\section{Objectif}
+
+L'objectif initial a été de réaliser un module de \slicing
+dans le cadre d'un outil généraliste d'analyse de programme (voir
+\cite{ppcSlicing}).
+Or, la plupart des réductions à effectuer se basent sur l'analyse des
+dépendances entre les données du programme.
+En effet, si l'utilisateur demande la sélection
+d'une instruction \verb!return x;!, il va falloir retrouver ce qui permet de
+calculer cette valeur de \verbtt{x} dans les instructions qui précèdent.\\
+
+Il s'agit donc de calculer le \indexdef{graphe de dépendances} d'une fonction
+(appelé \indexdef{PDG}~: {\it Program Dependence Graph} dans la littérature)
+c'est-à -dire de représenter finement les liens de
+dépendances entre les différentes instructions qui la composent.
+Le résultat ce calcul est un graphe dans lequel les sommets
+représentent les instructions,
+éventuellement décomposées en plusieurs noeuds représentant
+le calcul d'informations élémentaires.\\
+
+Dans le cadre de l'outil de \slicing,
+l'intérêt de ce calcul préalable est de pouvoir
+travailler en plusieurs passes lors de l'application des
+requêtes de réduction sans avoir Ã
+refaire ce calcul qui peut être lourd (alias, dépendances partielles, etc). En
+effet, même si l'on souhaite à terme calculer des réductions qui utilisent
+davantage la sémantique du programme, les réductions à l'aide des dépendances
+peuvent simplifier le problème.\\
+
+Par la suite, il a été jugé intéressant de considérer ce calcul
+comme un module à part entière car il peut avoir d'autres
+utilités comme étudier la
+propagation du flot d'information pour des analyses de sécurité, par exemple.
+
+\section{Spécifications du PDG}\label{sec-flot}
+
+Le PDG que l'on souhaite calculer comporte plusieurs types de dépendances~:
+
+\subsection{Dépendances sur la valeur des données}
+
+Les \indextxtdef{dépendances sur la valeur}{dépendance!valeur}
+d'une donnée sont les plus intuitives.
+
+\begin{exemple}
+ \begin{tabular}{m{3.5cm}m{\linewidth-4.3cm}}
+\begin{clisting}
+x = a + b;
+\end{clisting}
+&
+Ici, \verbtt{x} dépend de
+\verbtt{a} et \verbtt{b} car la valeur de \verbtt{x} après cette instruction dépend
+des valeurs de \verbtt{a} et \verbtt{b} avant.
+\end{tabular}
+\end{exemple}
+
+La question se pose néanmoins de définir la granularité à laquelle
+on s'intéresse aux données.
+L'utilisation d'autres analyses et structures de données de \ppc
+conduit à choisir la même précision
+(pour plus de détail, voir par exemple l'analyse de valeurs de \ppc).
+
+\subsection{Dépendances de calcul d'adresse}
+
+Pour les affectations, la valeur qui est écrite en mémoire dépend de la partie
+droite, mais le choix de l'adresse à laquelle on l'écrit peut également dépendre
+de variables qui apparaissent dans la partie gauche.
+
+\begin{exemple}
+\begin{tabular}{m{3.5cm}m{\linewidth-4.3cm}}
+\begin{clisting}
+*p = x;
+\end{clisting}
+&
+Ici, la valeur de la donnée modifiée dépend de \verbtt{x},
+mais le choix de la case dans laquelle on la range dépend de \verbtt{p}.
+En effet, si $p$ pointe sur $a$ ou $b$, c'est soit \verbtt{a} soit \verbtt{b} qui
+va être modifié.
+\end{tabular}
+\end{exemple}
+
+On parle alors de \indextxtdef{dépendances sur l'adresse}{dépendance!adresse}.
+
+\subsection{Dépendances de contrôle}
+
+Lorsqu'une donnée peut-être modifiée par plusieurs chemins d'exécution,
+elle dépend des conditions qui permettent de choisir le chemin.
+
+\begin{exemple}
+\begin{tabular}{m{3.5cm}m{\linewidth-4.3cm}}
+\begin{clisting}
+if (c)
+ x = a;
+L :
+\end{clisting}
+&
+La valeur de \verbtt{x} en \verbtt{L} dépend de \verbtt{a}, mais aussi de \verbtt{c}.\\
+\end{tabular}
+\end{exemple}
+
+Il s'agit d'une \indextxtdef{dépendance de contrôle}{dépendance!contrôle}.
+
+\subsection{Dépendances sur les déclarations}
+
+Lorsque des variables sont utilisées dans une instruction, celle-ci dépend de
+leurs déclarations, car si on veut la compiler, il faut que les variables
+existent.
+
+Les déclarations des variables lues (partie droite d'une affectation) sont
+considérées comme participant au calcul de la valeur.
+Les déclarations des
+variables utilisées pour déterminer la case affectée (partie gauche d'une
+affectation) sont considérées comme des dépendances sur l'adresse.
+
+\begin{exemple}
+\begin{tabular}{m{3.5cm}m{\linewidth-4.3cm}}
+\begin{clisting}
+/* 1 */ int x;
+/* 2 */ int y;
+...
+/* i */ x = 3;
+/* j */ y = 4;
+...
+/* n */ x = y;
+\end{clisting}
+&
+L'instruction (n) a une dépendance d'adresse sur la déclaration de x (1),
+et des dépendances de donnée sur l'affectation de y (j)
+et sa déclaration (2). Dans ce cas, on aurait pu se passer de de cette dernière
+dépendance car (j) dépend déjà de (2), mais ce n'est pas forcement le cas
+en présence d'alias.
+\end{tabular}
+\end{exemple}
+
+\subsection{Résumé}
+
+On voit donc qu'on distingue trois types de dépendances~:
+\begin{itemize}
+\item les calculs de valeurs,
+\item les calculs d'adresses,
+ \item le contrôle.
+\end{itemize}
+
+
+\section{État de l'art}\label{sec-lart}
+
+Voyons tout d'abord ce que dit la littérature sur ce sujet
+afin de voir les solutions qui peuvent répondre à notre besoin,
+et les points à modifier.
+
+\subsection{Origine}
+
+Les graphes de dépendances ont principalement été étudiés dans le cadre du
+\slicing{}, mais ils sont aussi utilisés dans les travaux sur la compilation.
+
+\subsection{Graphes de dépendances}
+
+\cite{Ottenstein84}, puis \cite{Ferrante87}
+introduisent la notion de PDG ({\it Program Dependence Graph}).
+Un tel graphe est utilisé pour représenter les différentes dépendances
+entre les instructions d'un programme.
+Ils l'exploitent pour calculer les instructions
+qui influencent la valeur des variables en un point.\\
+
+Cette représentation, initialement intraprocédurale, a été étendue
+à l'analyse interprocédurale dans \cite{horwitz88interprocedural} où elle
+porte le nom de SDG ({\it System Dependance Graph}).
+Elle est maintenant, à quelques variantes près,
+quasiment universellement utilisée.
+
+\subsection{Exploitation du graphe}
+
+Lorsque l'on utilise le graphe de dépendance pour faire du \slicing,
+le calcul se résume à un problème d'accessibilité à un noeud car comme le dit
+Susan Horwitz~:
+
+\begin{definition}{slicing selon \cite{horwitz88interprocedural}}
+A slice of a program with respect to program point p and variable x
+consists of a set of statements of the program that might affect
+the value of x at p.
+\end{definition}
+
+c'est-à -dire qu'il faut garder toutes les instructions correspondant à des
+noeuds du graphe pour lesquels il existe un chemin vers le noeud représentant le
+calcul de {\tt x} en {\tt p}.
+Mais le problème est que ce noeud n'existe que si {\tt x} est défini
+par l'instruction située en {\tt p}.
+
+Nous verrons que cette limitation peut être levée si l'on garde
+(ou recalcule) les structures de données utilisées
+lors de la construction du graphe.\\
+
+Le traitement des appels de fonction est souvent compliqué par le fait qu'il
+est également ramené à un problème d'accessibilité dans un graphe qui,
+cette fois, représente toute l'application. Or, dans un tel graphe,
+si on ne prend pas de précautions supplémentaires,
+on parcourt des chemins impossibles qui entrent dans une fonction
+par un appel, et sortent par un autre site d'appel.
+Ces chemins existent en effet dans le graphe,
+mais pas dans la réalité.
+
+Comme nous nous proposons de traiter ce problème de manière modulaire,
+nous devrions échapper à une partie de ce problème.
+Mais nous verrons par la suite que l'utilisation d'une analyse d'alias globale
+produit néanmoins quelques effets de bord indésirables.
+
+\subsection{Programmes non structurés}
+
+Les premiers algorithmes utilisés fonctionnent
+correctement sur des programmes structurés,
+mais produisent des résultats erronés en présence de \verbtt{goto}.
+
+Le problème vient du fait que ces instructions ne modifient pas de données~:
+il n'y a donc pas de dépendance de donnée~; et il n'y a pas
+de dépendance de contrôle non plus car dans le CFG,
+une seule branche sort du noeud pour aller vers le point de branchement.
+
+Plusieurs personnes (\cite{Choi94}, \cite{agrawal94slicing},
+\cite{harman98new}, \cite{kumar02better} entre autres)
+se sont donc intéressées
+aux sauts (\verbtt{goto}) qui brisaient la structure du programme.
+Ce point, qui nous intéresse tout particulièrement, est présenté en détail
+en \S\ref{sec-cdg}.
+
+\subsection{Pointeurs et données structurées}
+
+De nombreux articles s'intéressent aux traitements des données structurées,
+et plus encore des pointeurs. Dans le cadre de cette étude,
+nous n'avons pas exploré ces recherches étant donné que
+nous nous appuyons déjà sur une analyse d'alias précise.
+
+
+%~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+\section{Plan}
+
+Les trois chapitres suivants
+exposent comment est calculé notre graphe de dépendances.
+
+Puis, nous verrons au chapitre \ref{sec-find} comment
+exploiter les informations calculées et au chapitre
+\ref{sec-mark} comment associer des informations aux éléments
+et les propager dans le graphe.
+
+
+%~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/doc/pdg/macros_pdg.tex b/doc/pdg/macros_pdg.tex
new file mode 100644
index 0000000000000000000000000000000000000000..8741fa85bf26ba576ae7c68f2b2e1910dd5f3286
--- /dev/null
+++ b/doc/pdg/macros_pdg.tex
@@ -0,0 +1,130 @@
+%==============================================================================
+\usepackage{tabularx}
+\usepackage{wasysym}
+\usepackage{stmaryrd}
+
+%------------------------------------------------------------------------------
+\newcommand{\setenvclass}[2]{}
+
+\usepackage{listings}
+% TODO :
+\lstdefinestyle{clststyle}{}
+\lstnewenvironment{clisting}
+ {
+ \setenvclass{lstlisting}{clisting}
+ \lstset{language=C, style=clststyle}}
+ {}
+%-----------------------------------------------
+% Commandes pour mettre des ref dans l'index :
+\newcommand{\idb}[1]{\textbf{#1}}
+\newcommand{\indextxt}[1]{\index{#1}{\bf #1}}
+\newcommand{\indexdef}[1]{\index{#1|idb}{{\bf #1}}}
+\newcommand{\indextxtdef}[2]{\index{#2|idb}{{\bf #1}}}
+
+%-----------------------------------------------
+% quelques "mots" spéciaux
+\newcommand{\slicing}{{\it slicing}\xspace}
+\newcommand{\slicingb}{{\it slicing\ }}
+ % permet de corriger les cas où \slicing est suivi d'une {
+ % car il semble que xspace gère mal ce cas.
+\newcommand{\caml}{{\sc Ocaml}\xspace}
+\newcommand{\caveat}{{\sc Caveat}\xspace}
+\newcommand{\cil}{{\sc CIL}\xspace}
+\newcommand{\ppc}{{\sc Frama-C}\xspace}
+\newcommand{\from}{{\sc From}\xspace}
+
+\newcommand{\mylet}{\text{\it let }}
+\newcommand{\myin}{\text{\it in }}
+%------------------------------------------------------------------------------
+\newcommand{\verbtt}[1]{{\small{\tt{#1}}}}
+%------------------------------------------------------------------------------
+% Légende des figures :
+\usepackage[hang,small]{caption}
+\renewcommand{\captionfont}{\it}
+\renewcommand{\captionlabelfont}{\it \bf \small}
+%\renewcommand{\captionlabeldelim}{ : }
+%-----------------------------------------------
+% prend le nom du fichier
+% et éventuellement un facteur d'échelle (1 par défaut)
+\newcommand{\uneimage}[2][1]{
+ \includegraphics[width=(#1)\textwidth]{#2}
+}
+%--------------------------------
+\newcommand{\labcenterepsfig}[3]{
+ \begin{center}
+ \begin{figure}[hbt]
+ \centering{
+ \leavevmode
+ \uneimage{#1}
+ }
+ \caption{\label{#3} #2}
+ \end{figure}
+ \end{center}
+ }
+%------------------------------------------------------------------------------
+\newenvironment{debutenv}[1]
+ {
+ \vspace{5mm}
+ \begin{footnotesize}
+ \setenvclass{minipage}{myminipage}
+ \noindent\begin{minipage}[t]{\textwidth}
+ \fbox{\bf #1} \hrule
+ \vspace{3mm}
+ }
+ {
+ \end{minipage}
+ \end{footnotesize}
+ }
+\newenvironment{finenv}
+ {
+ \begin{footnotesize}
+ \setenvclass{minipage}{myminipage}
+ \noindent\begin{minipage}[t]{\textwidth}
+ }
+ {
+ \hrule
+ \
+ \end{minipage}
+ \end{footnotesize}
+ \vspace{5mm}
+ }
+\newenvironment{monenv}[1]
+ {\begin{debutenv}{#1}}
+ {\end{debutenv}
+ \par
+ \begin{finenv}
+ \end{finenv}}
+
+\newcounter{numexemple}
+\newcommand{\titreexemple}{%
+ \stepcounter{numexemple}{Exemple \arabic{numexemple}}}
+
+\newenvironment{exemple}
+ {\begin{monenv}{\titreexemple}}
+ {\end{monenv}}
+
+\newenvironment{exemple1}
+ {\begin{debutenv}{\titreexemple}}
+ {\end{debutenv}}
+
+\newenvironment{exemple2}
+ {\begin{finenv}}
+ {\end{finenv}}
+
+\newenvironment{astuce}
+ {\begin{monenv}{Astuce}}
+ {\end{monenv}}
+
+\newenvironment{definition}[1]
+ {\begin{monenv}{Definition (#1)}}
+ {\end{monenv}}
+
+\newenvironment{algo}[1]
+ {\begin{monenv}{Algorithme (#1)}}
+ {\end{monenv}}
+
+\newcounter{numrque}
+\newenvironment{remarque}[1]
+ {\refstepcounter{numrque}{\bf Remarque \arabic{numrque}} :\label{#1}}
+ {}
+%==============================================================================
diff --git a/doc/pdg/main.tex b/doc/pdg/main.tex
new file mode 100644
index 0000000000000000000000000000000000000000..3c36466ebbccfe3fbfc8290100bcd25276579c4c
--- /dev/null
+++ b/doc/pdg/main.tex
@@ -0,0 +1,27 @@
+\documentclass[a4paper,11pt,twoside,openright,web,lang=french]{frama-c-book}
+
+\input{macros_pdg.tex}
+%==============================================================================
+\begin{document}
+
+\coverpage{PDG --- Documentation technique}
+
+\begin{titlepage}
+\begin{flushleft}
+\includegraphics[height=14mm]{../images/cealistlogo.jpg}
+\end{flushleft}
+\vfill
+\title{Documentation du greffon PDG}{Calcul de dépendances dans un programme C}
+\author{Anne Pacalet et Patrick Baudin}
+\begin{tabular}{l}
+CEA LIST, Laboratoire de Sûreté et Sécurité des Logiciels, Saclay, F-91191 \\
+\end{tabular}
+\vfill
+\begin{flushleft}
+ \textcopyright 2007-2020 CEA LIST
+
+\end{flushleft}
+\end{titlepage}
+\input{pdg.tex}
+
+\end{document}
diff --git a/doc/pdg/mark.tex b/doc/pdg/mark.tex
new file mode 100644
index 0000000000000000000000000000000000000000..4e78cbd66eabf5fbce3835af9acfdb9a45a994cc
--- /dev/null
+++ b/doc/pdg/mark.tex
@@ -0,0 +1,159 @@
+\chapter{Marquage générique}\label{sec-mark}
+
+\section{Objectif}
+
+On souhaite pouvoir associer une information à certains éléments d'un PDG,
+propager cette information dans les dépendances de ces éléments,
+et calculer ce qu'il faut propager dans les autres PDG de l'application
+pour avoir un traitement interprocédural cohérent. \\
+
+Par exemple, l'information peut être un simple booléen qui indique si l'élément
+correspondant est visible ou non. Pour qu'un élément soit visible, il faut que
+toutes ses dépendances le soit aussi.
+On voit dans cet exemple qu'on s'intéresse dans un premier temps à une
+propagation arrière.\\
+
+Comme un PDG est associé à une fonction, la propagation s'arrête aux entrées
+de la fonction. Par ailleurs, les appels de fonction sont traités localement,
+sans descendre dans la fonction appelée.
+Pour gérer la propagation interprocédurale, les fonctions élémentaires de
+marquage doivent fournir l'information à propager aussi bien dans les fonctions
+appelées que dans les appelants.
+
+\section{Marquage générique}
+
+Le marquage pouvant être utilisé pour différents besoins,
+les marques peuvent être définies par l'utilisateur.
+Il lui suffit de définir comment en faire l'union.
+
+On utilise deux types d'union~:
+\begin{itemize}
+ \item l'une permet de faire une simple union de deux marques,
+ \item l'autre permet d'ajouter une marque à un élément de programme~:
+ elle calcule donc une nouvelle marque à partir de l'ancienne,
+ et de la marque à ajouter et fournit aussi la marque à propager dans les
+ dépendances.
+\end{itemize}
+
+\section{Propagation arrière}
+
+\subsection{Marquage intraprocédural}
+
+La propagation arrière s'effectue très simplement en suivant les dépendances,
+en ajoutant la marque propagée à la marque existante,
+et en s'arrêtant quand la marque à propager rendue par la fonction de marquage
+est $m_{\bot}$.\\
+
+En cours de propagation, lorsque l'on traite un élément correspondant à la
+sortie d'un appel de fonction, ou à une entrée de la fonction courante,
+la marque à propager ainsi que l'identifiant de l'élément sont stockés.
+A l'issu du marquage, on a donc~:
+\begin{itemize}
+ \item un ensemble de couple (entrée de la fonction, marque à propager),
+ \item une liste des appels de fonction, avec pour chacun un ensemble de
+ couples (sortie de l'appel, marque à propager).
+\end{itemize}
+
+C'est cette information qui permettra de faire la propagation interprocédurale.
+
+\subsection{Propagation interprocédurale}
+
+\subsubsection{Méthode automatique}
+
+Le module de marquage permet de faire automatiquement
+la propagation interprocédurale si on le souhaite.
+Il est utilisé de cette façon dans la détection de code mort par exemple.\\
+
+L'utilisateur peut, s'il le souhaite,
+donner des fonctions de transformation des marques~:
+\begin{itemize}
+ \item une qui est utilisée pour transformer les marques des entrées d'une
+ fonction avant la propagation dans les appelants,
+ \item une autre qui est utilisée pour transformer les marques des sorties
+ d'un appel de fonction avant propagation dans la fonction appelée.
+\end{itemize}
+Dans les cas les plus simples, ces fonctions ne font rien, et rendent
+simplement la marque qui leur est passée.
+
+\subsubsection{Méthode manuelle}
+
+Dans certains cas, il est souhaitable de gérer cette propagation à la main.
+C'est par exemple le cas dans le \slicing{} où une fonction source est associée
+à plusieurs marquages différents.\\
+
+Des fonctions aident néanmoins à retrouver les éléments à marquer dans les
+autres fonctions à partir du résultat fourni par le marquage intraprocédural.
+Ces fonctions traduisent les informations~:
+\begin{itemize}
+ \item (entrée de la fonction, marque à propager) en un ensemble d'éléments Ã
+ marquer dans une~- ou toutes les~- fonction(s) appelante(s),
+ \item (appel, \{(sortie de l'appel, marque à propager)\})
+ en un ensemble d'éléments à marquer dans la fonction appelée.
+\end{itemize}
+Les éléments rendu sont les nouveaux points de départ de marquages
+intraprocéduraux.
+L'utilisateur peut, comme lors de la propagation automatique,
+donner des fonctions de transformation des marques aux traductions.
+
+\subsubsection{Données non définies}
+
+Lorsque les points de départ marquage initial sont des éléments du PDG,
+toutes les propagations s'effectueront a priori sur des éléments existant.
+Mais ce n'est pas forcement le cas lorsqu'il s'agit de marquer les données
+qui n'interviennent pas dans les calculs. Par exemple~:
+
+\begin{exemple}
+ \begin{verbatim}
+int X1, X2;
+
+void f (int x) { /*@ assert X1 >= 0; */ return x + 1; }
+
+void f2 (void) { X2 = f (2); }
+
+void main (void) { X1 = 0; X2 = 0; f2 (); }
+ \end{verbatim}
+
+ Ici, si on s'intéresse à l'assertion de \verbtt{f}, il faut sélectionner
+ \verbtt{X1} à l'entrée de \verbtt{f}, propager cette information à travers
+ \verbtt{f2} pour enfin marquer l'affectation à \verbtt{X1} dans le \verbtt{main}
+ alors que cette donnée n'apparaît pas dans les PDG de \verbtt{f} et \verbtt{f2}.
+\end{exemple}
+
+On voit donc que dans les informations fournies et calculées
+pour gérer l'interprocédural, il peut y avoir des éléments ne correspondant
+pas à des noeuds de PDG.
+
+\subsubsection{Terminaison}
+
+La terminaison du processus dépend de la définition des marques.
+C'est donc à l'utilisateur de s'assurer que celle-ci permet la stabilisation du
+marquage.
+
+\section{Propagation avant}
+
+La propagation avant n'est pas effectuée automatiquement à l'heure actuelle.
+
+La propagation intraprocédurale ne pose pas de problèmes particuliers,
+car elle est très semblable au calcul en arrière~: il suffit simplement de
+parcourir les liens de dépendance dans l'autre sens.\\
+
+La partie interprocédurale semble un peu plus délicate,
+car il n'y a aucun point de repère dans le PDG
+pour identifier les endroits à partir desquels il faut propager
+(hormis le noeud correspondant au \verbtt{return}
+pour la propagation vers les appelants et les arguments explicites pour
+la propagation dans les appels de fonction).
+
+Des fonctions supplémentaires sont donc fournies pour~:
+\begin{itemize}
+ \item trouver les noeuds d'entrées d'une fonction qui doivent être
+ sélectionnés à partir des noeuds sélectionnés dans l'appelant,
+ \item trouver les noeuds de sortie d'un appel de fonction
+ qui doivent être
+ sélectionnés à partir des noeuds sélectionnés dans la fonction appelée.
+\end{itemize}
+
+En cas d'utilisation intensive de ces fonctionnalités,
+il serait sans doute intéressant de mémoriser les liens entre les
+différents PDG (cela est également vrai pour la propagation interprocédurale
+arrière...).\\
diff --git a/doc/pdg/pdg-call.fig b/doc/pdg/pdg-call.fig
new file mode 100644
index 0000000000000000000000000000000000000000..f55a683a25f4ca4cd7ef67f8bd4c8f96db2e0eaf
--- /dev/null
+++ b/doc/pdg/pdg-call.fig
@@ -0,0 +1,151 @@
+#FIG 3.2
+Landscape
+Center
+Metric
+A4
+100.00
+Single
+-2
+1200 2
+6 7830 3330 8820 3780
+2 3 0 1 0 7 50 -1 -1 4.000 0 0 0 0 0 7
+ 8190 3702 8301 3534 8211 3354 8010 3342 7899 3510 7989 3690
+ 8190 3702
+2 3 0 1 0 7 50 -1 -1 4.000 0 0 0 0 0 7
+ 8640 3690 8751 3522 8661 3342 8460 3330 8349 3498 8439 3678
+ 8640 3690
+4 1 0 50 -1 0 12 0.0000 4 135 150 8100 3600 f0\001
+4 1 0 50 -1 0 12 0.0000 4 135 150 8550 3600 f1\001
+-6
+6 7650 2880 8010 3150
+2 2 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 5
+ 7650 2880 8010 2880 8010 3150 7650 3150 7650 2880
+4 1 0 50 -1 0 12 0.0000 4 90 90 7830 3060 a\001
+-6
+6 8550 2880 8910 3150
+2 2 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 5
+ 8550 2880 8910 2880 8910 3150 8550 3150 8550 2880
+4 1 0 50 -1 0 12 0.0000 4 135 90 8730 3060 b\001
+-6
+6 8190 1440 8730 1980
+1 4 0 1 0 7 50 -1 -1 4.000 1 0.0000 8460 1710 180 180 8460 1890 8460 1530
+4 1 0 50 -1 0 12 0.0000 4 135 135 8460 1800 G\001
+-6
+6 8550 2340 9090 2790
+1 2 0 1 0 7 50 -1 -1 4.000 1 0.0000 8820 2565 180 135 8640 2430 9000 2700
+4 1 0 50 -1 0 12 0.0000 4 90 90 8820 2610 z\001
+-6
+6 7380 2340 8010 2790
+1 2 0 1 0 7 50 -1 -1 4.000 1 0.0000 7695 2565 225 135 7470 2430 7920 2700
+4 1 0 50 -1 0 12 0.0000 4 135 330 7740 2610 x+y \001
+-6
+6 7290 1800 7650 2250
+1 4 0 1 0 7 50 -1 -1 4.000 1 0.0000 7470 2025 135 135 7470 2160 7470 1890
+4 1 0 50 -1 0 12 0.0000 4 90 90 7470 2070 x\001
+-6
+6 7740 1800 8100 2250
+1 4 0 1 0 7 50 -1 -1 4.000 1 0.0000 7920 2025 135 135 7920 2160 7920 1890
+4 1 0 50 -1 0 12 0.0000 4 135 90 7920 2070 y\001
+-6
+6 7650 3780 8010 4230
+1 4 0 1 0 7 50 -1 -1 4.000 1 0.0000 7830 4005 135 135 7830 4140 7830 3870
+4 1 0 50 -1 0 12 0.0000 4 90 90 7830 4050 z\001
+-6
+6 4770 1620 6390 3870
+6 4860 1800 5220 2790
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4860 1800 5220 1800 5220 2070 4860 2070 4860 1800
+2 3 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4860 2430 5220 2430 5040 2790 4860 2430 4860 2430
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 5040 2070 5040 2430
+4 1 0 50 -1 0 12 0.0000 4 90 90 5040 1980 a\001
+4 1 0 50 -1 0 12 0.0000 4 90 90 5040 2610 a\001
+-6
+6 5400 1800 5760 2790
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 5400 1800 5760 1800 5760 2070 5400 2070 5400 1800
+2 3 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 5400 2430 5760 2430 5580 2790 5400 2430 5400 2430
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 5580 2070 5580 2430
+4 1 0 50 -1 0 12 0.0000 4 135 90 5580 2610 b\001
+4 1 0 50 -1 0 12 0.0000 4 135 90 5580 1980 b\001
+-6
+6 5940 2430 6300 2790
+2 3 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 5940 2430 6300 2430 6120 2790 5940 2430 5940 2430
+4 1 0 50 -1 0 12 0.0000 4 135 135 6120 2610 G\001
+-6
+2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5
+ 6390 3870 6390 1620 4770 1620 4770 3870 6390 3870
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 6030 1620 6390 1980
+2 3 0 1 0 7 50 -1 -1 4.000 0 0 7 0 0 7
+ 5490 3780 5601 3612 5511 3432 5310 3420 5199 3588 5289 3768
+ 5490 3780
+2 3 0 1 0 7 50 -1 -1 4.000 0 0 7 0 0 7
+ 6051 3780 6162 3612 6072 3432 5871 3420 5760 3588 5850 3768
+ 6051 3780
+3 0 2 2 0 7 50 -1 -1 4.500 0 0 0 3
+ 6120 2790 6210 3240 6030 3420
+ 0.000 1.000 0.000
+3 0 2 2 0 7 50 -1 -1 4.500 0 0 0 3
+ 5580 2790 5400 3060 5940 3420
+ 0.000 1.000 0.000
+3 0 2 2 0 7 50 -1 -1 4.500 0 0 0 3
+ 6120 2790 5940 3060 5490 3420
+ 0.000 1.000 0.000
+3 0 2 2 0 7 50 -1 -1 4.500 0 0 0 3
+ 5040 2790 4950 3150 5310 3420
+ 0.000 1.000 0.000
+4 0 0 50 -1 0 12 0.0000 4 135 60 6210 1800 f\001
+4 1 0 50 -1 0 12 0.0000 4 135 90 5400 3690 0\001
+4 1 0 50 -1 0 12 0.0000 4 135 90 5940 3690 1\001
+-6
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 7830 3150 8010 3330
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 8730 3150 8640 3330
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 8820 2700 8730 2880
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 7740 2700 7830 2880
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 8370 1890 8190 3330
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 8460 1890 8460 3330
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 7560 2160 7650 2430
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 7830 2160 7740 2430
+2 4 0 1 0 7 50 -1 -1 4.000 0 0 7 0 0 5
+ 9180 3780 9180 2340 7290 2340 7290 3780 9180 3780
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 8100 3690 7920 3870
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 8550 3690 8730 4050
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 9270 1800 8820 1350
+2 4 0 1 0 7 50 -1 -1 4.000 0 0 7 0 0 5
+ 9270 4500 9270 1350 7200 1350 7200 4500 9270 4500
+4 1 0 50 -1 0 12 0.0000 4 135 90 9090 1530 g\001
+4 1 0 50 -1 14 12 0.0000 4 180 1365 8370 1170 z = f(x+y,z);\001
+4 1 0 50 -1 0 12 0.0000 4 135 1245 4050 2610 Valeurs initiales\001
+4 1 0 50 -1 0 12 0.0000 4 135 975 4050 1980 D\351clarations\001
+4 1 0 50 -1 0 12 0.0000 4 135 540 4050 3690 Sorties\001
+4 1 0 50 -1 14 12 0.0000 4 165 1890 5580 1350 T1 f (T2 a, T3 b);\001
+4 1 0 50 -1 3 12 0.0000 4 150 1845 5580 4140 \\res From a , G.a, G.b;\001
+4 1 0 50 -1 3 12 0.0000 4 150 1050 5580 4410 G From b, G;\001
diff --git a/doc/pdg/pdg.tex b/doc/pdg/pdg.tex
new file mode 100644
index 0000000000000000000000000000000000000000..92fca55150bc4bfe1a28c3e0d343fce776b66439
--- /dev/null
+++ b/doc/pdg/pdg.tex
@@ -0,0 +1,78 @@
+%===============================================================================
+% Versions
+\section*{Versions}
+
+\begin{small}
+Seules les versions Vx.0 sont des documents achevés~;
+les autres sont à considérer comme des brouillons.
+
+\begin{enumerate}
+ \item[V3.0 -] 2 novembre 2020~:
+ \begin{itemize}
+ \item Document sous licence Creative Commons
+ ``Attribution-ShareAlike 4.0 International''
+ \url{https://creativecommons.org/licenses/by/4.0/}.
+ \end{itemize}
+ \item[V2.0 -] 3 décembre 2008~:
+ \begin{itemize}
+ \item réorganisation,
+ \item mise à jour,
+ \item partie sur l'utilisation.
+ \end{itemize}
+ \item[V1.4 - ] 30 mai 2008~:
+ \begin{itemize}
+ \item ajout d'une partie sur le marquage.
+ \end{itemize}
+ \item[V1.3 - ] 22 novembre 2007~:
+ \begin{itemize}
+ \item mise à jour de la partie sur l'interprocédural.
+ \end{itemize}
+ \item[V1.2 - ] 07 novembre 2007~:
+ \begin{itemize}
+ \item mise à jour de la partie sur les dépendances de contrôle.
+ \end{itemize}
+ \item[V1.1 - ] 20 septembre 2007~:
+ \begin{itemize}
+ \item réorganisation complète,
+ \item développement de la partie sur les dépendances de contrôle,
+ \item discussion au sujet des boucles infinies.
+ \end{itemize}
+ \item[V1.0 - ] 26 juin 2007~:
+ \begin{itemize}
+ \item relecture et petites corrections.
+ \end{itemize}
+ \item[V0.2 - ] 24 mai 2007~:
+ \begin{itemize}
+ \item révision générale,
+ \end{itemize}
+ \item[V0.1 - ] 23 mars 2007~:
+ \begin{itemize}
+ \item création du module de calcul de PDG,
+ \item extraction de la documentation du PDG du rapport sur le {\it
+ slicing}.
+ \end{itemize}
+\end{enumerate}
+\end{small}
+%===============================================================================
+\cleardoublepage
+\tableofcontents
+%===============================================================================
+\cleardoublepage\input{intro.tex}
+\cleardoublepage\input{data.tex}
+\cleardoublepage\input{ctrl.tex}
+\cleardoublepage\input{calls.tex}
+\cleardoublepage\input{utilisation.tex}
+\cleardoublepage\input{mark.tex}
+\cleardoublepage\input{conclusion.tex}
+%===============================================================================
+\appendix
+%--------------------------------------
+\cleardoublepage \input{impact.tex}
+%-------------------------------------------------------------------------------
+\cleardoublepage
+\bibliographystyle{abbrvnat}
+\bibliography{../slicing/bib-slicing}
+%--------------------------------------
+\cleardoublepage
+\printindex
+%===============================================================================
diff --git a/doc/pdg/utilisation.tex b/doc/pdg/utilisation.tex
new file mode 100644
index 0000000000000000000000000000000000000000..2b0d0794efaa27389a37391b59aefbe3d298729e
--- /dev/null
+++ b/doc/pdg/utilisation.tex
@@ -0,0 +1,49 @@
+\chapter{Retrouver l'information}\label{sec-find}
+
+Jusqu'à présent, on a vu comment calculer le graphe de dépendances.
+Dans ce chapitre, nous présentons les fonctions fournies pour
+trouver des éléments du PDG suivant un certain nombre de critères.
+L'annexe \ref{sec-impact} rappelle certains objectifs initiaux
+d'une utilisation de ces fonctions pour effectuer une analyse d'impact.\\
+
+Par ailleurs, outre la manipulation d'ensemble d'éléments du PDG,
+un système de gestion et de propagation de marques est également proposé.
+Il est présenté au chapitre \ref{sec-mark}.
+
+\section{A partir de leur clé}
+
+Au cours du calcul, chaque élément du PDG est associé à une clé
+qui correspond à l'élément de programme qu'il représente (cf. {\tt
+pdgIndex.mli}).
+On peut par la suite retrouver un élément à partir de cette clé
+comme par exemple l'élément correspondant à une instruction simple,
+à un paramètre d'entrée, à une déclaration locale, etc.
+
+\section{A partir d'une zone mémoire}
+
+Grâce à l'état qui est propagé lors de la construction
+des dépendances de données (cf. \S\ref{sec-propagation-etat})
+on peut retrouver les éléments qui participent au calcul
+d'une zone mémoire à un point de programme.
+
+Cette fonction doit également vérifier si les éléments trouvés
+définissent complètement la donnée recherchée ou non,
+et si ce n'est pas le cas, indiquer la zone susceptible de ne pas être
+complètement définie au point considéré.
+
+\section{A partir de propriétés}
+
+D'autres fonctionnalités de \ppc permettent d'interpréter une propriété
+du programme et d'en extraire les zones mémoire nécessaires à son évaluation.
+Comme on sait par ailleurs trouver les éléments qui correspondent
+a une zone mémoire en un point de programme (voir ci-dessus),
+on peut ainsi trouver par exemple les éléments dont dépendent une assertion
+ou tout autre propriété.
+
+\section{En exploitant les dépendances}
+
+Après avoir retrouver des éléments dans le graphe, on veut en général exploiter
+leurs dépendances. On peut facilement retrouver les dépendances avant ou
+arrière,
+avec ou sans filtrage sur leur type (donnée, contrôle,...),
+récursivement ou non.
diff --git a/doc/slicing/.gitignore b/doc/slicing/.gitignore
new file mode 100644
index 0000000000000000000000000000000000000000..91ebc66bd3c739930507edb3c2f09a066b922fbf
--- /dev/null
+++ b/doc/slicing/.gitignore
@@ -0,0 +1,11 @@
+biblio.bib
+frama-c-book.cls
+frama-c-cover.pdf
+frama-c-left.pdf
+frama-c-right.pdf
+main.pdf
+call.pdf
+choose_call.pdf
+exple2.pdf
+propagation.pdf
+propagation.pdf
diff --git a/doc/slicing/Makefile b/doc/slicing/Makefile
new file mode 100644
index 0000000000000000000000000000000000000000..b09932ac72db4cf6512927e70d60debfe827927c
--- /dev/null
+++ b/doc/slicing/Makefile
@@ -0,0 +1,50 @@
+.PHONY: all clean
+
+all: main.pdf
+
+GENERATED=biblio.bib
+GENERATED+=frama-c-book.cls frama-c-cover.pdf frama-c-left.pdf frama-c-right.pdf
+include ../MakeLaTeXModern
+
+DWNLDDIR=../manuals
+DOCNAME=slicing-documentation-fr.pdf
+
+BIB_FILE = bib-slicing.bib
+main.bbl : $(BIB_FILE)
+ @echo "=== Fichier .bib plus récent -> effacement du .bbl"
+ rm -f $(SRC).bbl
+
+main.pdf: $(FRAMAC_MODERN) $(BIB_FILE) \
+ main.tex macros_slicing.tex slicing.tex \
+ intro.tex conclusion.tex \
+ fonction.tex interproc.tex interproc2.tex man.tex \
+ algo.tex interexples.tex intercmds.tex projets.tex \
+ algoH.mli algo.ml \
+ call.pdf choose_call.pdf exple2.pdf propagation.pdf propagation.pdf
+
+###############################################################################
+
+GENERATED+=call.pdf choose_call.pdf exple2.pdf propagation.pdf propagation.pdf
+%.pdf : %.fig
+ fig2dev -L pdf $< $@
+
+###############################################################################
+
+%.pdf: %.tex
+ pdflatex $*
+ bibtex $*
+ pdflatex $*
+ pdflatex $*
+
+install: main.pdf
+ @echo "copying main.pdf in $(DWNLDDIR)/$(DOCNAME)"
+ @rm -f "$(DWNLDDIR)/$(DOCNAME)"
+ @cp main.pdf "$(DWNLDDIR)/$(DOCNAME)"
+
+clean:
+ rm -rf *~ *.aux *.log *.nav *.out *.snm *.toc *.lof *.pp *.bnf \
+ *.haux *.hbbl *.htoc \
+ *.cb *.cb2 *.cm? *.bbl *.blg *.idx *.ind *.ilg \
+ $(GENERATED)
+
+###############################################################################
diff --git a/doc/slicing/algo.ml b/doc/slicing/algo.ml
new file mode 100644
index 0000000000000000000000000000000000000000..35755d65866f27523d34355ed7ebcfb7cb07225a
--- /dev/null
+++ b/doc/slicing/algo.ml
@@ -0,0 +1,22 @@
+(* On nomme H le module des hypothèses. *)
+module H = AlgoH ;;
+
+(* produit une nouvelle fonction spécialisée en partant de [ff]
+ en marquant l'élément [e] et toutes ses dépendances avec la marque [m]. *)
+let rec mark_rec_pdg_elem pdg stmt_elems m e ff =
+ let new_ff = add_elem_mark pdg stmt_elems m e ff in
+ let dpds = H.get_dpds e pdg in
+ List.fold_right (mark_rec_pdg_elem pdg stmt_elems m) dpds new_ff
+ (* ;; *)
+and
+(* [add_elem_mark] ajoute la marque [m] Ã l'instruction correspondant Ã
+ l'élément [e] et marque les autres éléments éventuels comme superflus. *)
+ add_elem_mark pdg stmt_elems m e ff =
+ let stmt = H.get_stmt e stmt_elems in
+ let old_m = H.get_stmt_mark stmt ff in
+ let new_m = H.combine_mark old_m m in
+ let new_ff = H.replace_stmt_mark ff stmt new_m in
+ let elems = H.get_elems stmt stmt_elems in
+ let (_, other_elems) = List.partition (fun elem -> elem = e) elems in
+ let mark_spare_elem e ff = mark_rec_pdg_elem pdg stmt_elems H.spare_mark e ff in
+ List.fold_right mark_spare_elem other_elems new_ff
diff --git a/doc/slicing/algo.tex b/doc/slicing/algo.tex
new file mode 100644
index 0000000000000000000000000000000000000000..c27c2edc736c88d84f7aa080e80cd5feead8c087
--- /dev/null
+++ b/doc/slicing/algo.tex
@@ -0,0 +1,22 @@
+\chapter{Algorithmes}
+
+\section{Hypothèses}
+
+On se donne quelques types et fonctions de base~:\\
+
+\camlListingInput{algoH.mli}
+
+\section{Marquage d'une fonction}\label{sec-algo-mark-fct}
+
+Il s'agit de voir comment sont marquées les instructions d'une fonction
+à partir d'une requête donnant un élément du PDG et une marque.\\
+
+L'algorithme présenté ici est une version simplifiée
+de celui qui existe dans
+l'outil afin d'être plus facilement compréhensible.
+Il est très inefficace et risque de boucler car on ne teste pas
+si l'instruction à marquer contient déjà la nouvelle marque (test d'arrêt).
+
+Il s'agit de plus d'une version sans spécialisation des appels de fonction.\\
+
+\camlListingInput{algo.ml}
diff --git a/doc/slicing/algoH.mli b/doc/slicing/algoH.mli
new file mode 100644
index 0000000000000000000000000000000000000000..a514d3fedd1df4b77162a9b5d10ae67d66f29c14
--- /dev/null
+++ b/doc/slicing/algoH.mli
@@ -0,0 +1,59 @@
+(* Point de programme *)
+type t_program_point ;;
+
+(* Instruction *)
+type t_stmt ;;
+
+(* l'instruction située à un point de contrôle (après) *)
+val get_pp_stmt : t_program_point -> t_stmt ;;
+
+(* CFG : control flow graph *)
+type t_cfg ;;
+(* successeurs dans le cfg. *)
+val get_cfg_succ : t_cfg -> t_stmt -> t_stmt list ;;
+(* predecesseurs dans le cfg. *)
+val get_cfg_prev : t_cfg -> t_stmt -> t_stmt list ;;
+
+(* PDG : program dependences graph *)
+type t_pdg ;;
+(* element composant le PDG *)
+type t_elem ;;
+(* donne la liste des dépendances directes de l'élément dans le PDG *)
+val get_dpds : t_elem -> t_pdg -> t_elem list ;;
+val get_all_dpds : t_pdg -> t_elem -> t_elem list ;;
+val get_list_all_dpds : t_pdg -> t_elem list -> t_elem list ;;
+val get_list_control_dpds : t_pdg -> t_elem list -> t_elem list ;;
+val get_list_all_control_dpds : t_pdg -> t_elem list -> t_elem list ;;
+val merge : t_elem list -> t_elem list -> t_elem list ;;
+
+val get_pp_elems : t_pdg -> t_program_point -> t_elem list ;;
+
+(* correspondance entre les instructions et les éléments du PDG *)
+type t_stmt_elems ;;
+
+(* retrouver l'instruction correspondant à un élément *)
+val get_stmt : t_elem -> t_stmt_elems -> t_stmt ;;
+(* retrouver les instructions correspondant aux éléments *)
+val get_stmts : t_elem list -> t_stmt_elems -> t_stmt list ;;
+(* retrouver les éléments correspondant à une instruction *)
+val get_elems : t_stmt -> t_stmt_elems -> t_elem list ;;
+
+type t_state
+
+type t_data
+
+val get_state : t_program_point -> t_state ;;
+val get_defs_data : t_state -> t_data -> t_elem list ;;
+(* type des marques *)
+type t_mark ;;
+(* la marque correspondant à mS : superflu. *)
+val spare_mark : t_mark ;;
+(* combinaison de deux marques *)
+val combine_mark : t_mark -> t_mark -> t_mark ;;
+
+(* type correspondant au marquage des instructions d'une fonction. *)
+type t_ff ;;
+(* lire la marque associée à une instruction dans le marquage *)
+val get_stmt_mark : t_stmt -> t_ff -> t_mark ;;
+(* remplacer la marque associée à une instruction dans le marquage *)
+val replace_stmt_mark : t_ff -> t_stmt -> t_mark -> t_ff ;;
diff --git a/doc/slicing/bib-slicing.bib b/doc/slicing/bib-slicing.bib
new file mode 100644
index 0000000000000000000000000000000000000000..1ecf02cac03b72ab4ba1eb123e2db5e587c5928c
--- /dev/null
+++ b/doc/slicing/bib-slicing.bib
@@ -0,0 +1,519 @@
+%--------------------------------------------
+% voir aussi : http://www.infosun.fmi.uni-passau.de/st/staff/krinke/slicing/
+% pour une énorme biblio.
+%===============================================================================
+% Nos documents :
+%--------------------------------------------
+@techreport{ CEAlocations,
+ author = "Anne Pacalet",
+ title = "Emplacements, pointeurs, et opérations associées",
+ INSTITUTION = "CEA",
+ number = "DTSI/SLA/03-49/AP",
+ month = "janvier",
+ year = "2003"
+}
+%--------------------------------------------
+@techreport{ baudinImpact,
+ author = "P. Baudin",
+ title = "Analyse d'impact~: spécification de l'outil",
+ INSTITUTION = "CEA",
+ number = "DTSI/SOL/04-187",
+ month = "juin",
+ year = "2004"
+}
+%--------------------------------------------
+@techreport{ slicingCaveat,
+ author = "A. Pacalet and P. Baudin",
+ title = "Analyse d'impact ; L'outil de slicing",
+ INSTITUTION = "CEA",
+ number = "DTSI/SOL/05-141",
+ month = "mai",
+ year = "2005",
+ note = "(Note : {\it Il existe, en interne, une version plus récente de ce document})."
+}
+%--------------------------------------------
+@techreport{ ppcPdg,
+ author = "A. Pacalet",
+ title = "Calcul de dépendances dans un programme C",
+ INSTITUTION = "INRIA",
+ month = "juin",
+ year = "2007",
+ note = "(Note : {\it document de travail en cours d'évolution})"
+}
+%--------------------------------------------
+@techreport{ ppcSlicing,
+ author = "A. Pacalet",
+ title = "Conception d'un outil de slicing",
+ INSTITUTION = "INRIA",
+ month = "juin",
+ year = "2007",
+ note = "(Note : {\it document de travail en cours d'évolution})"
+}
+
+%===============================================================================
+% Etat de l'art sur le slicing en 1995
+@article{ tip95survey,
+ author = "F. Tip",
+ title = "A survey of program slicing techniques",
+ journal = "Journal of programming languages",
+ volume = "3",
+ pages = "121--189",
+ year = "1995",
+ url = "http://citeseer.nj.nec.com/tip95survey.html"
+}
+%--------------------------------------------
+@misc{wwwSlicing,
+ key = "SlicingWebLinks",
+ title = "Slicing Web Links",
+ url = "http://www.infosun.fmi.uni-passau.de/st/staff/krinke/slicing/"
+}
+%--------------------------------------------
+@inproceedings{873584,
+ author = {Andrea De Lucia and Mark Harman and Robert Hierons and Jens
+ Krinke},
+ title = {Unions of Slices Are Not Slices},
+ booktitle = {CSMR '03: Proceedings of the Seventh European Conference on
+ Software Maintenance and Reengineering},
+ year = {2003},
+ isbn = {0-7695-1902-4},
+ pages = {363},
+ publisher = {IEEE Computer Society},
+ address = {Washington, DC, USA},
+}
+%--------------------------------------------
+% Travaux de M. Ernst :
+% VDG (Value Dependance Graph) pour representer le programme
+% afin de faciliter le slicing. Traitement de tout ANSI-C (sauf longjump)
+% Utilise une analyse d'alias (point-to, flow-insensitive ?)
+% mais elle n'est pas détaillée.
+% Traite des structures,
+% mais pas de précision sur le traitement des éléments de tableaux...
+% Dans l'un des articles, représentation intéressante de l'état mémoire
+% considéré dans son ensemble avec fonctions Lookup/Update.
+% Traitement des appels de fonctions en utilisant les "froms".
+% A LIRE plus en détail.
+@techreport{Ernst95,
+ author = {Michael D. Ernst},
+ title = {Slicing pointers and procedures (abstract)},
+ institution = {Microsoft Research},
+ number = {MSR-TR-95-23},
+ address = {Redmond, WA},
+ month = {January~13,},
+ year = {1995},
+ url = "http://pag.csail.mit.edu/~mernst/pubs/slicing-tr9523-abstract.html"
+}
+@inproceedings{177907,
+ author = {Daniel Weise and Roger F. Crew and Michael Ernst and Bjarne Steensgaard},
+ title = {Value dependence graphs: representation without taxation},
+ booktitle = {POPL '94: Proceedings of the 21st ACM SIGPLAN-SIGACT symposium on Principles of programming languages},
+ year = {1994},
+ isbn = {0-89791-636-0},
+ pages = {297--310},
+ location = {Portland, Oregon, United States},
+ url = {http://doi.acm.org/10.1145/174675.177907},
+ doi = {10.1145/174675.177907},
+ publisher = {ACM Press},
+ address = {New York, NY, USA},
+ }
+@techreport{Ernst94,
+ author = "Michael D. Ernst",
+ title = "Practical fine-grained static slicing of optimized code",
+ institution = "Microsoft Research",
+ number = "MSR-TR-94-14",
+ month = "July",
+ year = "1994",
+ address = {Redmond, WA},
+ url = "http://pag.csail.mit.edu/~mernst/pubs/slicing-tr9414-abstract.html"
+}
+%--------------------------------------------
+% notion d'intersection entre les données pour traitement
+% des champs de structure et des éléments de tableau
+% (traitement de a[i] pas clair)
+% Presentation d'un slicing static,
+% mais considère que les pointeurs peuvent sont potentiellement en alias
+% avec n'importe quoi ! En fait, leur but est de faire du slicing dynamique,
+% ça résoud donc le problème.
+@inproceedings{ agrawal91dynamic,
+ author = "Hiralal Agrawal and Richard A. {DeMillo} and Eugene H. Spafford",
+ title = "Dynamic Slicing in the Presence of Unconstrained Pointers",
+ booktitle = "Symposium on Testing, Analysis, and Verification",
+ pages = "60--73",
+ year = "1991",
+ url = "http://citeseer.nj.nec.com/agrawal91dynamic.html"
+}
+
+%--------------------------------------------
+% Attention : une version de 88 + version révisée de 1990
+% System dependance graph et discussion sur l'interprocedural
+@inproceedings{ horwitz88interprocedural,
+ author = "Susan Horwitz and Thomas Reps and David Binkley",
+ title = "Interprocedural slicing using dependence graphs",
+ booktitle = "Proceedings of the {ACM} {SIGPLAN} '88 Conference on Programming Language Design and Implementation",
+ journal = "SIGPLAN Notices",
+ volume = "23-7",
+ month = "June",
+ address = "Atlanta, GA",
+ pages = "35--46",
+ year = "1988",
+ url = "http://citeseer.nj.nec.com/horwitz90interprocedural.html"
+}
+%--------------------------------------------
+% Critère original :
+% "Statements are removed if they cannot lead to satisfaction of the negation
+% of the postcondition when executed in an initial state
+% which satisfies the precondition".
+% En gros, on veux vérifier une post, et on élimine déjà les cas
+% où on arrive à voir qu'elle est déjà vérifier pour ne garder que les
+% bouts de programme o`la vérif demande plus de travail.
+% Si le programme satisfait le pré-post, la réduction est vide.
+@inproceedings{Harman2001,
+ title = {Pre/Post Conditioned Slicing},
+ author = "Mark Harman and Rob Hierons and Chris Fox and Sebastian Danicic and John Howroyd",
+ booktitle = {ICSM '01: Proceedings of the IEEE International Conference on Software Maintenance (ICSM'01)},
+ year = {2001},
+ isbn = {0-7695-1189-9},
+ pages = {138},
+ publisher = {IEEE Computer Society},
+ address = {Washington, DC, USA},
+ }
+%--------------------------------------------
+% le slicing utiliser pour confronter deux versions d'un programme.
+@article{65980,
+ author = {Susan Horwitz and Jan Prins and Thomas Reps},
+ title = {Integrating noninterfering versions of programs},
+ journal = {ACM Trans. Program. Lang. Syst.},
+ volume = {11},
+ number = {3},
+ year = {1989},
+ issn = {0164-0925},
+ pages = {345--387},
+ url = {http://doi.acm.org/10.1145/65979.65980},
+ doi = {10.1145/65979.65980},
+ publisher = {ACM Press},
+ address = {New York, NY, USA},
+ comment = {Slicing to compare two versions of a program},
+ }
+%--------------------------------------------
+@article{Ferrante87,
+ author = {Jeanne Ferrante and Karl J. Ottenstein and Joe D. Warren},
+ title = {The program dependence graph and its use in optimization},
+ journal = {ACM Trans. Program. Lang. Syst.},
+ volume = {9},
+ number = {3},
+ year = {1987},
+ issn = {0164-0925},
+ pages = {319--349},
+ url = {http://doi.acm.org/10.1145/24039.24041},
+ publisher = {ACM Press},
+ address = {New York, NY, USA},
+ comment = {Introduce the function PDG (program dependence graph)},
+ }
+%--------------------------------------------
+@inproceedings{Ottenstein84,
+ author = {Karl J. Ottenstein and Linda M. Ottenstein},
+ title = {The program dependence graph in a software development environment},
+ booktitle = {SDE 1: Proceedings of the first ACM SIGSOFT/SIGPLAN software engineering symposium on Practical software development environments},
+ year = {1984},
+ isbn = {0-89791-131-8},
+ pages = {177--184},
+ url = {http://doi.acm.org/10.1145/800020.808263},
+ publisher = {ACM Press},
+ address = {New York, NY, USA},
+ }
+%--------------------------------------------
+@inproceedings{ sinha99systemdependencegraphbased,
+ author = "Saurabh Sinha and Mary Jean Harrold and Gregg Rothermel",
+ title = "System-Dependence-Graph-Based Slicing of Programs with Arbitrary Interprocedural Control Flow",
+ booktitle = "International Conference on Software Engineering",
+ pages = "432--441",
+ year = "1999",
+ url = "http://citeseer.nj.nec.com/article/sinha98systemdependencegraphbased.html"
+}
+
+
+%--------------------------------------------
+@misc{ reps93wisconsin,
+ author = "T. Reps",
+ title = "The wisconsin program-integration system reference manual: Release",
+ text = "T. Reps. The wisconsin program-integration system reference manual: Release
+ 2.0. Technical Report Unpublished report, University of Wisconsin, Madison,
+ WI, July 1993.",
+ year = "1993",
+ url = "http://citeseer.nj.nec.com/reps93wisconsin.html"
+}
+
+%--------------------------------------------
+@inproceedings{ lyle97using,
+ author = "J. Lyle and D. Wallace",
+ title = "Using the Unravel Program Slicing Tool to Evaluate High Integrity Software",
+ booktitle = "Proceedings of Software Quality Week",
+ month = "May",
+ year = "1997",
+ url = "http://citeseer.ist.psu.edu/lyle97using.html"
+}
+%--------------------------------------------
+@misc{unravel,
+ key = "Unravel",
+ title = "Unravel",
+ url = "http://www.itl.nist.gov/div897/sqg/unravel/unravel.html"
+}
+%--------------------------------------------
+@misc{CodeSurfeur,
+ key = "CodeSurfeur",
+ title = "CodeSurfeur",
+ url = "http://www.codesurfer.com/"
+}
+%--------------------------------------------
+@PHDTHESIS{ weiser79,
+ author = "Mark Weiser",
+ title = "Program slices: formal, psychological, and practical investigations
+ of an automatic program abstraction method.",
+ school = "University of Michigan, Ann Arbor",
+ year = "1979"
+ }
+%--------------------------------------------
+@inproceedings{weiser81,
+ author = {Mark Weiser},
+ title = {Program slicing},
+ booktitle = {ICSE '81: Proceedings of the 5th international conference on Software engineering},
+ year = {1981},
+ isbn = {0-89791-146-6},
+ pages = {439--449},
+ location = {San Diego, California, United States},
+ publisher = {IEEE Press},
+ address = {Piscataway, NJ, USA},
+ }
+%--------------------------------------------
+% A LIRE : discution sur différents types de flots de données.
+@inproceedings{ cartwright89semantics,
+ author = "R. Cartwright and M. Felleisen",
+ title = "The semantics of program dependence",
+ booktitle = "Proceedings of the {ACM} {SIGPLAN} '89 Conference on Programming Language Design and Implementation",
+ journal = "SIGPLAN Notices",
+ volume = "24-7",
+ month = "June",
+ address = "Portland, OR",
+ pages = "13--27",
+ year = "1989",
+ url = "http://citeseer.ist.psu.edu/cartwright89semantic.html"
+}
+%--------------------------------------------
+% Bonne idée de slicing avec des Pre/Post mais ne dit pas grand chose...
+% Je ne comprend pas bien comment on peut enlever des affectations
+% en propageant une precondition en avant...
+@inproceedings{Chung-2001,
+ author = {I. S. Chung and W. K. Lee and G. S. Yoon and Y. R. Kwon},
+ title = {Program slicing based on specification},
+ booktitle = {SAC '01: Proceedings of the 2001 ACM symposium on Applied computing},
+ year = {2001},
+ isbn = {1-58113-287-5},
+ pages = {605--609},
+ location = {Las Vegas, Nevada, United States},
+ url = {http://doi.acm.org/10.1145/372202.372784},
+ publisher = {ACM Press},
+ address = {New York, NY, USA},
+ }
+
+%--------------------------------------------
+@article{survey2005,
+ author = {Baowen Xu and Ju Qian and Xiaofang Zhang and Zhongqiang Wu and Lin Chen},
+ title = {A brief survey of program slicing},
+ journal = {SIGSOFT Softw. Eng. Notes},
+ volume = {30},
+ number = {2},
+ year = {2005},
+ issn = {0163-5948},
+ pages = {1--36},
+ url = {http://doi.acm.org/10.1145/1050849.1050865},
+ publisher = {ACM Press},
+ address = {New York, NY, USA},
+ }
+%--------------------------------------------
+% Article très clair avec une bonne introduction (def. CFG, PDG, postdom, ...)
+% Deux méthodes pour calculer un slicing en présence de GOTO.
+% Définition et preuve d'une "correct executable slice"
+@article{Choi94,
+ author = {Jong-Deok Choi and Jeanne Ferrante},
+ title = {Static slicing in the presence of goto statements},
+ journal = {ACM Trans. Program. Lang. Syst.},
+ volume = {16},
+ number = {4},
+ year = {1994},
+ issn = {0164-0925},
+ pages = {1097--1113},
+ url = {http://doi.acm.org/10.1145/183432.183438},
+ publisher = {ACM Press},
+ address = {New York, NY, USA},
+ }
+%--------------------------------------------
+% Traitement des goto après slicing normal : bonne idée.
+% On ne modifie pas les graphes de dépendances,
+% mais on sélectionne après coup les GOTO dont le 1er postdominateur sélectionné% diffère du 1er successeur lexical sélectionné.
+@inproceedings{ agrawal94slicing,
+ author = "Hiralal Agrawal",
+ title = "On Slicing Programs with Jump Statements",
+ booktitle = "{SIGPLAN} Conference on Programming Language Design and Implementation",
+ pages = "302--312",
+ year = "1994",
+ url = "http://citeseer.ist.psu.edu/agrawal94slicing.html"
+}
+%--------------------------------------------
+% A LIRE : amélioration de agrawal94slicing
+@misc{ harman98new,
+ author = "M. Harman and S. Danicic",
+ title = "A new algorithm for slicing unstructured programs",
+ text = "Harman, M. and Danicic, S. (1998). A new algorithm for slicing unstructured
+ programs. Journal of Software Maintenance, 10(6):415-441.",
+ year = "1998",
+ url = "http://citeseer.ist.psu.edu/harman98new.html"
+}
+%--------------------------------------------
+% A LIRE : amélioration récente (2002) du traitement des goto
+% + traitement spécifique des switch.
+@inproceedings{ kumar02better,
+ author = "Sumit Kumar and Susan Horwitz",
+ title = "Better Slicing of Programs with Jumps and Switches",
+ booktitle = "Fundamental Approaches to Software Engineering",
+ pages = "96--112",
+ year = "2002",
+ url = "http://citeseer.ist.psu.edu/kumar02better.html"
+}
+%--------------------------------------------
+% Très bon résumé de la problématique des dépendances de contrôle.
+% Traitement des cas sans point unique de sortie
+% Slicing préservant la non-terminaison et la terminaison prématurée (exit)
+% version courte publiée à ESOP2005.
+@techreport{ ranganath04new,
+ author = "V. Ranganath and T. Amtoft and A. Banerjee and M. Dwyer and J.
+Hatcliff",
+ title = "A new foundation for control-dependence and slicing for modern
+program structures",
+ institution = "SAnToS Lab., Kansas State University",
+ number = "8",
+ year = "2004",
+ url = "citeseer.ist.psu.edu/ranganath05new.html",
+ note = "(Note : {\it Une version courte de ce document a été publiée à ESOP'2005})."
+}
+%--------------------------------------------
+% Intéressant : à étudier plus en détail en ce qui concerne les transformations
+% code et les problèmes que ça pose.
+@misc{ danicic-syntaxdirected,
+ author = "Sebastian Danicic and Mark Harman and Malcolm Munro and Dave Binkley and
+ Mohammed Daoudi and Lin Hu and Xingyuan Zhang",
+ title = "Syntax-Directed Amorphous Slicing",
+ url = "http://citeseer.ist.psu.edu/579941.html"
+}
+%--------------------------------------------
+% Slicing avec transformation des instructions
+% Règles de transformation
+%+ détail de 2 cas d'étude (A LIRE)
+@article{harman03,
+ author = "Mark Harman, David Binkley and Sebastian Danicic",
+ title = "Amorphous Program Slicing",
+ journal = "Journal of Systems and Software",
+ volume = "68",
+ number = "1",
+ pages = "45--64",
+ year = "2003"
+}
+%--------------------------------------------
+@inproceedings{ harman01gustt,
+ author = "Mark Harman and Lin Hu and Malcolm C. Munro and Xingyuan Zhang",
+ title = "{GUSTT}: An Amorphous Slicing System which Combines Slicing and Transformation",
+ booktitle = "Working Conference on Reverse Engineering",
+ pages = "271--280",
+ year = "2001",
+ url = "http://citeseer.ist.psu.edu/harman01gustt.html"
+}
+%--------------------------------------------
+%
+@misc{ daoudi-consus,
+ author = "M. Daoudi and L. Ouarbya and J. Howroyd and S. Danicic and Mark Marman
+ and Chris Fox and M. P. Ward",
+ title = "ConSUS: A Scalable Approach to Conditional Slicing",
+ year = "2002",
+ url = "http://citeseer.ist.psu.edu/daoudi02consus.html"
+}
+%--------------------------------------------
+% Intro bien intéressante : A LIRE !
+@misc{ ward2002,
+ author = "Ward, Martin",
+ title = "Program Slicing via FermaT Transformations",
+ year = "2002",
+ url = "http://citeseer.ist.psu.edu/ward02program.html" }
+%--------------------------------------------
+% Description détaillée d'un outil de slicing conditionel
+% sur un sous ensemble 'simple' de C.
+% différence entre
+% * "Control Dependance Sensive"
+% = suppression des instructions qui ne sont pas executées
+% lorsque les entrées satisfont la pré
+% * et "Control Dependance Inensive"
+ % = suppression de tout ce qui est inutile pour que le pg slicé
+% et le programme d'origine donnent les mêmes résultats en tout point
+% lorsque les entrées satisfont la pré
+% (par exemple, on peut supprimer un if si on sait dans quelle branche on passe)
+
+@article{fox-consit,
+ author = "Chris Fox and Sebastian Danicic and Mark Harman and Robert M. Hierons",
+ title = "ConSIT: A Fully Automated Conditioned Program Slicer",
+ journal = "Software: Practice and Experience",
+ volume = {34},
+ number = {1},
+ year = {2004},
+ pages = {15--46},
+ url = {http://dx.doi.org/10.1002/spe.556}
+}
+%--------------------------------------------
+@inproceedings{Field95,
+ author = {John Field and G. Ramalingam and Frank Tip},
+ title = {Parametric program slicing},
+ booktitle = {POPL '95: Proceedings of the 22nd ACM SIGPLAN-SIGACT symposium on Principles of programming languages},
+ year = {1995},
+ isbn = {0-89791-692-1},
+ pages = {379--392},
+ address = {San Francisco, California, United States},
+ url = {http://doi.acm.org/10.1145/199448.199534},
+ publisher = {ACM Press},
+ }
+%--------------------------------------------
+@article{176473,
+ author = {David Binkley},
+ title = {Precise executable interprocedural slices},
+ journal = {ACM Lett. Program. Lang. Syst.},
+ volume = {2},
+ number = {1-4},
+ year = {1993},
+ issn = {1057-4514},
+ pages = {31--45},
+ url = {http://doi.acm.org/10.1145/176454.176473},
+ publisher = {ACM Press},
+ address = {New York, NY, USA},
+ comment = {about generating a program slice that is compilable},
+ }
+%--------------------------------------------
+@inproceedings{Comuzzi,
+ author = {Joseph J. Comuzzi and Johnson M. Hart},
+ title = {Program Slicing Using Weakest Preconditions},
+ booktitle = {FME '96: Proceedings of the Third International Symposium of Formal Methods Europe on Industrial Benefit and Advances in Formal Methods},
+ year = {1996},
+ isbn = {3-540-60973-3},
+ pages = {557--575},
+ publisher = {Springer-Verlag},
+ address = {London, UK},
+url = {http://portal.acm.org/citation.cfm?id=729684},
+ comment = {about a slicing that keeps all that impact a property ?},
+ }
+%--------------------------------------------
+@inproceedings{ fox01backward,
+ author = "C. Fox and M. Harman and R. Hierons and S. Danicic",
+ title = {Backward Conditioning: A New Program Specialisation Technique and Its Application to Program Comprehension},
+ booktitle = {IWPC '01: Proceedings of the 9th International Workshop on Program Comprehension},
+ year = {2001},
+ pages = {89--97},
+ publisher = {IEEE Computer Society},
+ address = {Washington, DC, USA},
+ url = "http://citeseer.ist.psu.edu/fox01backward.html"
+}
+%--------------------------------------------
+%--------------------------------------------
diff --git a/doc/slicing/call.fig b/doc/slicing/call.fig
new file mode 100644
index 0000000000000000000000000000000000000000..1d2f99cf6ff2918c92c73adf0f8ae8f7379be5c6
--- /dev/null
+++ b/doc/slicing/call.fig
@@ -0,0 +1,78 @@
+#FIG 3.2
+Landscape
+Center
+Metric
+A4
+100.00
+Single
+-2
+1200 2
+6 4320 5670 4680 6030
+1 4 0 1 0 0 50 -1 20 0.000 1 0.0000 4410 5850 45 45 4365 5850 4455 5850
+1 4 0 1 0 0 50 -1 20 0.000 1 0.0000 4590 5850 45 45 4545 5850 4635 5850
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 4500 5850 162 162 4500 5850 4635 5940
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 4500 5670 4500 6030
+-6
+6 4770 7020 5130 7380
+1 4 0 1 0 0 50 -1 20 0.000 1 0.0000 4860 7200 45 45 4815 7200 4905 7200
+1 4 0 1 0 0 50 -1 20 0.000 1 0.0000 5040 7200 45 45 4995 7200 5085 7200
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 4950 7200 162 162 4950 7200 5085 7290
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 4950 7020 4950 7380
+-6
+6 6570 5895 6930 6255
+1 4 0 1 0 0 50 -1 20 0.000 1 0.0000 6660 6075 45 45 6615 6075 6705 6075
+1 4 0 1 0 0 50 -1 20 0.000 1 0.0000 6840 6075 45 45 6795 6075 6885 6075
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 6750 6075 162 162 6750 6075 6885 6165
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 6750 5895 6750 6255
+-6
+6 7020 6570 7380 6930
+1 4 0 1 0 0 50 -1 20 0.000 1 0.0000 7110 6750 45 45 7065 6750 7155 6750
+1 4 0 1 0 0 50 -1 20 0.000 1 0.0000 7290 6750 45 45 7245 6750 7335 6750
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 7200 6750 162 162 7200 6750 7335 6840
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 7200 6570 7200 6930
+-6
+2 1 0 2 0 0 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 3.00 90.00 150.00
+ 5895 7065 6165 7065
+2 1 0 2 0 0 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 3.00 90.00 150.00
+ 7020 6480 6885 6300
+2 1 0 2 0 0 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 3.00 90.00 150.00
+ 4770 6660 4680 6480
+2 1 0 2 0 0 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 3.00 90.00 150.00
+ 5850 6165 5625 6165
+3 2 0 1 0 7 50 -1 -1 0.000 0 0 0 3
+ 7110 6750 6660 6525 6660 6075
+ 0.000 -1.000 0.000
+3 2 0 1 0 7 50 -1 -1 0.000 0 0 0 3
+ 7290 6750 7290 6300 6840 6075
+ 0.000 -1.000 0.000
+3 2 0 1 0 7 50 -1 -1 0.000 0 0 0 3
+ 4860 7200 4410 6525 4410 5850
+ 0.000 -1.000 0.000
+3 2 0 1 0 7 50 -1 -1 0.000 0 0 0 3
+ 5040 7200 5040 6300 4590 5850
+ 0.000 -1.000 0.000
+3 2 1 1 0 7 50 -1 -1 4.000 0 0 0 3
+ 6660 6075 5130 6435 4410 5895
+ 0.000 -1.000 0.000
+3 2 1 1 0 7 50 -1 -1 4.000 0 0 0 4
+ 6840 6075 6480 5670 5175 6075 4590 5850
+ 0.000 -1.000 -1.000 0.000
+3 2 1 1 0 7 50 -1 -1 4.000 0 0 0 4
+ 5040 7200 5850 6840 6975 7200 7290 6750
+ 0.000 -1.000 -1.000 0.000
+3 2 1 1 0 0 50 -1 -1 4.000 0 0 0 4
+ 4860 7200 4950 6885 5400 6750 6120 6840
+ 0.000 -1.000 -1.000 0.000
+4 0 0 50 -1 0 12 0.0000 4 90 180 4500 7245 cs\001
+4 0 0 50 -1 0 12 0.0000 4 90 180 4050 5895 ce\001
+4 0 0 50 -1 0 12 0.0000 4 90 90 7110 6075 e\001
+4 0 0 50 -1 0 12 0.0000 4 90 90 7515 6795 s\001
+4 0 0 50 -1 0 12 0.0000 4 180 135 7470 6300 gi\001
diff --git a/doc/slicing/choose_call.fig b/doc/slicing/choose_call.fig
new file mode 100644
index 0000000000000000000000000000000000000000..de59292eb760bb2ea6504d35c5f0c95a2da5289a
--- /dev/null
+++ b/doc/slicing/choose_call.fig
@@ -0,0 +1,223 @@
+#FIG 3.2
+Landscape
+Center
+Metric
+A4
+41.00
+Single
+-2
+1200 2
+6 6840 3510 8190 3960
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 6840 3510 8190 3510 8190 3960 6840 3960 6840 3510
+4 0 0 50 -1 0 10 0.0000 4 135 645 6930 3690 call(c) = g\001
+4 0 0 50 -1 0 10 0.0000 4 150 1110 6930 3885 /\\ add_outputs (g)\001
+-6
+6 5715 6750 6705 7065
+2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5
+ 6705 7065 6705 6750 5715 6750 5715 7065 6705 7065
+4 0 0 50 -1 0 10 0.0000 4 135 840 5805 6975 in(c) ~in(g) ?\001
+-6
+6 4050 7200 5490 7965
+2 2 0 3 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4095 7245 5445 7245 5445 7920 4095 7920 4095 7245
+4 0 0 50 -1 0 10 0.0000 4 135 840 4230 7830 /\\ in(g)~in(c)\001
+4 0 0 50 -1 0 10 0.0000 4 135 645 4230 7425 call(c) = g\001
+4 0 0 50 -1 0 10 0.0000 4 135 1020 4230 7650 /\\ out(g)~out(c)\001
+-6
+6 5580 8010 6930 8415
+4 0 0 50 -1 0 10 0.0000 4 150 1320 5580 8145 apply missing_inputs\001
+4 0 0 50 -1 0 10 0.0000 4 150 1350 5580 8370 = modify_call_inputs\001
+-6
+6 7020 7245 8415 7920
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 7020 7245 8415 7245 8415 7920 7020 7920 7020 7245
+4 0 0 50 -1 0 10 0.0000 4 150 1245 7110 7830 /\\ missing_inputs(c)\001
+4 0 0 50 -1 0 10 0.0000 4 135 1020 7110 7650 /\\ out(g)~out(c)\001
+4 0 0 50 -1 0 10 0.0000 4 135 645 7110 7425 call(c) = g\001
+-6
+6 7245 1620 8910 2115
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 7245 1620 8910 1620 8910 2115 7245 2115 7245 1620
+4 0 0 50 -1 0 10 0.0000 4 135 405 7380 1845 call=g\001
+4 0 0 50 -1 0 10 0.0000 4 150 1365 7380 2040 /\\ missing_outputs (c)\001
+-6
+6 7875 5625 9225 6300
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 7875 5625 9225 5625 9225 6300 7875 6300 7875 5625
+4 0 0 50 -1 0 10 0.0000 4 135 645 8010 5805 call(c) = g\001
+4 0 0 50 -1 0 10 0.0000 4 150 1110 8010 6000 /\\ change_call(g2)\001
+4 0 0 50 -1 0 10 0.0000 4 135 1095 8010 6195 /\\ out(g2)~out(c)\001
+-6
+6 8685 6525 10080 7290
+4 0 0 50 -1 0 10 0.0000 4 150 885 8685 6855 missing_input\001
+4 0 0 50 -1 0 10 0.0000 4 150 1155 8685 7050 -> change_call(g2)\001
+4 0 0 50 -1 0 10 0.0000 4 135 1395 8685 7245 (pre : out(g2)~out(c))\001
+4 0 0 50 -1 0 10 0.0000 4 105 465 8685 6660 USER :\001
+-6
+6 8640 2250 10035 3015
+4 0 0 50 -1 0 10 0.0000 4 150 1035 8640 2580 missing_outputs\001
+4 0 0 50 -1 0 10 0.0000 4 150 1155 8640 2775 -> change_call(g2)\001
+4 0 0 50 -1 0 10 0.0000 4 135 1395 8640 2970 (pre : out(g2)~out(c))\001
+4 0 0 50 -1 0 10 0.0000 4 105 465 8640 2385 USER :\001
+-6
+6 7245 2520 8010 2745
+2 4 0 1 0 7 50 -1 18 0.000 0 0 7 0 0 5
+ 8010 2745 7245 2745 7245 2520 8010 2520 8010 2745
+4 0 0 50 -1 2 10 0.0000 4 105 600 7335 2700 MODE ?\001
+-6
+6 -360 1035 990 1575
+4 1 0 50 -1 0 10 0.0000 4 150 1140 315 1170 apr\350s modification\001
+4 1 0 50 -1 0 10 0.0000 4 135 1020 315 1350 du marquage de c\001
+4 1 0 50 -1 0 10 0.0000 4 135 1320 315 1530 avec sig(c) <> bottom\001
+-6
+6 -225 6300 1125 6840
+6 -225 6705 1125 6840
+4 1 0 50 -1 0 10 0.0000 4 135 1275 450 6810 pour chaque appelant\001
+-6
+4 1 0 50 -1 0 10 0.0000 4 150 1140 450 6435 apr\350s modification\001
+4 1 0 50 -1 0 10 0.0000 4 150 990 450 6615 d'une entr\351e de g\001
+-6
+6 5490 4995 6840 5715
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 5490 4995 6840 4995 6840 5715 5490 5715 5490 4995
+4 0 0 50 -1 0 10 0.0000 4 135 900 5670 5220 call(c) = None\001
+4 0 0 50 -1 0 10 0.0000 4 150 1035 5670 5415 /\\ change_call(g)\001
+4 0 0 50 -1 0 10 0.0000 4 135 1020 5670 5610 /\\ out(g)~out(c)\001
+-6
+6 2025 5220 4365 5715
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2025 5220 4365 5220 4365 5715 2025 5715 2025 5220
+4 0 0 50 -1 0 10 0.0000 4 135 900 2115 5400 call(c) = None\001
+4 0 0 50 -1 0 10 0.0000 4 150 2115 2115 5595 /\\ add_outputs (g)+change_call(g)\001
+-6
+6 4500 5220 5490 5580
+4 0 0 50 -1 0 10 0.0000 4 150 960 4500 5535 add_outputs(g)\001
+4 0 0 50 -1 0 10 0.0000 4 135 345 4500 5355 apply\001
+-6
+6 2025 4590 3105 4860
+2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5
+ 3105 4860 3105 4590 2025 4590 2025 4860 3105 4860
+4 0 0 50 -1 0 10 0.0000 4 135 960 2070 4770 out(g)~out(c)?\001
+-6
+6 3600 3825 4770 4410
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 3600 3825 4770 3825 4770 4410 3600 4410 3600 3825
+4 0 0 50 -1 0 10 0.0000 4 135 900 3735 4050 call(c) = None\001
+4 0 0 50 -1 0 10 0.0000 4 105 720 3735 4245 /\\ NewSlice\001
+-6
+6 2250 3870 3015 4095
+2 4 0 1 0 7 50 -1 18 0.000 0 0 7 0 0 5
+ 3015 4095 2250 4095 2250 3870 3015 3870 3015 4095
+4 0 0 50 -1 2 10 0.0000 4 105 600 2340 4050 MODE ?\001
+-6
+6 2070 2880 3240 3465
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2070 2880 3240 2880 3240 3465 2070 3465 2070 2880
+4 0 0 50 -1 0 10 0.0000 4 135 900 2205 3105 call(c) = None\001
+4 0 0 50 -1 0 10 0.0000 4 150 840 2205 3300 /\\ choose_call\001
+-6
+6 3420 3015 5805 3375
+4 0 0 50 -1 0 10 0.0000 4 135 1320 3870 3330 (pre : out(g)~out(c))\001
+4 0 0 50 -1 0 10 0.0000 4 150 2355 3420 3150 USER : choose_call -> change_call (g)\001
+-6
+1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 1485 6480 64 64 1485 6480 1549 6480
+1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 6210 6030 64 64 6210 6030 6274 6030
+1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 2475 4275 64 64 2475 4275 2539 4275
+2 1 1 1 0 7 50 -1 -1 6.000 0 0 -1 1 0 3
+ 2 1 1.00 60.00 120.00
+ 3240 3195 6210 3195 6210 4995
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3
+ 2 1 1.00 60.00 120.00
+ 3105 4725 5670 4725 5670 4995
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3
+ 2 1 1.00 60.00 120.00
+ 2025 1215 2475 1215 2475 2880
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3
+ 2 1 1.00 60.00 120.00
+ 7200 2610 2880 2610 2880 2880
+2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 3
+ 2 1 1.00 60.00 120.00
+ 8415 7470 8550 7470 8550 6300
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ 2475 4860 2475 5220
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ 2475 4095 2475 4590
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 4
+ 2 1 1.00 60.00 120.00
+ 7470 3960 7470 6480 6390 6480 6390 6750
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ 7470 2160 7470 2520
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ 6210 5715 6210 6030
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ -450 1215 990 1215
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ 6210 6030 6210 6750
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3
+ 2 1 1.00 60.00 120.00
+ 5715 6930 4725 6930 4725 7200
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ -450 6480 1440 6480
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ 2025 1890 7245 1890
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 3
+ 2 1 1.00 60.00 120.00
+ 6705 6930 7695 6930 7695 7245
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ 7470 2745 7470 3510
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 4
+ 2 1 1.00 60.00 120.00
+ 7695 7920 7695 8235 4725 8235 4725 7920
+2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 3
+ 2 1 1.00 60.00 120.00
+ 8550 2115 8550 5445 6840 5445
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ 2475 3465 2475 3870
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ 3015 4005 3600 4005
+2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5
+ 2025 1350 2025 1080 990 1080 990 1350 2025 1350
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ 1485 1350 1485 1755
+2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5
+ 2025 2025 2025 1755 990 1755 990 2025 2025 2025
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 4
+ 2 1 1.00 60.00 120.00
+ 1485 2025 1485 6480 6075 6480 6075 6750
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ 7875 6030 6255 6030
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ 4365 5400 5490 5400
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ 3600 4275 2520 4275
+4 0 0 50 -1 0 10 0.0000 4 105 345 2565 4995 NON\001
+4 0 0 50 -1 0 10 0.0000 4 105 285 3195 4545 OUI\001
+4 0 0 50 -1 0 10 0.0000 4 105 285 5400 6885 OUI\001
+4 0 0 50 -1 0 10 0.0000 4 105 345 6840 6885 NON\001
+4 0 0 50 -1 0 10 0.0000 4 150 1410 6660 2340 apply missing_outputs\001
+4 0 0 50 -1 0 10 0.0000 4 105 345 2070 1170 NON\001
+4 0 0 50 -1 0 10 0.0000 4 105 345 2070 1845 NON\001
+4 0 0 50 -1 0 10 0.0000 4 105 765 6345 2880 call <- None\001
+4 0 0 50 -1 0 10 0.0000 4 105 285 1575 1530 OUI\001
+4 1 0 50 -1 0 10 0.0000 4 135 735 1485 1260 call(c) = g ?\001
+4 1 0 50 -1 0 10 0.0000 4 135 990 1485 1935 out(g)~out(c) ?\001
+4 0 0 50 -1 0 10 0.0000 4 105 285 1575 2205 OUI\001
+4 0 0 50 -1 0 10 0.0000 4 150 1095 5895 6255 apply change_call\001
+4 0 0 50 -1 0 10 0.0000 4 105 270 2565 4500 -> g \001
+4 0 0 50 -1 0 10 0.0000 4 150 1095 2160 3645 apply choose_call\001
diff --git a/doc/slicing/conclusion.tex b/doc/slicing/conclusion.tex
new file mode 100644
index 0000000000000000000000000000000000000000..cfa67fd91a7ea5fb75899f741a5f830fab6cf888
--- /dev/null
+++ b/doc/slicing/conclusion.tex
@@ -0,0 +1,20 @@
+\chapter{Conclusion}
+
+En conclusion, on peut dire que les fonctionnalités de base de l'outil
+n'ont pas beaucoup évoluées en 2008, mais il a gagné en robustesse,
+et en précision~: ce qui était le principal objectif de l'année.\\
+
+La principale évolution concerne la gestion des annotations
+que ce soit lors de la production du résultat (que garde-t-on~?)
+que comme critère de \slicing. Ce point est encore en développement
+car il nécessite l'utilisation de fonctions externes au module
+qui n'existent pas encore.\\
+
+La boîte à outils de \slicing peut être considéré comme stable,
+même si elle peut encore évoluer pour répondre à de nouveaux besoins,
+
+L'annexe \ref{sec-projets} présente en particulier
+certains projets qui ont été évoqués,
+et dont certain pourrait éventuellement venir compléter l'outil.
+
+
diff --git a/doc/slicing/exple2.fig b/doc/slicing/exple2.fig
new file mode 100644
index 0000000000000000000000000000000000000000..063357672eaa09c8a334ddef7d364827f57d3708
--- /dev/null
+++ b/doc/slicing/exple2.fig
@@ -0,0 +1,266 @@
+#FIG 3.2
+Landscape
+Center
+Metric
+A4
+100.00
+Single
+-2
+1200 2
+5 1 0 1 0 5 20 -1 20 0.000 0 1 0 0 2700.000 4365.000 2700 4275 2610 4365 2700 4455
+5 1 0 1 0 5 20 -1 20 0.000 0 1 0 0 3375.000 3960.000 3375 3870 3285 3960 3375 4050
+5 1 0 1 0 5 20 -1 20 0.000 0 1 0 0 3375.000 3735.000 3375 3645 3285 3735 3375 3825
+5 1 0 1 0 5 20 -1 20 0.000 0 1 0 0 3375.000 3375.000 3375 3285 3285 3375 3375 3465
+5 1 0 1 0 5 20 -1 20 0.000 0 1 0 0 3375.000 3150.000 3375 3060 3285 3150 3375 3240
+5 1 0 1 0 5 20 -1 20 0.000 0 1 0 0 3375.000 2700.000 3375 2610 3285 2700 3375 2790
+5 1 0 1 0 2 21 -1 20 0.000 0 0 0 0 3375.000 3150.000 3375 3060 3465 3150 3375 3240
+5 1 0 1 0 2 21 -1 20 0.000 0 0 0 0 3375.000 2700.000 3375 2610 3465 2700 3375 2790
+5 1 0 1 0 2 22 -1 20 0.000 0 0 0 0 2925.000 3150.000 2925 3060 3015 3150 2925 3240
+5 1 0 1 0 2 22 -1 20 0.000 0 0 0 0 2925.000 2700.000 2925 2610 3015 2700 2925 2790
+5 1 0 1 0 2 22 -1 20 0.000 0 0 0 0 3825.000 3735.000 3825 3645 3915 3735 3825 3825
+5 1 0 1 0 2 22 -1 20 0.000 0 0 0 0 3825.000 2700.000 3825 2610 3915 2700 3825 2790
+5 1 0 1 0 2 22 -1 20 0.000 0 0 0 0 3375.000 3735.000 3375 3645 3465 3735 3375 3825
+5 1 0 1 0 2 22 -1 20 0.000 0 0 0 0 3375.000 3375.000 3375 3285 3465 3375 3375 3465
+5 1 0 1 0 5 14 -1 20 0.000 0 1 0 0 2925.000 3150.000 2925 3060 2835 3150 2925 3240
+5 1 0 1 0 5 14 -1 20 0.000 0 1 0 0 3600.000 3735.000 3600 3645 3510 3735 3600 3825
+5 1 0 1 0 5 14 -1 20 0.000 0 1 0 0 3600.000 2700.000 3600 2610 3510 2700 3600 2790
+5 1 0 1 0 5 14 -1 20 0.000 0 1 0 0 3150.000 3150.000 3150 3060 3060 3150 3150 3240
+5 1 0 1 0 5 14 -1 20 0.000 0 1 0 0 3150.000 2700.000 3150 2610 3060 2700 3150 2790
+5 1 0 1 0 5 14 -1 20 0.000 0 1 0 0 2925.000 2700.000 2925 2610 2835 2700 2925 2790
+5 1 0 1 0 5 13 -1 20 0.000 0 1 0 0 675.000 3150.000 675 3060 585 3150 675 3240
+5 1 0 1 0 5 13 -1 20 0.000 0 1 0 0 900.000 3150.000 900 3060 810 3150 900 3240
+5 1 0 1 0 5 13 -1 20 0.000 0 1 0 0 1350.000 3150.000 1350 3060 1260 3150 1350 3240
+5 1 0 1 0 5 13 -1 20 0.000 0 1 0 0 1350.000 2700.000 1350 2610 1260 2700 1350 2790
+5 1 0 1 0 5 13 -1 20 0.000 0 1 0 0 900.000 2700.000 900 2610 810 2700 900 2790
+5 1 0 1 0 5 13 -1 20 0.000 0 1 0 0 675.000 2700.000 675 2610 585 2700 675 2790
+5 1 0 1 0 5 41 -1 20 0.000 0 1 0 0 2925.000 3150.000 2925 3060 2835 3150 2925 3240
+5 1 0 1 0 5 41 -1 20 0.000 0 1 0 0 2925.000 2700.000 2925 2610 2835 2700 2925 2790
+5 1 0 1 0 5 41 -1 20 0.000 0 1 0 0 3375.000 3735.000 3375 3645 3285 3735 3375 3825
+5 1 0 1 0 5 41 -1 20 0.000 0 1 0 0 3375.000 3375.000 3375 3285 3285 3375 3375 3465
+5 1 0 1 0 5 41 -1 20 0.000 0 1 0 0 3375.000 3150.000 3375 3060 3285 3150 3375 3240
+5 1 0 1 0 5 41 -1 20 0.000 0 1 0 0 3375.000 2700.000 3375 2610 3285 2700 3375 2790
+5 1 0 1 0 2 42 -1 20 0.000 0 0 0 0 3825.000 3735.000 3825 3645 3915 3735 3825 3825
+5 1 0 1 0 2 42 -1 20 0.000 0 0 0 0 3375.000 3150.000 3375 3060 3465 3150 3375 3240
+5 1 0 1 0 2 42 -1 20 0.000 0 0 0 0 3825.000 2700.000 3825 2610 3915 2700 3825 2790
+5 1 0 1 0 2 42 -1 20 0.000 0 0 0 0 3375.000 2700.000 3375 2610 3465 2700 3375 2790
+5 1 0 1 0 5 43 -1 20 0.000 0 1 0 0 675.000 3150.000 675 3060 585 3150 675 3240
+5 1 0 1 0 5 43 -1 20 0.000 0 1 0 0 1125.000 3150.000 1125 3060 1035 3150 1125 3240
+5 1 0 1 0 2 43 -1 20 0.000 0 0 0 0 1125.000 3150.000 1125 3060 1215 3150 1125 3240
+5 1 0 1 0 2 43 -1 20 0.000 0 0 0 0 1575.000 3150.000 1575 3060 1665 3150 1575 3240
+5 1 0 1 0 2 43 -1 20 0.000 0 0 0 0 1575.000 2700.000 1575 2610 1665 2700 1575 2790
+5 1 0 1 0 2 43 -1 20 0.000 0 0 0 0 1125.000 2700.000 1125 2610 1215 2700 1125 2790
+5 1 0 1 0 5 43 -1 20 0.000 0 1 0 0 1125.000 2700.000 1125 2610 1035 2700 1125 2790
+5 1 0 1 0 5 43 -1 20 0.000 0 1 0 0 675.000 2700.000 675 2610 585 2700 675 2790
+5 1 0 1 0 5 31 -1 20 0.000 0 1 0 0 3600.000 3735.000 3600 3645 3510 3735 3600 3825
+5 1 0 1 0 5 31 -1 20 0.000 0 1 0 0 3600.000 2700.000 3600 2610 3510 2700 3600 2790
+5 1 0 1 0 5 31 -1 20 0.000 0 1 0 0 3150.000 3150.000 3150 3060 3060 3150 3150 3240
+5 1 0 1 0 5 31 -1 20 0.000 0 1 0 0 3150.000 2700.000 3150 2610 3060 2700 3150 2790
+5 1 0 1 0 5 31 -1 20 0.000 0 1 0 0 900.000 3150.000 900 3060 810 3150 900 3240
+5 1 0 1 0 5 31 -1 20 0.000 0 1 0 0 1350.000 3150.000 1350 3060 1260 3150 1350 3240
+5 1 0 1 0 5 31 -1 20 0.000 0 1 0 0 900.000 2700.000 900 2610 810 2700 900 2790
+5 1 0 1 0 5 31 -1 20 0.000 0 1 0 0 1350.000 2700.000 1350 2610 1260 2700 1350 2790
+5 1 0 1 0 5 51 -1 20 0.000 0 1 0 0 4725.000 3510.000 4725 3420 4635 3510 4725 3600
+5 1 0 1 0 1 51 -1 20 0.000 0 0 0 0 4725.000 3825.000 4725 3735 4815 3825 4725 3915
+5 1 0 1 0 2 51 -1 20 0.000 0 0 0 0 4725.000 4185.000 4725 4095 4815 4185 4725 4275
+5 1 0 1 0 5 23 -1 20 0.000 0 1 0 0 1125.000 3150.000 1125 3060 1035 3150 1125 3240
+5 1 0 1 0 5 23 -1 20 0.000 0 1 0 0 1125.000 2700.000 1125 2610 1035 2700 1125 2790
+5 1 0 1 0 2 23 -1 20 0.000 0 0 0 0 1125.000 2700.000 1125 2610 1215 2700 1125 2790
+5 1 0 1 0 2 23 -1 20 0.000 0 0 0 0 1575.000 2700.000 1575 2610 1665 2700 1575 2790
+5 1 0 1 0 2 23 -1 20 0.000 0 0 0 0 1575.000 3150.000 1575 3060 1665 3150 1575 3240
+5 1 0 1 0 2 23 -1 20 0.000 0 0 0 0 675.000 2700.000 675 2610 765 2700 675 2790
+5 1 0 1 0 2 23 -1 20 0.000 0 0 0 0 675.000 3150.000 675 3060 765 3150 675 3240
+5 1 0 1 0 2 23 -1 20 0.000 0 0 0 0 1125.000 3150.000 1125 3060 1215 3150 1125 3240
+6 4500 2565 6165 3285
+5 1 0 1 0 5 15 -1 20 0.000 0 1 0 0 5400.000 3150.000 5400 3060 5310 3150 5400 3240
+5 1 0 1 0 5 15 -1 20 0.000 0 1 0 0 5400.000 2700.000 5400 2610 5310 2700 5400 2790
+5 1 0 1 0 5 15 -1 20 0.000 0 1 0 0 4950.000 2700.000 4950 2610 4860 2700 4950 2790
+5 1 0 1 0 5 40 -1 20 0.000 0 1 0 0 4950.000 3150.000 4950 3060 4860 3150 4950 3240
+5 1 0 1 0 5 40 -1 20 0.000 0 1 0 0 4950.000 2700.000 4950 2610 4860 2700 4950 2790
+5 1 0 1 0 1 42 -1 20 0.000 0 0 0 0 5850.000 3150.000 5850 3060 5940 3150 5850 3240
+5 1 0 1 0 1 42 -1 20 0.000 0 0 0 0 5850.000 2700.000 5850 2610 5940 2700 5850 2790
+5 1 0 1 0 5 30 -1 20 0.000 0 1 0 0 5400.000 3150.000 5400 3060 5310 3150 5400 3240
+5 1 0 1 0 5 30 -1 20 0.000 0 1 0 0 5400.000 2700.000 5400 2610 5310 2700 5400 2790
+6 4500 2565 6165 3285
+5 1 0 1 0 1 21 -1 20 0.000 0 0 0 0 5850.000 3150.000 5850 3060 5940 3150 5850 3240
+5 1 0 1 0 1 21 -1 20 0.000 0 0 0 0 5850.000 2700.000 5850 2610 5940 2700 5850 2790
+5 1 0 1 0 1 22 -1 20 0.000 0 0 0 0 4950.000 3150.000 4950 3060 5040 3150 4950 3240
+5 1 0 1 0 1 22 -1 20 0.000 0 0 0 0 4950.000 2700.000 4950 2610 5040 2700 4950 2790
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 5400 2700 90 90 5400 2700 5490 2700
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 5400 3150 90 90 5400 3150 5490 3150
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 4950 2700 90 90 4950 2700 5040 2700
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 4950 3150 90 90 4950 3150 5040 3150
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 5850 3150 90 90 5850 3150 5940 3150
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 5850 2700 90 90 5850 2700 5940 2700
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 4770 2700 4500 3060
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4500 2700 6165 2700 6165 3150 4500 3150 4500 2700
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 75.00
+ 4950 2790 4950 3060
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 75.00
+ 5400 2790 5400 3060
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 75.00
+ 5850 2790 5850 3060
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 75.00
+ 5015 2768 5375 3083
+4 1 0 50 -1 0 10 0.0000 4 105 120 5130 3060 X\001
+4 1 0 50 -1 0 10 0.0000 4 105 120 5580 3060 Y\001
+4 1 0 50 -1 0 10 0.0000 4 105 75 6030 3060 g\001
+4 1 0 50 -1 0 10 0.0000 4 105 75 4590 2835 g\001
+4 1 0 50 -1 0 10 0.0000 4 75 75 4815 2655 u\001
+4 1 0 50 -1 0 10 0.0000 4 75 75 5265 2655 v\001
+4 1 0 50 -1 0 10 0.0000 4 75 120 5715 2655 w\001
+-6
+-6
+6 540 2565 1710 2835
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 675 2700 90 90 675 2700 765 2700
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 900 2700 90 90 900 2700 990 2700
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 1125 2700 90 90 1125 2700 1215 2700
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 1350 2700 90 90 1350 2700 1440 2700
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 1575 2700 90 90 1575 2700 1665 2700
+-6
+6 540 3015 1710 3285
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 675 3150 90 90 675 3150 765 3150
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 900 3150 90 90 900 3150 990 3150
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 1125 3150 90 90 1125 3150 1215 3150
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 1350 3150 90 90 1350 3150 1440 3150
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 1575 3150 90 90 1575 3150 1665 3150
+-6
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 3150 3150 90 90 3150 3150 3240 3150
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 3150 3375 90 90 3150 3375 3240 3375
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 3600 3735 90 90 3600 3735 3690 3735
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 3825 3960 90 90 3825 3960 3915 3960
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 3600 3960 90 90 3600 3960 3690 3960
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 3600 2700 90 90 3600 2700 3690 2700
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 3825 2700 90 90 3825 2700 3915 2700
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 3375 2700 90 90 3375 2700 3465 2700
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 3150 2700 90 90 3150 2700 3240 2700
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 2925 2700 90 90 2925 2700 3015 2700
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 3365 3730 90 90 3365 3730 3455 3730
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 3815 3730 90 90 3815 3730 3905 3730
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 2935 3370 90 90 2935 3370 3025 3370
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 3385 3370 90 90 3385 3370 3475 3370
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 3385 3145 90 90 3385 3145 3475 3145
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 2935 3145 90 90 2935 3145 3025 3145
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 3150 4365 90 90 3150 4365 3240 4365
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 3600 4365 90 90 3600 4365 3690 4365
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 4050 4365 90 90 4050 4365 4140 4365
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 2700 4365 90 90 2700 4365 2790 4365
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 3375 3960 90 90 3375 3960 3465 3960
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 1125 3465 90 90 1125 3465 1215 3465
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 1350 3465 90 90 1350 3465 1440 3465
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 1575 3465 90 90 1575 3465 1665 3465
+1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 900 3465 90 90 900 3465 990 3465
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 2483 2700 2258 3060
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 75.00
+ 2925 2790 2925 3060
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 75.00
+ 3150 2790 3150 3060
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 75.00
+ 3375 2790 3375 3060
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 75.00
+ 3375 3465 3375 3645
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 4
+ 1 1 1.00 60.00 75.00
+ 3375 4050 3375 4095 3150 4095 3150 4275
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 75.00
+ 3600 4050 3600 4275
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 4
+ 1 1 1.00 60.00 75.00
+ 3825 4050 3825 4095 4050 4095 4050 4275
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2475 3150 2700 3150 2700 3375 2475 3375 2475 3150
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2700 3150 3510 3150 3510 3375 2700 3375 2700 3150
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2925 3735 3150 3735 3150 3960 2925 3960 2925 3735
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 75.00
+ 3600 2790 3600 3645
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 75.00
+ 3825 2790 3825 3645
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 3150 3735 3960 3735 3960 3960 3150 3960 3150 3735
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 4
+ 1 1 1.00 60.00 75.00
+ 3150 4095 2925 4095 2700 4095 2700 4275
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2250 2700 4275 2700 4275 4365 2250 4365 2250 2700
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 1575 3240 1575 3375
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 1350 3240 1350 3375
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 1125 3240 1125 3375
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 1125 3240 900 3375
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 900 3240 900 3375
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 675 3240 900 3375
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 900 3240 1125 3375
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 675 3240 1125 3375
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 75.00
+ 675 2790 675 3060
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 75.00
+ 900 2790 900 3060
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 75.00
+ 1125 2790 1125 3060
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 75.00
+ 1350 2790 1350 3060
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 75.00
+ 1575 2790 1575 3060
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 540 3150 1710 3150 1710 3465 540 3465 540 3150
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 540 3150 360 3150 360 3465 540 3465 540 3150
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 0 2700 2025 2700 2025 3825 0 3825 0 2700
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 495 2700 0 3195
+4 0 0 50 -1 0 12 0.0000 4 135 60 2295 2835 f\001
+4 1 0 50 -1 0 10 0.0000 4 105 135 2610 3105 c1\001
+4 1 0 50 -1 0 10 0.0000 4 105 135 3060 3690 c2\001
+4 1 0 50 -1 0 10 0.0000 4 105 120 3240 4275 X\001
+4 1 0 50 -1 0 10 0.0000 4 105 120 3690 4275 Y\001
+4 1 0 50 -1 0 10 0.0000 4 105 60 2790 4275 f\001
+4 1 0 50 -1 0 10 0.0000 4 105 90 4140 4275 Z\001
+4 1 0 50 -1 0 10 0.0000 4 105 75 2565 3285 g\001
+4 1 0 50 -1 0 10 0.0000 4 105 75 3060 3870 g\001
+4 1 0 50 -1 0 10 0.0000 4 75 60 2925 2565 a\001
+4 1 0 50 -1 0 10 0.0000 4 105 75 3150 2565 b\001
+4 1 0 50 -1 0 10 0.0000 4 75 60 3375 2565 c\001
+4 1 0 50 -1 0 12 0.0000 4 135 90 3600 2565 d\001
+4 1 0 50 -1 0 12 0.0000 4 90 90 3825 2565 e\001
+4 0 0 51 -1 0 10 0.0000 4 135 990 4950 3555 marque m en m1\001
+4 0 0 51 -1 0 10 0.0000 4 135 990 4950 3870 marque m en m2\001
+4 0 0 51 -1 0 10 0.0000 4 135 1185 4950 4230 marque spare en m2\001
+4 1 0 50 -1 0 10 0.0000 4 105 120 1125 3690 X\001
+4 1 0 50 -1 0 10 0.0000 4 105 120 1350 3690 Y\001
+4 1 0 50 -1 0 10 0.0000 4 105 90 1575 3690 Z\001
+4 1 0 50 -1 0 10 0.0000 4 105 120 900 3690 N\001
+4 1 0 50 -1 0 12 0.0000 4 135 60 675 2565 I\001
+4 1 0 50 -1 0 12 0.0000 4 135 75 900 2565 J\001
+4 1 0 50 -1 0 12 0.0000 4 135 135 1125 2565 K\001
+4 1 0 50 -1 0 12 0.0000 4 135 105 1350 2565 L\001
+4 1 0 50 -1 0 12 0.0000 4 135 165 1575 2565 M\001
+4 1 0 50 -1 0 12 0.0000 4 135 60 450 3375 f\001
+4 1 0 50 -1 0 12 0.7854 4 135 360 225 2925 main\001
diff --git a/doc/slicing/exple2v0.pdf b/doc/slicing/exple2v0.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..644513d26120a090ea73a3b5b14d52af292d22e0
Binary files /dev/null and b/doc/slicing/exple2v0.pdf differ
diff --git a/doc/slicing/exple2v1-1.pdf b/doc/slicing/exple2v1-1.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..7d821b6a59ed2869753f01ea0c03d2689162cc79
Binary files /dev/null and b/doc/slicing/exple2v1-1.pdf differ
diff --git a/doc/slicing/exple2v1-2.pdf b/doc/slicing/exple2v1-2.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..84850912b8f1b5f18a604e8aa30b6f562d5691cc
Binary files /dev/null and b/doc/slicing/exple2v1-2.pdf differ
diff --git a/doc/slicing/exple2v1-3.pdf b/doc/slicing/exple2v1-3.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..aad6063f1b39f90136293ba1dfe76318f0255186
Binary files /dev/null and b/doc/slicing/exple2v1-3.pdf differ
diff --git a/doc/slicing/exple2v1-4.pdf b/doc/slicing/exple2v1-4.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..9d665443e13baeaaae0d12cfe356d749a6d5508c
Binary files /dev/null and b/doc/slicing/exple2v1-4.pdf differ
diff --git a/doc/slicing/exple2v2-1.pdf b/doc/slicing/exple2v2-1.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..218a7e55a1e5d53d55a89eee9fd984ba16a9781f
Binary files /dev/null and b/doc/slicing/exple2v2-1.pdf differ
diff --git a/doc/slicing/exple2v2-2.pdf b/doc/slicing/exple2v2-2.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..4593112e2f5dc3c0af633c0a05c89400c5d4cfb1
Binary files /dev/null and b/doc/slicing/exple2v2-2.pdf differ
diff --git a/doc/slicing/exple2v2-3.pdf b/doc/slicing/exple2v2-3.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..f0b2b16294ac04bd6c2cc15493bb05a2c54fd345
Binary files /dev/null and b/doc/slicing/exple2v2-3.pdf differ
diff --git a/doc/slicing/exple2v3-1.pdf b/doc/slicing/exple2v3-1.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..f0a389d3b848397281e7ee5088d01d2e8d234b87
Binary files /dev/null and b/doc/slicing/exple2v3-1.pdf differ
diff --git a/doc/slicing/exple2v3-2.pdf b/doc/slicing/exple2v3-2.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..decf18a4c15a76cc5ffe6fc9df111e82a9a2ee69
Binary files /dev/null and b/doc/slicing/exple2v3-2.pdf differ
diff --git a/doc/slicing/exple2v3-3.pdf b/doc/slicing/exple2v3-3.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..3fe63e2bd280ed94ac8a627997c631b300fd8811
Binary files /dev/null and b/doc/slicing/exple2v3-3.pdf differ
diff --git a/doc/slicing/exple2v3-4.pdf b/doc/slicing/exple2v3-4.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..afc8e61196c714677a7d02079d33a1aae3627730
Binary files /dev/null and b/doc/slicing/exple2v3-4.pdf differ
diff --git a/doc/slicing/exple2v4-1.pdf b/doc/slicing/exple2v4-1.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..253178920e4656ccc7817d6f9cfb626885e38fbc
Binary files /dev/null and b/doc/slicing/exple2v4-1.pdf differ
diff --git a/doc/slicing/exple2v4-2.pdf b/doc/slicing/exple2v4-2.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..92ffac9208c07267c158b6552b64f44b71a08ce0
Binary files /dev/null and b/doc/slicing/exple2v4-2.pdf differ
diff --git a/doc/slicing/fonction.tex b/doc/slicing/fonction.tex
new file mode 100644
index 0000000000000000000000000000000000000000..faa7a9ae02c1e8d06a5b5906b19ea195086e4601
--- /dev/null
+++ b/doc/slicing/fonction.tex
@@ -0,0 +1,223 @@
+\chapter{Réduction d'une fonction}\label{sec-filtrage-fct}
+
+\section{Fonction spécialisée}
+
+On appelle \indextxtdef{fonction spécialisée}{fonction!spécialisée}
+la réduction d'une fonction source obtenue suite à l'application d'une ou
+plusieurs actions. Ce chapitre expose comment est représentée
+cette réduction, et comment elle est calculée.\\
+
+La réduction d'une fonction doit distinguer les instructions visibles
+de celles qui ne le sont pas.
+Une information booléenne, attachée à chaque instruction,
+devrait donc suffire Ã
+indiquer si celle-ci appartient ou non à la fonction spécialisée, mais
+la mise en place d'un outil de navigation incite à enrichir les informations
+calculées. On décide donc d'avoir
+une annotation plus précise du flot de données, que l'on appelle
+{\bf marquage},
+pour préciser la raison de la présence ou de l'absence d'un certain élément.
+Cela peut permettre de visualiser l'impact des instructions d'une
+fonction sur un point de programme (contrôle, données utilisées, déclaration
+nécessaires, etc.)\\
+
+Le document qui présente le calcul de PDG expose les éléments qui composent le
+graphe de dépendance. La plupart correspondent à une instruction.
+Quelques exceptions néanmoins~:
+\begin{itemize}
+\item les éléments représentant les entrées/sorties d'une fonction
+ ne sont pas associés à une instruction,
+\item le label d'une instruction est représenté par un élément en plus de ceux
+qui représentent l'instruction,
+\item un appel de fonction est représenté par plusieurs éléments.\\
+\end{itemize}
+
+Nous ne nous considérons pas, dans un premier temps,
+la spécialisation des fonctions appelées qui sera étudiée
+dans le chapitre \ref{sec-interproc}.
+L'appel de fonction est donc simplement vu pour l'instant comme
+une instruction représentée par plusieurs éléments.
+
+
+Par contre, nous distinguons la visibilité d'un label de celle de l'instruction
+associée. Dans la suite, le label sera souvent considéré comme une instruction Ã
+part entière.\\
+
+On peut donc dire que
+la fonction spécialisée contient un \indexdef{marquage}
+qui fait correspondre une \indexdef{marque}
+aux instructions et labels d'une fonction.
+
+\section{Marquage}
+
+On calcule le marquage d'une fonction en réponse à une requête.
+Celle-ci se traduit en général en terme d'éléments du PDG.\\
+
+Initialement, le marquage
+peut contenir le résultat de précédents calculs ou être
+nouvellement créé, c'est-à -dire vide.\\
+
+Le calcul élémentaire est très simple~:
+il consiste à parcourir le PDG,
+à calculer la marque pour chaque élément,
+et à l'associer à l'instruction ou au label correspondant
+en la combinant avec l'éventuelle valeur précédente.\\
+
+Une idée de l'algorithme appliqué est présenté en \ref{sec-algo-mark-fct}.
+
+
+\subsection{Passage à un point de programme}
+
+Une première requête consiste à marquer les éléments du flot
+qui servent à déterminer ce qui permet de passer
+Ã un point de programme.\\
+
+La marque propagée s'appelle
+\indextxtdef{marque de contrôle}{marque!de contrôle},
+et se note {\it mC}.
+% , mais on utilise une
+% \indextxtdef{marque de contrôle initiale}{marque!de contrôle initiale}
+% ($mC_0$) pour annoter le point de
+% départ de la recherche.
+% Cela permet de retrouver ce point par la suite, et de ne
+% pas sélectionner l'instruction concernée.\\
+
+Pour faire ce calcul, on propage la marque dans les dépendances de contrôle du
+point choisi, puis récursivement dans toutes les dépendances des points ainsi
+sélectionnés. Cela correspond à marquer {\it mC} tous les éléments
+de l'ensemble $R_{L0}$.
+
+\begin{exemple}
+\begin{tabular}{l|p{8cm}}
+\begin{tabular}{>{\itshape}c c l}
+mC && \verb!x = y+1;!\\
+ && \verb!a = 0;!\\
+ && \verb!b = 10;!\\
+ && \verb!...!\\
+mC && \verb!if (x > 0) {!\\
+ && \verb!...!\\
+ && \verb!L: a += b;!\\
+ && \verb!...!\\
+ && \verb!}!\\
+\end{tabular}
+&
+Il s'agit ici de sélectionner ce qui contrôle le passage au point \verbtt{L}.
+Le test \verb!x>0! est donc marqué {\it mC} ainsi que le calcul de \verbtt{x}
+dont dépend ce test.
+\end{tabular}
+\end{exemple}
+
+\subsection{Valeur d'une donnée}
+
+On peut également demander à sélectionner ce qui permet de calculer une donnée
+Ã un point de programme.
+On peut par exemple demander à ne garder que ce qui permet de calculer l'une des
+sorties d'une fonction.\\
+
+La première étape consiste à trouver l'élément, ou les éléments,
+correspondant dans le graphe.
+Des éléments particuliers représentent les sorties de la fonction.
+Pour des calculs internes,
+on peut utiliser l'identification d'une affectation pour parler de la donnée
+affectée, ou alors
+il faut disposer de l'état utilisé lors de la construction du graphe.
+On peut alors retrouver les éléments qui ont participé au calcul en un point
+de n'importe quelle
+donnée, du moins lorsque le point considéré se trouve dans sa portée.\\
+
+La marque associée au calcul d'une donnée s'appelle
+\indextxtdef{marque de valeur}{marque!de valeur}
+et se note {\it mV}. Elle sert, comme son nom l'indique,
+à annoter les éléments qui participent au calcul
+de la valeur de la donnée demandée. \\
+
+Les données qui permettent de calculer l'adresse de la case modifiée (partie
+gauche de l'affectation)
+sont annotés par une \indextxtdef{marque d'adresse}{marque!d'adresse} ($mA$).
+Il s'agit par exemple du calcul de l'indice d'un élément de tableau ou d'un
+pointeur.\\
+
+Les éléments
+qui permettent d'atteindre le point de programme sont marqués {\it mC}.
+
+\begin{exemple}
+\begin{tabular}{m{4cm} c | m{8cm}}
+\begin{tabular}{>{\itshape}c c l}
+mCA && \verb!x = y+1;!\\
+mV && \verb!b = 10;!\\
+ && \verb!...!\\
+mC && \verb!if (x > 0) {!\\
+ && \verb!...!\\
+ && \verb!L: t[x] = b;!\\
+ && \verb!...!\\
+ && \verb!}!\\
+\end{tabular}
+&&
+Il s'agit ici de sélectionner ce qui participe au calcul de l'instruction
+située au point \verbtt{L}.
+Le test \verb!x>0! est donc marqué {\it mC} ainsi que le calcul de \verbtt{x}
+dont dépend ce test. La valeur de \verbtt{b} participe au calcul de la partie
+droite et est donc marqué {\it mV}. La partie gauche dépend de
+\verbtt{x} qui doit donc avoir la marque {\it mA}. On voit donc que \verbtt{x}
+cumule deux informations et est donc marqué {\it mCA}.
+\end{tabular}
+\end{exemple}
+
+
+\subsection{Éléments superflus}
+
+On a vu que le marquage est relatif aux instructions,
+et que certaines instructions (appels de fonctions) sont représentées
+par plusieurs éléments du PDG. Si on ne souhaite pas décomposer les
+instructions (ie. spécialiser les appels de fonctions),
+il peut arriver qu'une même instruction corresponde à des éléments
+visibles et d'autres invisibles. Ces derniers, et leurs dépendances,
+sont alors marqués
+\indextxtdef{superflus}{marque!superflu} (marque $mS$).
+Certaines instructions deviennent alors visibles alors qu'elles ne sont pas
+strictement nécessaires au calcul demandé.\\
+
+\begin{exemple}
+\begin{center}
+\begin{tabular}{m{4cm}p{1cm}m{6cm}}
+\begin{verbatim}
+int G;
+int f (int x, int y) {
+ G = x + 1;
+ return y + 2;
+}
+int g (void) {
+ int a = 1;
+ int b = a+1;
+ return f (b, a);
+}
+\end{verbatim}
+&&
+Si l'utilisateur demande à sélectionner ce qui permet de calculer la valeur
+de retour de \verbtt{g}, on n'aurait en fait besoin que de la valeur de \verbtt{a},
+mais comme on ne spécialise pas \verbtt{f}, il faut aussi marquer
+l'instruction qui calcule \verbtt{b} comme superflue.
+\end{tabular}
+\end{center}
+\end{exemple}
+
+\subsection{Marques}
+
+En résumé, les marques possibles sont les suivantes~:
+\begin{center}
+\begin{tabular}{|>{\itshape}c!{:}l|}
+ \hline
+ mV & marque de valeur \\
+ mC & marque de contrôle \\
+ mA & marque d'adresse \\
+ mS & marque pour un élément superflu\\
+ \hline
+\end{tabular}
+\end{center}
+
+Les marques $mV,mC,mA$ peuvent se superposer lorsqu'un élément participe au
+calcul pour plusieurs raisons. On notera par exemple $mVA$ la marque associée Ã
+un élément qui participe à la valeur et au calcul d'adresse. Par la suite,
+on appelle marque $mCAV$ toute marque de cette famille.\\
+
+La marque $mS$ est l'élément neutre de la combinaison.
diff --git a/doc/slicing/intercmds.tex b/doc/slicing/intercmds.tex
new file mode 100644
index 0000000000000000000000000000000000000000..90f9b011872dda397cdcabcda0ae73c46db484e8
--- /dev/null
+++ b/doc/slicing/intercmds.tex
@@ -0,0 +1,256 @@
+
+\chapter{Détail des actions} \label{app-actions}
+
+Ce chapitre présente une fiche signalétique pour chaque action du calcul
+interprocédurale présentées au chapitre \ref{sec-interproc}.
+Elle correspondent aux commandes telles qu'elles ont été spécifiées,
+et il peut y avoir quelques différences par rapport à ce qui a été implémenté,
+mais il s'agit de différences mineures (principalement les noms).
+Pour plus de détails, le lecteur est invité à consulter la document du code
+qui sera toujours la plus à jour.\\
+
+\newcommand{\proto}[2]{
+ \section{#1}\labact{#1}{2}
+ \centerline{\textit{#1}(#2)}
+ \bb
+ }
+\newcommand{\precond}{{\bf Précondition}}
+\newcommand{\param}{{\bf Paramètres}}
+\newcommand{\creable}{{\bf Création par l'utilisateur}}
+\newcommand{\modifiable}{{\bf Modifiable par l'utilisateur}}
+\newcommand{\generable}{{\bf Génération automatique}}
+\newcommand{\application}{{\bf Application}}
+\newcommand{\genere}{{\bf Génération}}
+\newcommand{\modifie}{{\bf Modifications}}
+
+Les indications suivantes sont données pour chaque action~:
+\begin{itemize}
+ \item \param~: indique le sens des paramètres de l'action,
+ \item \precond~: indique les conditions éventuelles de création et/ou
+ d'application,
+ \item \creable~: indique si l'utilisateur peut la créer,
+ \item \modifiable~: indique si l'utilisateur peut la modifier lorsqu'elle est
+ dans la liste d'attente,
+ \item \generable~: indique si cette action peut être générée par l'outil,
+ et précise dans quels cas,
+ \item \application~: détaille ce qu'il se passe quand cette action est
+ appliquée,
+ \item \genere~: donne la liste des actions pouvant être générées,
+ \item \modifie~: indique si une spécialisation peut être crée ou modifiée.
+\end{itemize}
+
+\proto{NewSlice}{$f_0$}
+
+\begin{itemize}
+ \item \param~: $f_0$ est la fonction source pour laquelle on souhaite créer
+ une nouvelle spécialisation.
+ \item \precond~: néant.
+ \item \creable~: oui.
+ \item \modifiable~: oui (suppression).
+ \item \generable~: oui, par \actChooseCall.
+ \item \application~:
+ crée une nouvelle spécialisation $f_i$, initialement sans aucun marquage
+ (tout invisible).
+ \item \genere~: néant.
+ \item \modifie~: création d'une nouvelle $f_i$.
+\end{itemize}
+
+\proto{AddUserMark}{$f_i, (e,m)$}
+
+\begin{itemize}
+ \item \param~: $f_i$ est la fonction dont on veut modifier le marquage,
+ $e$ un élément à marquer, $m$ la marque à lui ajouter.
+ Différentes version de cette action peut être proposée pour faciliter la
+ désignation de $e$ et le choix de la marque $m$.
+ \item \precond~: $f_i$ doit exister et $e$ désigner un élément valide de $f$.
+ \item \creable~: oui.
+ \item \modifiable~: oui (suppression).
+ \item \generable~: non.
+ \item \application~: ajoute $m$ Ã la marque $m1$ de $e$ dans $f_i$
+ et propage dans les dépendances.
+ \item \genere~: $\actExamineCalls$.
+ \item \modifie~: modification de $f_i$.
+\end{itemize}
+
+\proto{ExamineCalls}{$f_i$}
+
+\begin{itemize}
+ \item \param~: $f_i$ est la fonction dont le marquage a été modifié
+ et pour laquelle il faut vérifier les appels.
+ \item \precond~: $f_i$ doit exister.
+ \item \creable~: non.
+ \item \modifiable~: non.
+ \item \generable~: oui.
+ \item \application~:
+ vérifie la cohérence du marquage de chaque appel de fonction $c$
+ de \call(f) et également des éventuelles appels à $f_i$.
+ \item \genere~:
+ $\actChooseCall$ et/ou $\actMissingOutputs$ si le marquage de
+ certains appels de fonction a été modifié, et $\actMissingInputs$ si
+ $f_i$ est appelée et que les entrées de certains appels sont insuffisamment
+ marquées.
+ \item \modifie~: rien.
+\end{itemize}
+
+
+\proto{ChooseCall}{$c, f_i$}
+
+\begin{itemize}
+ \item \param~: appel $c$ dans la fonction spécialisée $f_i$.
+ \item \precond~: néant.
+ \item \creable~: non.
+ \item \modifiable~: oui, elle peut être remplacée par un $\actChangeCall(c,
+ f_i, g_j)$ (voir les conditions de création de cette action).
+ \item \generable~: oui, quand le marquage de $f_i$ est modifié et que
+ l'appel $c$ devient visible, cette action est générée pour lui
+ attribuer une fonction à appeler.
+ \item \application~: détermine la fonction à appeler en tenant compte du mode
+ de fonctionnement.
+ \item \genere~: \actChangeCall{} et éventuellement \actNewSlice{} et
+ \actAddOutputMarks{}.
+ \item \modifie~: rien.
+\end{itemize}
+
+\proto{ChangeCall}{$c, f_i, g_j$}
+
+\begin{itemize}
+ \item \param~: on considère l'appel $c$ de $f_i$, $g_j$ est la fonction Ã
+ appeler.
+ \item \precond~: $\Call(f_0)(c)=g_0$ et la signature de sortie de $g_j$
+ doit être compatible avec $\sigc(c, f_i)$.
+ \item \creable~: oui.
+ \item \modifiable~: oui, mais seulement s'il l'a initialement créée.
+ \item \generable~: oui, par un \actChooseCall.
+ \item \application~: $\Call(f_i)(c)=g_j$ et les marques des entrées de $g_j$
+ sont propagées dans $f_i$ ($\actModifCallInputs(c, f_i)$).
+ \item \genere~: l'action \actModifCallInputs{} est directement
+ appliquée, mais elle peut générer d'autres actions (voir
+ \refact{ModifCallInputs}{2}).
+ \item \modifie~: $f_i$.
+\end{itemize}
+
+
+\proto{MissingInputs}{$c, f_i$}
+
+\begin{itemize}
+ \item \param~:
+ appel $c$ dans la fonction spécialisée $f_i$,
+ \item \precond~: la fonction appelée nécessite plus d'entrées que n'en calcule
+ $f_i$.
+ \item \creable~:
+ non,
+ \item \modifiable~:
+ oui, elle peut être remplacée par un $\actChangeCall(c, f_i, g_j)$ (voir les
+ conditions de création de cette action).
+ \item \generable~:
+ oui, lorsque la fonction $\Call(f_i)(c) = g_j$ a été modifiée, et qu'elle
+ nécessite le marquage d'entrées qui ne le sont pas $\sigc(c,f_i)$.
+ \item \application~: équivalente à \actModifCallInputs{} ou \actChooseCall{}
+ en fonction du mode de fonctionnement.
+ \item \genere~: dépend de l'application (voir ci-dessus).
+ \item \modifie~: dépend de l'application (voir ci-dessus).
+\end{itemize}
+
+
+\proto{ModifCallInputs}{$c, f_i$}
+
+\begin{itemize}
+ \item \param~: appel $c$ dans la fonction spécialisée $f_i$.
+ \item \precond~: $\Call(f_i)(c) = g_j$
+ \item \creable~: non.
+ \item \modifiable~: non.
+ \item \generable~: oui, par l'application de \actMissingInputs{} dans certains
+ modes.
+ \item \application~: propage les marques des entrées de $g_j$ au niveau de
+ l'appel $c$ de $f_i$ et et dans le dépendances.
+ \item \genere~:
+ $\actChooseCall$ et/ou $\actMissingOutputs$ si le marquage de
+ certains appels de fonction a été modifié, et $\actMissingInputs$ si
+ $f_i$ est appelée et que les entrées de certains appels sont insuffisamment
+ marquées.
+ \item \modifie~: $f_i$.
+\end{itemize}
+
+\proto{MissingOutputs}{$c, f_i$}
+
+\begin{itemize}
+ \item \param~: appel $c$ dans la fonction spécialisée $f_i$
+ \item \precond~: $\Call(f_i)(c) = g_j$
+ \item \creable~: non.
+ \item \modifiable~: oui, elle peut être remplacée par un
+ $\actChangeCall(c, f_i, g_k)$
+ (voir les conditions de création de cette action).
+ \item \generable~: oui, lorsque le marquage de $c$ dans $f_i$ est modifié,
+ que l'appel est attribué à $g_j$, et que les sorties de $g_j$
+ sont insuffisantes.
+ \item \application~: dépend du mode~:
+ \begin{itemize}
+ \item \actAddOutputMarks{}
+ \item ou \actChooseCall{}
+ \end{itemize}
+ \item \genere~: dépend de l'application (voir ci-dessus).
+ \item \modifie~: dépend de l'application (voir ci-dessus).
+\end{itemize}
+
+\proto{AddOutputMarks}{$f_i, \outsigf$}
+
+\begin{itemize}
+ \item \param~: $f_i$ est la fonction dont on veut modifier le marquage,
+ $\outsigf$ indique les marques qui doivent être ajouté aux sorties.
+ \item \precond~: $f_i$ doit exister et $\outsigf$ correspondre à une signature
+ des sorties de $f$.
+ \item \creable~: non.
+ \item \modifiable~: non.
+ \item \generable~: oui, par l'application de \actMissingOutputs.
+ \item \application~:
+ les marques de $\outsigf$ sont ajoutées aux marques $m2$ des
+ sorties de $f_i$ et propagées.
+ \item \genere~:
+ \actChooseCall{} et/ou \actMissingOutputs{} si le marquage de
+ certains appels de fonction a été modifié, et \actMissingInputs{} si
+ $f_i$ est appelée et que les entrées de certains appels sont insuffisamment
+ marquées.
+ \item \modifie~: modification de $f_i$.
+\end{itemize}
+
+\proto{CopySlice}{$f_i$}
+
+\begin{itemize}
+ \item \param~: $f_i$ est la fonction spécialisée à copier.
+ \item \precond~: $f_i$ doit exister.
+ \item \creable~: oui.
+ \item \modifiable~: oui (suppression),
+ \item \generable~: non.
+ \item \application~:
+ crée une nouvelle spécialisation $f_j$ de $f$ dont le marquage et les appels
+ sont identiques à ceux de $f_i$. Attention, à l'issue de cette action,
+ $f_j$ n'est pas appelée.
+ \item \genere~: non.
+ \item \modifie~: création d'une nouvelle $f_j$.
+\end{itemize}
+
+\proto{Combine}{$f_i, f_j$}
+
+\begin{itemize}
+ \item \param~: $f_i$ et $f_j$ sont les fonctions spécialisées à combiner.
+ \item \precond~: $f_i$ et $f_j$ doivent exister.
+ \item \creable~: oui.
+ \item \modifiable~: oui (suppression),
+ \item \generable~: non.
+ \item \application~: calcule une nouvelle spécialisation $f_k$
+ \item \genere~: $\actChooseCall$
+ \item \modifie~: création et calcul de $f_k$.
+\end{itemize}
+
+\proto{DeleteSlice}{$f_i$}
+
+\begin{itemize}
+ \item \param~: $f_i$ est la fonction spécialisée à supprimer.
+ \item \precond~: $f_i$ ne doit pas être appelée.
+ \item \creable~: oui.
+ \item \modifiable~: oui (suppression).
+ \item \generable~: non.
+ \item \application~: $f_i$ est supprimée.
+ \item \genere~: néant.
+ \item \modifie~: $f_i$ est supprimée.
+\end{itemize}
diff --git a/doc/slicing/interexples.tex b/doc/slicing/interexples.tex
new file mode 100644
index 0000000000000000000000000000000000000000..20c59843be629e2d487c84fdfb95b6f1bfbc875d
--- /dev/null
+++ b/doc/slicing/interexples.tex
@@ -0,0 +1,206 @@
+
+\chapter{Exemple de marquage interprocédural}
+
+Cette partie présente comment les actions élémentaires précédemment présentées
+peuvent être utilisées pour répondre à des requêtes utilisateur de plus haut
+niveau.
+
+
+\section{Présentation de l'exemple}
+
+Nous allons voir différents exemple de marquage de l'exemple ci-dessous.
+Dans tous les cas, on considère que l'utilisateur souhaite n'avoir qu'une
+spécialisation par fonction source dans le résultat, et qu'il demande
+systématiquement la propagation de son marquage aux appelants.
+\bb
+
+Pour simplifier la présentation,
+comme on ne s'intéresse ici qu'à la propagation interprocédurale,
+on n'utilise qu'une marque élémentaire $m$ quelconque qui rend un élément
+visible et la marque \spare{} déjà mentionnée.
+
+\noindent\begin{tabular}{p{4cm}p{4.5cm}p{5cm}}
+\begin{verbatim}
+int X, Y;
+int g (int u, int v,
+ int w) {
+ lg1: X = u;
+ lg2: Y = u + v;
+ return w;
+ }
+\end{verbatim}
+&
+\begin{verbatim}
+int Z;
+int f (int a, int b,
+ int c, int d,
+ int e) {
+ int r;
+ lf1: r = g (a, b, c);
+ lf2: Z = g (r, d, e);
+ return X;
+ }
+\end{verbatim}
+&
+\begin{verbatim}
+int I, J, K, L, M, N;
+int main () {
+ lm1: /* ... */
+ lm2: N = f (I, J, K, L, M);
+ lm3: /* ... */
+ }
+\end{verbatim}
+\end{tabular}
+
+\bb\centerline{\uneimage{exple2v0}}\bb
+
+La légende indique comment sont représentées les marques sur les figures
+suivantes.
+
+\section{Cas 1}
+
+Supposons tout d'abord que l'utilisateur veuille sélectionner la sortie 0
+de $f$, et voyons comment se déroule le calcul.\bb
+
+On a vu en \S\ref{sec-propagate-to-calls} que cette requête de l'utilisateur se
+traduit par la séquence d'actions élémentaires suivantes~:
+\begin{itemize}
+ \item $f_1 = \actNewSlice (f_0)$,
+ \item $\actAddOutputMarks(f_1, (out_0, m))$
+ \item ${\mathit main}_1 = \actNewSlice ({\mathit main}_0)$,
+ \item $\actChangeCall(c, {\mathit main}_1, f_1)$.
+\end{itemize}
+
+On calcule tout d'abord le marquage de $f_1$ par simple propagation~:
+
+\bb{\centerline{\uneimage{exple2v1-1}}}\bb
+
+Puis, la seconde action
+génère $\actChooseCall(c_1, f_1)$ et $\actChooseCall(c_2, f_1)$.
+
+A l'application de la première de ces nouvelles actions,
+comme il n'y a pas encore de spécialisation pour $g$,
+on génère~:
+
+\begin{itemize}
+ \item $g_1 = \actNewSlice (g_0)$,
+ \item $\actAddOutputMarks(g_1, (out_0, m))$
+ \item $\actChangeCall(c_1, f_1, g_1)$
+\end{itemize}
+
+A l'issue de la construction de $g_1$, l'entrée $w$ a une marque $m_2$.
+L'application du \actChangeCall{}
+va donc déclencher un $\actModifCallInputs(c_1, f_1)$ qui va conduire à marquer
+l'entrée $c$ de $f_1$ comme $\spare$ (en plus de $m$ en $m_1$).
+
+\bb{\centerline{\uneimage{exple2v1-2}}}\bb
+
+L'application de $\actChooseCall(c_2, f_1)$ produit~:
+\begin{itemize}
+ \item $\actAddOutputMarks(g_1, (out_X, m))$ puisqu'on a choisi de n'avoir
+ qu'une spécialisation par fonction source,
+ \item et $\actChangeCall(c_2, f_1, g_1)$.
+\end{itemize}
+
+Comme $g_1$ est appelée en $c_1$,
+la modification de son marquage conduit à générer $\actMissingInputs(c_1, f_1)$,
+qui, vues les options, est directement traduit par
+$\actModifCallInputs(c_1, f_1)$.
+
+Puis, le $\actChangeCall{}$ va déclencher $\actModifCallInputs(c_2, f_1)$
+qui va marquer $e$ comme $\spare$.
+
+\bb{\centerline{\uneimage{exple2v1-3}}}\bb
+
+Finalement, il ne reste plus qu'Ã appliquer $\actChangeCall(c, {\mathit main}_1,
+f_1)$ qui conduit à appliquer $\actModifCallInputs(c, {\mathit main}_1)$
+et donc à propager le marquage de $f_1$ dans ${\mathit main}_1$.
+
+\bb{\centerline{\uneimage{exple2v1-4}}}
+
+
+\section{Cas 2}
+
+A partir du résultat du cas 1, l'utilisateur souhaite sélectionner le calcul de
+$Y$ dans $g_1$. \bb
+
+$\actAddUserMark(g_1, (out_Y, m))$ propage le marquage en $m_1$ à l'entrée $v$
+de $g_1$ ($u$ est déjà marquée).
+
+\bb{\centerline{\uneimage{exple2v2-1}}}\bb
+
+Puis comme $g_1$ est appelée, et qu'il manque des marques, deux actions
+$\actMissingInputs{}$ sont générées. Les options indiquent qu'elles doivent être
+traduites en $\actModifCallInputs(c_1, f_1)$ et $\actModifCallInputs(c_2, f_1)$.
+Ce qui conduit à marquer en $m_1$ les entrées $a, b, d$ de $f_1$.
+
+\bb{\centerline{\uneimage{exple2v2-2}}}\bb
+
+De même, la propagation va être effectuée dans ${\mathit main}_1$
+par l'application de $\actModifCallInputs(c, {\mathit main}_1)$.
+
+\bb{\centerline{\uneimage{exple2v2-3}}}\bb
+
+
+\section{Cas 3}
+
+Dans une nouvelle étude, l'utilisateur souhaite sélectionner le calcul de $X$
+dans $g$.
+\bb
+
+Comme dans le cas 1, cette requête se traduit par la création d'une fonction
+spécialisée $g_1$ et la propagation de son marquage à tous ses appels~:
+\begin{itemize}
+ \item $g_1 = \actNewSlice (g_0)$,
+ \item $\actAddOutputMarks(g_1, (out_X, m))$
+ \item $f_1 = \actNewSlice (f_0)$,
+ \item $\actChangeCall(c_1, f_1, g_1)$.
+ \item $\actChangeCall(c_2, f_1, g_1)$.
+ \item ${\mathit main}_1 = \actNewSlice ({\mathit main}_0)$,
+ \item $\actChangeCall(c, {\mathit main}_1, f_1)$.
+\end{itemize}
+
+On calcule tout d'abord le marquage de $g_1$~:
+
+\bb{\centerline{\uneimage{exple2v3-1}}}\bb
+
+Puis, les deux \actChangeCall{} dans $f_1$ conduisent à propager $m_1$~:
+
+\bb{\centerline{\uneimage{exple2v3-2}}}\bb
+
+La seconde propagation (lors de la modification de $c_2$)
+déclenche $\actMissingOutputs(c_1, f_1)$
+qui, au vue des options, se transforme en $\actAddOutputMarks(g_1,
+\outsigc(c_1))$. Ceci conduit à marquer $m_2$ la sortie 0 de $g_1$.
+Les $\actMissingInputs$ générés se transforme en $\actModifCallInputs(c_1, f_1)$
+et $\actModifCallInputs(c_2, f_1)$, qui propage \spare{} aux entrées $c$ et $e$ de
+$f_1$.
+
+\bb{\centerline{\uneimage{exple2v3-3}}}\bb
+
+Enfin, le $\actChangeCall(c, {\mathit main}_1, f_1)$ propage le marquage de
+$f_1$ dans ${\mathit main}_1$. On remarque que même si ce changement avait été
+effectué plus tôt, la propagation du marquage aurait été effectué grâce à des
+$\actMissingInputs$.
+
+\bb{\centerline{\uneimage{exple2v3-4}}}\bb
+
+
+\section{Cas 4}
+
+A partir du cas 3, l'utilisateur souhaite ajouter la sélection du calcul de $Y$
+dans $g_1$.\bb
+
+$\actAddUserMark(g_1, (out_Y, m))$ conduit à marquer $Y$ en $m_1$,
+puis, par propagation, $v$ en $m_1$ également~:
+
+\bb{\centerline{\uneimage{exple2v4-1}}}\bb
+
+Des actions $\actMissingInputs$ transformée en $\actModifCallInputs$ propage
+$m_1$ aux entrées $b$ et $d$ de $f_1$, puis aux entrées $J$ et $L$ de ${\mathit
+main}_1$.
+
+\bb{\centerline{\uneimage{exple2v4-2}}}\bb
+
+
+
diff --git a/doc/slicing/interproc.tex b/doc/slicing/interproc.tex
new file mode 100644
index 0000000000000000000000000000000000000000..2d5cb46481f06d5782abc08a711d743910bce9da
--- /dev/null
+++ b/doc/slicing/interproc.tex
@@ -0,0 +1,198 @@
+\newcommand{\bb}{\bigskip}
+
+\newcommand{\spare}{\ensuremath{\mathit{Spare}}}
+\newcommand{\sigc}{\ensuremath{\mathit{sig_c}}}
+\newcommand{\insigc}{\ensuremath{\mathit{inSig_c}}}
+\newcommand{\outsigc}{\ensuremath{\mathit{outSig_c}}}
+\newcommand{\sigf}{\ensuremath{\mathit{sig_f}}}
+\newcommand{\insigf}{\ensuremath{\mathit{inSig_f}}}
+\newcommand{\outsigf}{\ensuremath{\mathit{outSig_f}}}
+\newcommand{\sig}{\ensuremath{\mathit{sig}}}
+\newcommand{\true}{\ensuremath{\mathit{true}}}
+\newcommand{\false}{\ensuremath{\mathit{false}}}
+
+\newcommand{\imply}{\Rightarrow}
+\newcommand{\lt}{<}
+
+\newcommand{\inout}{\ensuremath{\mathit{InOut}}}
+\newcommand{\call}{\ensuremath{\mathit{call}}}
+\newcommand{\length}{\ensuremath{\mathit{length}}}
+\newcommand{\none}{\ensuremath{\mathit{None}}}
+
+
+\newcommand{\topm}{{\top}_m}
+\newcommand{\tops}{{\top}_s}
+\newcommand{\topc}{{\top}_c}
+\newcommand{\botm}{{\bot}_m}
+\newcommand{\bots}{{\bot}_s}
+\newcommand{\botc}{{\bot}_c}
+
+\newcommand{\option}[1]{\motcle{#1}{Options}{opt}{\textbf{#1}}}
+
+\newcommand{\defaction}[1]{\motcle{#1}{Actions}{act}}
+\newcommand{\labact}[2]{\index{Actions!#1}\label{sec-#1-#2}}
+\newcommand{\refact}[2]{\S\ref{sec-#1-#2}}
+%===============================================================================
+
+\chapter{Réduction interprocédurale}\label{sec-interproc}
+
+\section{Objectif}
+
+Le filtrage élémentaire vu précédemment n'est qu'un préalable à la réduction
+d'une application car lorsqu'une fonction a été réduite, il faut également
+traiter ses appels pour rester cohérent, et on peut aussi vouloir réduire les
+fonctions appelées.
+
+\subsection{Spécification du problème}
+
+Pour étendre le marquage intraprocédural
+déjà effectué à un calcul interprocédural,
+une première approche serait
+de propager le marquage à travers les appels de fonctions, mais cela conduit
+soit à un trop grand nombre de fonctions spécialisées si l'on distingue tous les
+appels, soit à trop de perte de précision si l'on en fait l'union.
+Ce problème est exposé plus en détail en \S\ref{sec-compat-sig}.
+L'objectif est donc d'obtenir un compromis acceptable et paramétrable.\\
+
+Dès lors que l'on décide de pouvoir avoir plusieurs spécialisations d'une même
+fonction source dans l'application finale,
+le mécanisme permettant d'obtenir un résultat cohérent devient relativement
+complexe. Par exemple,
+lorsqu'on s'intéresse au calcul de certaines données $d$ dans une fonction $g$,
+on a vu au chapitre précédent comment calculer le marquage des éléments du PDG
+pour pouvoir réduire $g$.
+Si $g$ appelle $h$, et que toutes les sorties de $h$ ne sont pas nécessaires au
+calcul de $d$ dans $g$, on peut aussi vouloir demander la spécialisation de $h$.
+Par ailleurs, si $g$ est appelée,
+il est possible de remplacer un ou plusieurs appels par un appel
+à $g_1$. Ce traitement doit être appliqué récursivement puisque dès que l'on
+modifie le marquage d'une fonction, on peut avoir besoin également de modifier
+les fonctions appelées et appelantes.\\
+
+On décide donc de décomposer un traitement complet en différentes
+actions élémentaires parfaitement définies. Elles pourront ensuite être
+combinées automatiquement en fonction d'options de plus haut niveau.
+
+\subsection{Organisation des résultats}
+
+Le processus complet consiste à appliquer successivement
+un certain nombre de requêtes exprimées par l'utilisateur
+afin de construire une nouvelle application.
+Nous appellerons \indexdef{projet courant}
+l'état de cette nouvelle application à un instant donné.
+Il est composé~:
+\begin{itemize}
+ \item d'un ensemble de résultats (initialement vide)
+ sur les fonctions tels qu'ils ont été
+ présentés en \ref{sec-filtrage-fct}, c'est-à -dire de fonctions
+ spécialisées~;
+ \item et d'une liste d'actions qui sont
+encore à appliquer pour obtenir une application cohérente.
+\end{itemize}
+\bb
+
+Lorsque l'utilisateur exprime des requêtes, elles sont traduites en
+{\bf actions} qui sont rangées dans la liste des tâches en attente.
+Les actions s'appliquent en séquence, c'est-à -dire qu'on ne peut pas appliquer
+une action si la précédente n'est pas terminée.
+L'application d'une action peut éventuellement générer de nouvelles actions.
+\bb
+
+Une action peut dans certains cas être supprimée ou modifiée~:
+ce point est abordé en \S\ref{sec-gestion-actions}.
+\bb
+
+A la fin de l'analyse, il n'y a plus d'action à appliquer,
+et l'application résultante peut être générée.
+
+\subsection{Appel de fonction}
+
+Lors du marquage intraprocédural, on obtient les marques strictement nécessaires
+au calcul demandé. On peut en particulier en extraire les signatures des appels
+de fonction. Pour chacun d'entre eux, dès lors qu'il y a au moins un élément
+visible, il va falloir décider quelle est la fonction appelée.
+On a vu par exemple qu'on peut choisir de ne pas spécialiser les appels de
+fonction~: les entrées invisibles des appels devront alors être marqué comme
+superflus.
+
+\subsection{Propagation aux fonctions appelées}\label{sec-callee}
+
+Pour se laisser la possibilité de faire évoluer l'outil,
+ on décide d'offrir plusieurs possibilités~:
+\begin{itemize}
+\item une spécialisation par appel~:
+pour chaque appel, on détermine les sorties
+utiles, et on génère la fonction appelée correspondante (si elle n'existe pas
+déjà ),
+\item pas de spécialisation de fonction~: dès qu'on a besoin d'une des sorties
+d'une fonction, on laisse l'appel, et on a donc besoin de sélectionner tous les
+arguments d'appel,
+\item une seule spécialisation par fonction~: regroupement de toutes les
+spécialisations nécessaires à l'application en une seule fonction,
+\item regroupement de fonctions spécialisées {\it a posteriori},
+Ã la demande de l'utilisateur.
+\end{itemize}
+
+\subsection{Propagation aux fonctions appelantes}\label{sec-caller}
+
+ Lorsqu'une fonction spécialisée a été calculée, on peut vouloir l'appeler
+ à la place de la fonction initiale, et ainsi propager la réduction.
+ Il faut pour cela pouvoir créer une requête qui désigne le point d'appel,
+ et la fonction spécialisée à utiliser. Cette requête revient à s'intéresser au
+ calcul des entrées visibles de la spécialisation au dessus du point d'appel.
+
+ L'application d'une telle requête peut à son tour générer une demande de
+ spécialisation, éventuellement de la même fonction comme dans l'exemple
+ ci-dessous.
+
+\begin{exemple}
+La figure suivante montre un exemple de différentes étapes de la
+transformation des appels à $g$ dans $f$ par des appels à la fonction filtrée
+$g_1$, et comment on peut envisager de propager l'information.
+
+\begin{center}
+\uneimage{propagation}
+\end{center}
+
+\begin{enumerate}
+ \item calcul de la fonction $g_1$ : seule la seconde entrée est visible, les
+ sorties ne sont pas visibles;
+ \item remplacement du second appel à $g$ dans $f$ par un appel à $g_1$,
+ et sélection des éléments qui permettent de calculer l'entrée visible.
+ On voit que ce calcul nécessite de calculer la seconde sortie du premier
+ appel à $g_1$. Il faut donc calculer une seconde fonction $g_2$.
+ \item calcul de la fonction $g_2$ : elle doit avoir les mêmes éléments que
+ $g_1$ et calculer en plus sa seconde sortie. On voit ce cela nécessite la
+ visibilité de la première entrée.
+ \item sélection de ce qui permet de calculer la première entrée de $g_2$ dans
+ $f$.
+\end{enumerate}
+\end{exemple}
+
+\subsection{Sélection des appels d'une fonction}
+
+ En plus des critères de \slicing déjà vus qui consiste à sélectionner une
+ donnée à un point de programme, l'aspect interprocédural conduit Ã
+ définir un nouveau critère qui permet
+ de ne garder que ce qui permet d'appeler une fonction donnée,
+ et de calculer les contextes d'appels.
+ La fonction peut être~:
+ \begin{itemize}
+ \item une fonction externe dont on n'a pas le code,
+ \item une fonction présente dans le code source,
+ \item une fonction issue d'un précédent filtrage,
+ \end{itemize}
+ et on peut choisir de sélectionner~:
+ \begin{itemize}
+ \item uniquement ce qui permet d'atteindre les points de programme des
+ appels à cette fonction,
+ \item ou bien également ce qui permet de calculer les entrées.
+ \end{itemize}
+
+ Ce filtrage peut par exemple être utilisé pour réduire une application
+ afin de permettre une analyse des fuites mémoire.
+ Il suffit pour cela de sélectionner les fonctions d'allocation (\verbtt{alloc},
+ \verbtt{malloc}, etc.) et la fonction de libération (\verbtt{free}).\\
+
+\input{interproc2.tex}
+
diff --git a/doc/slicing/interproc2.tex b/doc/slicing/interproc2.tex
new file mode 100644
index 0000000000000000000000000000000000000000..c7528466dabfc224453400224c3591447e8bd28a
--- /dev/null
+++ b/doc/slicing/interproc2.tex
@@ -0,0 +1,995 @@
+\section{Principe et notations}
+
+On rappelle ici les aspects du calcul intraprocédural, et diverses notations,
+qui vont être utilisées par la suite.
+On s'appuie en grande partie sur la représentation des entrées/sortie
+et des appels de fonction dans le PDG présenté dans \cite{ppcPdg}.
+
+\subsection{Marques élémentaires}
+
+On considère qu'on a un ensemble de marques élémentaires,
+non détaillées ici, muni~:
+\begin{itemize}
+ \item d'un ordre partiel ($\leq$),
+ \item d'une opération d'union ($+$),
+ \item d'un plus petit élément ($\botm$) utilisé pour marquer les éléments
+ invisibles,
+ \item et d'un plus grand élément ($\topm$) correspondant au marquage des
+ élément de la fonction source.
+\end{itemize}
+
+On considère de plus un élément appelé \spare{} tel que~:
+\begin{itemize}
+ \item $\forall m. m \neq \botm \imply m = \spare \lor \spare \leq m$
+\end{itemize}
+On a donc~:
+\begin{equation*}
+\forall m. m \neq \botm \imply m + \spare = m
+\end{equation*}
+Cette marque est donc la plus petite qui rende un élément visible.
+Elle est utilisée pour marquer les élément dit {\it superflus}, c'est-à -dire
+ceux qui ne seraient pas nécessaire si la réduction était plus précise.
+
+\subsection{Marquage}
+
+On a vu au chapitre \ref{sec-filtrage-fct} que l'on dispose d'une procédure
+permettant de marquer une instruction et de la propager
+selon les dépendances (PDG).
+
+Au cours de ce calcul,
+les relations de dépendances entre les entrées et les sorties des fonctions
+appelées sont données par la spécification\footnote{c'est peut-être un problème
+si on fait de la coupure de branche, car les dépendances peuvent être réduites
+par une telle spécialisation.}.\bb
+
+Dans le résultat obtenu, lorsqu'un élément de fonction $e1$ est utilisé par un
+élément de fonction $e2$, la marque $m1$ associée à $e1$
+est supérieure ou
+égale à la marque $m2$ associée à $e2$ car $m1$ est l'union des marques
+de tous les éléments qui dépendent de $e1$.
+
+\subsection{Fonctions}
+
+Chaque fonction source peut être spécialisée une ou plusieurs fois.
+Au niveau {\it intraprocédural},
+cela signifie qu'on lui attribue un certain marquage.\bb
+
+Dans la suite, on note~:
+\begin{itemize}
+ \item $f, g, h, ...$ une fonction quelconque (source ou spécialisée),
+ \item une fonction source est munie d'un indice 0~: $f_0, g_0, h_0, ...$
+ \item les fonctions spécialisées ont un autre indice~: $f_i, g_j, h_k, ...$
+ (sauf mention contraire, quand on précise l'indice,
+ on suppose donc qu'il est différent de 0).
+\end{itemize}
+
+\subsection{Entrées/sorties}
+
+Le graphe de dépendance contient des éléments particuliers qui représentent
+les entrées et les sorties de la fonction.
+On note $\inout(f)$ l'ensemble de ces éléments pour la fonction $f$.\bb
+
+On ne précise pas de quelle fonction $f$ il s'agit, car on considère le même
+ensemble d'entrées/sorties pour toutes les spécialisations~:
+\begin{equation*}
+ \forall i. \inout(f_0) = \inout(f_i)
+\end{equation*}
+
+\subsection{Signature}
+
+On appelle {\bf signature}, et on note $\sig$, une fonction
+qui associe une marque aux éléments d'un ensemble d'entrées/sorties.
+
+On définit $\tops$ qui représente une signature dont tous les éléments
+ont une marque $\topm$~:
+\begin{equation*}
+\sig = \tops \equiv \forall e \in dom(\sig). \sig(e) = \topm
+\end{equation*}
+et de même, $\bots$ qui représente une signature dont tous les éléments
+ont une marque $\botm$~:
+\begin{equation*}
+\sig = \bots \equiv \forall e \in dom(\sig). \sig(e) = \botm
+\end{equation*}
+
+% A TERMINER~: il faut sans doute déjà introduire la notion de précondition dans
+% la signature, car si deux spécialisations ont la même marque pour une même
+% sortie, mais qu'elles ne se placent pas dans les mêmes conditions, il faut tenir
+% compte de la relation d'ordre sur les préconditions (implication).
+%
+% Exemple~: si on spécialise une fonction avec une entrée $x=2$,
+% elle est plus précise qu'une spécialisation avec $x>0$,
+% par contre, elle est incomparable avec la spécialisation dans le cas $x<0$.\bb
+
+
+On définit $\sigf(f)$ la {\bf signature d'une fonction} $f$ telle que~:
+\begin{itemize}
+ \item $dom(\sigf(f)) = \inout(f)$
+ \item $\sigf(f_0) = \tops$
+ \item $\sigf(f_i)(e)$ est la marque attribuée à $e$ dans $f_i$.
+\end{itemize}
+\bb
+
+On notera parfois $\insigf(f)$ et $\outsigf(f)$ les fonctions dont le domaine
+est réduit aux entrées ou aux sorties.
+
+% La relation d'ordre sur les signatures de fonction traduit la précision
+% des spécialisations.
+% Une spécialisation est plus petite qu'une autre si elle calcule moins
+% de chose, ou si elle calcule la même chose, mais qu'elle
+% nécessite moins d'entrée (c'est possible si le choix des fonctions appelées
+% n'est pas le même).
+
+\subsection{Appel de fonction}
+
+Comme nous parlons ici de la partie interprocédurale du traitement, on
+s'intéresse principalement aux appels de fonction. On considère que l'on sait
+identifier de manière unique un appel de fonction $c$, (par exemple par
+l'identification de la fonction appelante et un élément du PDG, ou un numéro
+d'ordre). Dans la suite, pour préciser le nom de la fonction appelée,
+on notera $c_g$ un appel à une fonction $g$.\bb
+
+On note $\call(f)$ l'ensemble des appels de fonction de $f$.
+On remarque que l'on ne précise pas la spécialisation, car~:
+\begin{equation*}
+\forall i. \call(f_i) = \call(f_0)
+\end{equation*}
+\bb
+
+Pour chaque appel de fonction $c_g$ de $f_i$,
+le graphe de dépendance contient des éléments qui
+représentent les entrées/sorties de la fonction appelée.
+
+On définit la {\bf signature d'un appel} de fonction $c$
+dans la fonction $f_i$, et on note $\sigc(c, f_i)$,
+la fonction qui donne les marques de ces éléments dans $f_i$.
+
+\section{Calcul interprocédural}
+
+\subsection{Gestion des fonctions}
+
+Au niveau {\it intraprocédural}, une fonction spécialisée est caractérisée par
+un certain marquage de ses éléments.
+En interprocédural, on s'intéresse à la propagation des marques aux appels
+de fonction. On se propose donc d'ajouter aux fonctions spécialisées
+une fonction $\Call$, décrite en \S\ref{sec-Call}, qui associe, à chaque appel
+de fonction, l'identification de la fonction à appeler. L'objectif est de
+remplacer certains appels par des appels à des fonctions spécialisées.\bb
+
+La réduction d'une application consiste à construire un {\bf projet} qui
+contient une liste de fonction, initialisée à la liste des fonctions source, et
+complétée au cours de l'étude par les fonctions spécialisées calculées.
+
+L'objectif est d'obtenir un projet cohérent, tel que défini en
+\S\ref{sec-coherence}.
+
+\subsection{Appels de fonction}\label{sec-Call}
+
+On appelle $\Call(f_i)$ la fonction qui fait correspondre
+chaque appel de $f_i$ à une fonction appelée.
+$\Call(f_i)(c)$ donne donc la fonction appelée par $f_i$ pour l'appel $c$.\bb
+
+On note $\Call(f_i)(c) = \botc$ quand l'appel est invisible.
+
+Par ailleurs, $\Call(f_i)(c) = \topc$ signifie que l'appel
+n'est pas encore attribué, c'est-à -dire que l'on n'a pas encore choisi la
+fonction à appeler.\bb
+
+Si la fonction appelée est déterminée par l'accès à un pointeur de fonction,
+il n'est pris en considération dans $\Call$ que si on connaît
+statiquement la fonction appelée à partir de l'analyse de valeur.
+Dans les autres cas, on laissera
+l'appel tel qu'il est dans la fonction source.\bb
+
+
+Les fonctions source appellent forcement des fonctions source~:
+\begin{equation*}
+\forall c \in \call(f), \exists g. \Call(f_0)(c) = g_0
+\end{equation*}
+
+Quand l'appel est attribué, il correspond forcement à une spécialisation
+de la fonction initialement appelée~:
+\begin{equation*}
+\forall c \in \call(f), \Call(f_0)(c) = g_0
+\imply \forall f_i. (\Call(f_i)(c) = \botc \lor \Call(f_i)(c) = \topc
+\lor \exists j. \Call(f_i)(c) = g_j)
+\end{equation*}
+
+Par ailleurs, si $\Call(f_i)(c) = g_j$
+on veut que la signature de la fonction appelée
+$\sigf(g_j)$ soit {\it compatible}
+Ã la signature de l'appel $\sigc(c, f_i)$.
+Voyons maintenant ce que cela veut dire...
+
+\subsection{Problème de compatibilité des signatures}\label{sec-compat-sig}
+
+La première idée qui vient lorsque l'on souhaite propager le marquage
+aux fonctions appelées est d'appliquer les mêmes règles de propagation dans les
+dépendances que pour le calcul
+intraprocédural. Mais lorsque l'on souhaite utiliser une même fonction
+spécialisée dans différents contextes, cela conduit à avoir une trop grande
+perte de précision. On veut par exemple pouvoir marquer
+comme \spare{} les entrées qui ne sont pas réellement utilisées pour un certain
+appel, même si elles portent d'autres marques par ailleurs.
+\bb
+
+Par exemple, dans le cas suivant~:
+
+\noindent\begin{tabular}{p{5cm}p{4cm}p{4cm}}
+\begin{verbatim}
+int X, Y;
+
+void g (int x, int y) {
+ X = x; Y = y;
+ }
+\end{verbatim}
+&
+\begin{verbatim}
+
+int f_a (int x_a,
+ int y_a) {
+ g (x_a, y_a);
+ return X;
+ }
+\end{verbatim}
+&
+\begin{verbatim}
+
+int f_b (int x_b,
+ int y_b) {
+ g (x_b, y_b);
+ return Y;
+ }
+\end{verbatim}
+\end{tabular}
+
+si l'utilisateur demande le marquage
+des sorties 0 de \verb$f_a$ et \verb$f_b$, et la construction d'une seule
+spécialisation pour \verb$g$, on aimerait que \verb$x_a$ et \verb$y_b$ soient
+marquées \spare{}
+
+
+\bb
+Pour obtenir un tel comportement, on décide d'étendre le marquage
+comme suit.
+
+\subsection{Couple de marques}
+
+Pour garder un maximum de précision, il faut distinguer les sélections
+réellement effectuées par l'utilisateur des marques introduites par une
+approximation.
+Pour cela, on marque chaque élément d'une spécialisation non plus par une seule
+marque, mais par un couple $<m_1, m_2>$ où~:
+\begin{itemize}
+ \item la marque $m_1$ correspond à la propagation d'une sélection par
+ l'utilisateur dans la fonction d'origine et dans ses appelants,
+ {\sc MAIS}
+ on ne la propage pas directement dans les fonctions appelées
+ car cela conduit à avoir une trop grande perte de précision.
+ Il faut noter que $m_1$ ne peut en principe pas être \spare,
+ sauf si l'utilisateur le demande explicitement.
+ \item la marque $m_2$ correspond à la propagation d'une marque $m_1$
+ d'un appelant. Donc, lorsque la sortie d'un appel a une marque $m_1$, la
+ sortie correspondante de la fonction appelée est marquée $m_2$.
+ Par ailleurs, si une fonction a une entrée marquée
+ $m = <m_1, m_2>$ avec $m_2 \neq \botm$, ses appelants doivent propager
+ $m' = <m_1, \spare>$ sur l'entrée correspondante.
+ Attention, comme on le verra plus loin,
+ cela ne veut pas dire que les entrées des appelants ont la
+ marque $m'$, car il faut combiner cette marque avec les marques de
+ l'appelante.
+\end{itemize}
+\bb
+
+Du point de vue de l'utilisateur, la marque associée à un élément est l'union de
+$m_1$ et de $m_2$.
+\bb
+
+Dans l'exemple précédent, les entrées $x$ et $y$ de $g$
+seront marquées en $m_2$, et cela conduira bien à marquer $\spare{}$ les entrées
+inutiles dans $f\_a$ et $f\_b$.
+
+\subsection{Cohérence du projet} \label{sec-coherence}
+
+Avant de voir comment calculer le résultat, voyons les propriétés que doit avoir
+un marquage final pour être cohérent.
+Les éléments qui nous intéressent sont les signatures des fonctions et des
+appels.
+
+Nous ne parlons ci-dessous que des marques propagées,
+sachant qu'en plus, chacune peut contenir aussi une marque mise manuellement par
+l'utilisateur.
+
+\begin{itemize}
+ \item les marques des sorties d'un appel $(c_g, f_i)$ ne dépendent que du
+ contexte d'appel, c'est-à -dire des marques de leurs dépendances dans $f_i$.
+ Néanmoins, il semble qu'une marque $m_2$ ne puisse venir que de marques
+ $m_2$ sur les sorties de $f_i$, sauf la marque \spare{} qui peut venir
+ d'entrées d'appels de fonction.
+ \item les marques des sorties d'une fonction spécialisée sont déterminées
+ par les marques des sorties des appels à cette fonction.
+ On ne peut avoir $m_1 \neq \botm$ que si l'utilisateur a placé
+ explicitement une marques sur la sortie. La marque $m_2$ est l'union
+ des marques $m_1$ et $m_2$ des sorties des appels.
+ \item les marques des entrées d'une fonction sont uniquement déterminées par
+ la propagation des marques des autres éléments de la fonction.
+ Une marque $m_1$ provient nécessairement d'une sélection utilisateur dans la
+ fonction considérée ou une de ses fonctions appelées.
+ \item les marques des entrées d'un appel $(c_g, f_i)$ sont une combinaison des
+ marques des entrées de $g$ et des sorties de $(c_g, f_i)$
+ Si l'on remplace la fonction appelée, il faut recalculer ces
+ marques d'entrées.
+\end{itemize}
+\bb
+
+En résumé,
+considérons une entrée $e$ et une sortie $s$ d'une fonction spécialisée $g_i$,
+on note $m(e) = \sigf(g_i)(e)$, $m(s) = \sigf(g_i)(s)$.
+
+\labcenterepsfig{call}{Propagation des marques dans les appels de
+fonction}{fig-mark-call}
+
+Soit $c$ un appel quelconque à cette fonction,
+on note $m(ce) = \sigc(c)(e)$ et $m(cs) = \sigc(c)(s)$.
+Pour avoir un projet cohérent, on doit avoir les propriétés suivantes~:
+
+
+\begin{itemize}
+ \item $m_2(s) \geq m_1(cs) + m_2(cs)$
+ \item $m_1(e) \leq m_1(ce)$
+ \item $m_2(e) \neq \botm \imply m_1(ce) \geq \spare$
+\end{itemize}
+
+Par ailleurs, si la sortie $s$ dépend de l'entrée $e$~:
+\begin{itemize}
+ \item $m_1(cs) \leq m_2(s) \leq m_2(e) \leq m_2(ce)$
+ \item $m_1(cs) \leq m_1(ce)$
+ \item $m_1(s) \leq m_1(e) \leq m_1(ce)$
+\end{itemize}
+\bb
+
+On a vu que le calcul du résultat final se décompose en actions élémentaires.
+Entre deux actions, on impose que le projet soit {\bf partiellement cohérent},
+c'est-Ã -dire que pour tous $\Call(f_i)(c)$~:
+\begin{itemize}
+ \item $\Call(f_i)(c) = \botc \Longleftrightarrow \sigc(c, f_i) = \bots$
+ \item $\Call(f_i)(c) = \topc$ et il doit y avoir une action en attente pour
+ attribuer l'appel,
+ \item $\Call(f_i)(c) = g_j$ et~:
+ \begin{itemize}
+ \item $g_j$ doit exister et avoir une signature compatible à l'appel,
+ ou une action de modification en attente
+ (car dans ce cas, on ne sait pas forcement évaluer la compatibilité des
+ signatures).
+ \item ou $g_j$ n'existe pas encore, mais fait l'objet d'une action de
+ construction en attente.
+ \end{itemize}
+\end{itemize}
+\bb
+
+Lorsque la liste des actions est vide, le projet doit être {\bf cohérent}
+c'est-à -dire que tous les appels de fonction doivent être affectés
+Ã une fonction ayant une signature compatible avec celle de l'appel.
+
+
+\section{Actions pour le calcul interprocédural}\label{sec-def-actions}
+
+La difficulté du traitement est d'enchaîner correctement les actions pour
+obtenir une application cohérente. De plus, pour avoir une boite à outils
+suffisamment flexible, les actions doivent correspondre à des traitements
+suffisamment élémentaires, et parfaitement spécifiés (surtout leur comportement
+vis à vis des différentes options).
+
+On décide donc que toute action doit être décomposée et traduite
+en une séquence d'{\bf actions élémentaires} définies ci-dessous.
+Elles doivent être simples, et
+le moins paramétrables possible, la flexibilité venant plutôt de la
+traduction d'une action de haut niveau en actions élémentaires.
+Ces dernières ne sont donc pas toutes accessibles par l'utilisateur,
+mais peuvent être vues comme des étapes de calcul qui seront combinées
+par la suite en fonction des besoins.
+\bb
+
+L'application d'une action élémentaire~:
+\begin{itemize}
+ \item peut éventuellement générer de nouvelles actions,
+ \item mais ne peut créer ou modifier qu'une seule fonction (ou aucune).
+\end{itemize}
+\bb
+
+Cette partie présente donc tout d'abord les actions élémentaires,
+et le détail de l'application de chacune d'entre elles.
+Puis, on verra que la génération de ces actions dépend du mode de fonctionnement
+choisi. Les modes proposés sont exposés en \S\ref{sec-modes}.
+
+Les actions sont résumées sous forme de fiches signalétiques, en annexe
+\ref{app-actions}.
+
+\defaction{NewSlice}
+\subsection{Création une spécialisation~: \actNewSlice}\labact{NewSlice}{1}
+
+On appelle $f_i = \actNewSlice(f_0)$ l'action qui permet de construire
+une spécialisation $f_i$ de $f_0$ . Initialement, toutes les marques sont
+mises à $\botm$ et la fonction $\Call(f_i)(c) = \topc$.
+Les modifications peuvent ensuite être faite à l'aide des actions présentées
+ci-dessous. Cela permet d'avoir un traitement cohérent.
+
+\subsection{Modification d'une spécialisation}
+
+Les actions suivantes permettent de modifier la marquage une spécialisation
+Elles ne créent pas de nouvelles fonctions.
+\bb
+
+{\bf Attention}~: pour l'instant, les actions {\bf ajoutent} des marques.
+Veut-on pouvoir réduire une spécialisation~?
+
+\defaction{ExamineCalls}
+Dans tous les cas, lorsque le marquage d'une fonction est modifié,
+il faut ensuite gérer ses appels de fonction.
+Toutes les actions de modification ci-dessous génèrent donc une requête
+\actExamineCalls{} qui permet d'effectuer cette tâche.
+Son application est présentée en \refact{ExamineCalls}{1}.
+
+\defaction{AddUserMark}
+\subsubsection{Ajout d'une marque utilisateur~: \actAddUserMark}\labact{AddUserMark}{1}
+
+L'action $\actAddUserMark(f_i, (e, m)$ permet d'ajouter et de propager
+une marque sur
+n'importe quel élément de $f_i$. Il s'agit d'une marque utilisateur,
+elle est donc ajoutée en $m_1$.
+
+\defaction{AddOutputMarks}
+\subsubsection{Propagation d'une marque de sortie ~: \actAddOutputMarks}\labact{AddOutputMarks}{1}
+
+L'action $\actAddOutputMarks(f_i, \outsigc)$
+est générée lorsque $f_i$ est appelée, mais qu'elle ne calcule pas assez de
+choses. Pour chaque sortie $s$, si $\outsigc(s) = <m_1, m_2>$,
+il faut ajouter $<\botm, m_1+m_2>$ Ã $\outsigf(f_i)(s)$ et propager
+la nouvelle marque dans $f_i$.
+
+\defaction{ModifCallInputs}
+\subsubsection{Marquage des entrées d'un appel~: \actModifCallInputs}\labact{ModifCallInputs}{1}
+
+L'action $\actModifCallInputs(c_g, f_i)$ est générée lorsque
+les marques d'entrée d'un appel $g_j = \Call(f_i)(c_g)$ dans $f_i$
+sont insuffisantes pour la fonction appelée. Pour chaque entrée $e$ de l'appel,
+on commence par recalculer sa marque en fonction des marques de ses dépendances.
+Cela permet d'obtenir un résultat correct même si on avait besoin de plus
+d'entrée avant d'appeler $g_j$. Puis, si
+$\insigf(g_j)(e) = <m_1, m_2>$, il faut ajouter $<m_1, \spare>$ Ã
+$\insigc(c_g, f_i)$ si $m_2 \neq \botm$ et $<m_1, \botm>$ sinon,
+et propager la nouvelle marque ainsi obtenue dans $f_i$.
+
+
+\subsubsection{Gestion des appels~: $\actExamineCalls$}\labact{ExamineCalls}{1}
+
+L'action $\actExamineCalls(f_i)$ est automatiquement appliquée
+après toute modification du marquage de la fonction $f_i$
+car il faut examiner $\Call(f_i)$ afin d'en vérifier la cohérence,
+c'est-à -dire pour voir si les fonctions appelées conviennent toujours.
+\bb
+
+
+\defaction{ChooseCall}
+Pour chaque appel, on regarde donc~:
+\begin{itemize}
+ \item si $\outsigc(c, f_i) = \bots$ (on n'utilise pas les sorties de l'appel
+ de fonction), alors $\Call(f_i)(c) = \botc$,
+ \item sinon (certaines sorties sont marquées)~:
+ \begin{itemize}
+ \item si $\Call(f_i)(c) = \botc$~:
+ rien n'était appelé précédemment, il faire faire comme si
+ $\Call(f_i)(c) = \topc$ (voir ci-dessous),
+ \item si $\Call(f_i)(c) = \topc$~:
+ aucune fonction n'a encore été attribuée à cet appel.
+ Une action \actChooseCall est chargée d'affecter une fonction à cet
+ appel (cf. \refact{ChooseCall}{1}).
+ \item si $\Call(f_i)(c) = g_j$~: il faut comparer $\outsigc(c, f_i)$ Ã
+ $outsigf(g_j)$ comme nous allons le voir.
+ \end{itemize}
+\end{itemize}
+
+Pour que la fonction appelée $g_j$ convienne, il faut qu'elle calcule au moins
+toutes les sorties nécessaires à cet appel. C'est-à -dire que si une sortie de
+l'appel est marquée $<m_1, m_2>$, et que la sortie correspondante de $g_j$ est
+marquée $<m_1', m_2'>$, on doit avoir~:
+\begin{equation*}
+m_2' \geq m_1 + m_2
+\end{equation*}
+
+\defaction{MissingOutputs}
+Si ce n'est pas le cas, une action \actMissingOutputs{} est générée
+(cf. \refact{MissingOutputs}{1}).
+On pourrait générer directement $\actAddOutputMarks(g_j, \outsigc(c, f_i)$ mais
+ça ne permettrait pas de choisir une autre fonction $g$ plutôt que d'étendre
+$g_j$.
+\bb
+
+\defaction{MissingInputs}
+Par ailleurs, $\actExamineCalls$ s'occupe également de la propagation des
+marques aux appelants, c'est-à -dire que si $f_i$ est appelée par $h_k$ et que
+les marques de ses entrées ont été modifiées, il faut les propager aux entrées
+des appels. Pour cela, on génère une action \actMissingInputs
+(cf. \refact{MissingInputs}{1}). On
+pourrait directement générer $\actModifCallInputs(c_f, h_k)$, mais cela ne
+permettrait pas de modifier l'appel de fonction pour choisir d'appeler une autre
+spécialisation de $f$ dans $h_k$.
+
+Les étapes de l'attribution, puis de la modification des appels de fonction
+peuvent sembler complexes au premier abord,
+d'autant plus que leur enchaînement dépend d'un mode
+de fonctionnement qui sera explicité en \S\ref{sec-modes} et éventuellement des
+interventions ponctuelles de l'utilisateur.
+La figure \ref{fig-modifcall} tente de résumer ce processus.
+
+\clearpage
+\begin{center}
+ \rotatebox{90}{%
+ \resizebox{200mm}{!}{\includegraphics{choose_call}}}
+
+Fig.~\thefigure~:\label{fig-modifcall}
+Gestion d'un appel $c$ Ã une fonction $g$
+
+suite à la modification des marques de la signature de $c$ dans la fonction appelante
+
+ou à celle des entrées de $g$.
+\stepcounter{figure}
+\end{center}
+\clearpage
+
+\subsection{Affecter ou modifier un appel de fonction}
+
+On a vu que lors de la création ou la modification du marquage d'une fonction
+$f_i$, des actions $\actChooseCall(c, f_i)$,
+$\actMissingOutputs(c, f_i)$ ou
+$\actMissingInputs(c, f_i)$ pouvaient être générées lorsqu'un appel $c$
+doit être attribué ou modifié.
+Dans tous les cas, on se pose la question de la fonction à appeler car soit on
+ne l'a pas encore choisie, soit elle ne convient plus.
+\bb
+
+\subsubsection{Attribution d'un appel : $\actChooseCall$}\labact{ChooseCall}{1}
+
+Une action $\actChooseCall(c, f_i)$ peut-être générée (selon le mode choisi)
+lorsque
+$\Call(f_i)(c)$ doit être modifié car le marquage de $f_i$ a changé~:
+il s'agit de trouver une fonction $g_k$ pour remplacer l'ancienne valeur de
+$\Call(f_i)(c)$ qui pouvait être $\topc$, $\botc$ ou encore $g_j$,
+mais cette dernière ne convient plus.
+\bb
+
+Lors de l'application de cette action, outre le mode de fonctionnement,
+le critère principal de choix est le marquage des sorties dans l'appel
+($\outsigc(c, f_i)$) qui est confronté
+au marquage des spécialisations de $g$ déjà calculées,
+en appliquant éventuellement un traitement particulier à $g_j$,
+la fonction initialement appelée.
+
+En fonction du mode~:
+\begin{itemize}
+ \item soit on trouve une $g_k$ qui convient,
+ \item soit on trouve une $g_k$ que l'on souhaite utiliser,
+ mais qui ne calcule pas assez de choses~:
+ il faut donc créer $\actAddOutputMarks (g_k, \sigc(c, f_i))$,
+ \item soit on ne trouve pas de spécialisation existante et on lance alors la
+ création d'une nouvelle spécialisation soit en partant de $g_0$, soit en
+ partant de $g_j$ (Ã voir...)
+\end{itemize}
+\bb
+
+\defaction{ChangeCall}
+Dans tous les cas, après avoir choisi $g_k$,
+on applique une action \actChangeCall (cf. \refact{ChangeCall}{1}).
+
+\subsubsection{Action $\actMissingInputs$}\labact{MissingInputs}{1}
+
+On rappelle qu'une action $\actMissingInputs(c, f_i)$ est générée lorsque la
+fonction $g_j$ attribuée à $\Call(f_i)(c) = g_j$ a été modifiée, et qu'elle
+nécessite le marquage d'entrées qui ne le sont pas $\sigc(c,f_i)$.
+\bb
+
+En fonction du mode de fonctionnement, une telle action peut conduire à ~:
+\begin{itemize}
+ \item la modification du marquage de $f_i$,
+ c'est-Ã -dire l'application de $\actModifCallInputs(c, f_i)$,
+ \item le choix d'une autre fonction, c'est-Ã -dire l'application de
+ $\actChooseCall(c, f_i)$ (dont le résultat dépend du mode courant),
+ \item une transformation manuelle par l'utilisateur de cette action par
+ un $\actChangeCall(c, f_i, g_k)$ où $g_k$ doit nécessairement calculer
+ suffisamment de sorties.
+\end{itemize}
+
+\subsubsection{Action $\actMissingOutputs$}\labact{MissingOutputs}{1}
+
+L'action $\actMissingOutputs(c, f_i)$ est générée lorsque le marquage de $f_i$
+a été modifié et que la
+fonction $g_j$ attribuée à $\Call(f_i)(c) = g_j$ ne calcule pas suffisamment
+de sorties pour le nouveau marquage.
+\bb
+
+En fonction du mode de fonctionnement, une telle action peut conduire à ~:
+\begin{itemize}
+ \item la modification du marquage de $g_j$,
+ c'est-Ã -dire l'application de $\actAddOutputMarks(g_j, \sigc(c, f_i))$,
+ \item le choix d'une autre fonction, c'est-Ã -dire l'application de
+ $\actChooseCall(c, f_i)$ (dont le résultat dépend du mode courant),
+ \item une transformation manuelle par l'utilisateur de cette action par
+ un $\actChangeCall(c, f_i, g_k)$ où $g_k$ doit nécessairement calculer
+ suffisamment de sorties.
+\end{itemize}
+
+\subsubsection{Changement d'un appel : $\actChangeCall$}\labact{ChangeCall}{1}
+
+L'action $\actChangeCall(c, f_i, g_j)$ permet de transformer $f_i$
+pour avoir $\Call(f_i)(c) = g_j$.
+Elle ne peut être appliqué que si
+$g_j$ calcule bien toutes les sorties nécessaire à l'appel $c$ dans $f_i$.
+Il faut donc appliquer $\actAddOutputMarks$ Ã $g_j$ avant d'appliquer
+$\actChangeCall$ s'il en manque.
+\bb
+
+L'application de $\actChangeCall(c, f_i, g_j)$ consiste à modifier
+$\Call(f_i)(c)$, mais aussi à appliquer $\actModifCallInputs(c, f_i)$ dans le
+cas où la signature de $g_j$ nécessite des entrées qui ne sont pas visibles dans
+$\sigc(c, f_i)$.
+
+\subsection{Modes de fonctionnement}\label{sec-modes}
+
+La génération de ces actions, ainsi que l'effet de leur application sur le
+projet, dépend du choix d'un mode de fonctionnement
+qui décide de la précision des spécialisations.
+Ce mode peut offrir de nombreuses possibilités,
+mais on se limite dans un premier temps à quatre comportements~:
+\begin{enumerate}
+ \item pas de spécialisation des appels de fonction (\option{DontSliceCalls})
+ (cf. \S\ref{sec-DontSliceCalls})~;
+ \item pas de spécialisation, mais propagation du marquage aux fonctions
+ appelées (\option{PropagateMarksOnly})(cf. \S\ref{sec-PropagateMarksOnly})~;
+ \item le moins de spécialisations possibles
+ (\option{MinimizeNbSlice}) (cf. \S\ref{sec-MinimizeNbSlice})~:
+ l'outil ne crée pas plus d'une spécialisation par fonction~;
+ \item spécialisations les plus précises possible
+ (\option{PreciseSlices}) (cf. \S\ref{sec-PreciseSlices})~:
+ on regroupe néanmoins les fonctions ayant la même visibilité,
+ même si le marquage n'est pas le même.
+\end{enumerate}
+
+Pour plus de flexibilité,
+du point de vue de la boîte à outil décrite ici, on suppose que le mode peut
+être changé à tout moment.
+
+\subsubsection{Réduction avec {\it DontSliceCalls}}\label{sec-DontSliceCalls}
+
+Il s'agit du choix qui permet d'utiliser le marquage intraprocédural sans
+propagation aux fonctions appelées.
+Il peut être utilisé si l'on s'intéresse aux liens de dépendance
+dans une fonction, sans s'intéresser au reste de l'application.
+Tous les appels visibles sont donc attribués aux fonctions source~:
+$$\forall c. \exists o. \outsigc(c, f_i)(o) \neq \botm
+\imply \Call(f_i)(c) = \Call(f_0)(c)$$
+
+Dans ce cas, il n'est pas utile de générer d'action $\actChooseCall$,
+et les $\actMissingInputs$ (marquage à \spare{} des entrées non utilisées)
+sont directement appliquées.
+Par ailleurs, il n'y a pas non plus d'actions
+$\actMissingOutputs$ puisque les fonctions source calculent toutes les sorties.
+\bb
+
+Si un autre mode a été utilisé, il est possible néanmoins d'être amené Ã
+appliquer les actions suivantes~:
+
+\begin{itemize}
+ \item $\actChooseCall(c, f_i)$ est traduite en $\actChangeCall(c, f_i, g_0)$,
+ \item $\actMissingInputs(c, f_i)$ en $\actModifCallInputs(c, f_i)$
+ \item $\actMissingOutputs(c, f_i)$ en $\actAddOutputMarks$ ?
+ ou $\actChangeCall(c, f_i, g_0)$ ?
+\end{itemize}
+
+\subsubsection{Réduction avec {\it PropagateMarksOnly}}\label{sec-PropagateMarksOnly}
+
+Ce mode est à utiliser si l'on veut voir la propagation des dépendances
+dans l'ensemble de l'application sans calculer de spécialisations.
+Il est donc très semblable au mode précédent sauf que l'on calcule un marquage
+également pour les fonctions appelées. Néanmoins, il ne s'agit pas d'une
+réduction à proprement parlé puisque tout reste visible.
+
+\subsubsection{Réduction avec {\it MinimizeNbSlice}}\label{sec-MinimizeNbSlice}
+
+Lorsque l'on applique une action $\actChooseCall$
+sur un appel à une fonction $g$
+et qu'il n'y a pas encore de spécialisation, on en crée une nouvelle.
+
+S'il y a une spécialisation $g_j$ (et une seule),
+elle est choisie pour être appelée, indépendamment de son marquage.
+\bb
+
+Si plusieurs $g_j$ existent, c'est
+{\it la plus proche}\footnote{Les critères de choix restent à définir.}
+qui doit être choisie.
+\bb
+
+S'il manque des marques aux sorties de la fonction choisie,
+il faut les lui ajouter. Pour cela,
+il n'y a pas de génération de $\actMissingOutputs$ puisqu'on ne souhaite avoir
+qu'une seule spécialisation~: elle est directement remplacée
+par $\actAddOutputMarks$.
+\bb
+
+Enfin, l'action $\actChangeCall$ permet d'appeler la fonction choisie.
+C'est cette dernière action qui s'occupe
+ensuite de propager le marquage des entrées dans $f_i$
+en appliquant automatiquement le $\actModifCallInputs(c, f_i)$.
+
+\subsubsection{Réduction avec {\it PreciseSlices}}\label{sec-PreciseSlices}
+
+Dans ce mode, lors de l'application de $\actChooseCall(c, f_i)$,
+le choix de la fonction à appeler s'effectue de la façon suivante~:
+\begin{itemize}
+ \item on sélectionne les spécialisations qui ont la même visibilité
+ que $\outsigc(c, f_i)$ (même si elles n'ont pas exactement le même
+ marquage)~;
+ \item s'il n'y en a pas, on en crée une nouvelle~;
+ \item s'il n'y en a qu'une, elle est choisie~;
+ \item s'il y en a plusieurs, il faut en choisir une.
+Dans le cas, on choisit pour l'instant la première
+spécialisation trouvée. Il est clair que ce choix peut être amélioré
+si on définit des critères de choix.
+
+ Il faut remarquer que cette situation ne peut se produire que si
+ l'utilisateur est intervenu.
+\end{itemize}
+
+
+Remarque~: Si $\Call(f_i)(c)$ est déjà attribué avant l'application de
+$\actChooseCall$, on ignore son ancienne valeur.\\
+
+Dans ce mode, l'application des actions $\actMissingOutputs(c, f_i)$ et
+$\actMissingInputs(c, f_i)$ est équivalente à l'application
+de $\actChooseCall(c, f_i)$.
+\bb
+
+Il faut noter que ce mode peut être également être choisi si l'on veut piloter
+tous les choix manuellement car les actions sont toutes générées, et l'outil ne
+fait un choix que lorsqu'elles sont appliquées. Elles peuvent donc être
+préalablement transformées en $\actChangeCall$ par l'utilisateur.
+
+
+\subsection{Autres actions}
+
+\defaction{CopySlice}
+\subsubsection{Duplication d'une spécialisation~: \actCopySlice}\labact{CopySlice}{1}
+
+L'action $f_j = \actCopySlice(f_i)$ permet simplement de dupliquer $f_i$
+et donc de créer une nouvelle fonction spécialisée $f_j$.
+Le marquage, ainsi que la fonction $\Call(f_i)$ sont simplement copiés.
+
+Il faut noter que, initialement, $f_j$ n'est pas appelée.
+
+\defaction{Combine}
+\subsubsection{Combinaison de spécialisations~: \actCombine}\labact{Combine}{1}
+
+On peut combiner deux spécialisations (c'est-à -dire en faire l'union)
+Ã l'aide de $f_3 = \actCombine(f_1, f_2)$.\bb
+
+La table de marquage se
+calcule simplement en combinant les marques, sans qu'il y ait besoin de
+propager. Il faut ensuite résoudre les appels de fonction, c'est-à -dire
+calculer $\Call(f_3)$. Ce qui est fait
+pour un appel donné $c$ dépend de sa signature dans le résultat $f_3$
+par rapport à ce qu'on a dans $f_1$ et $f_2$.
+On sait que, par construction
+$\sigc(c, f_3) = \sigc(c, f_1) \cup \sigc(c, f_2)$
+et qu'elle est donc supérieure ou égale.
+
+\begin{itemize}
+ \item si $\sigc(c, f_1)=\sigc(c, f_2)$~:
+ \begin{itemize}
+ \item si $\Call(f_1)(c) = \Call(f_2)(c)$~: $\Call(f_3)(c) = \Call(f_1)(c)$
+ \item si $\Call(f_1)(c) = \topc$~: $\Call(f_3)(c) = \Call(f_2)(c)$
+ \item si $\Call(f_2)(c) = \topc$~: $\Call(f_3)(c) = \Call(f_1)(c)$
+ \item sinon, cela veut dire que les deux appels sont attribués à des
+ fonctions différentes~: on choisit celle qui a la plus petite signature
+ (ie. la plus précise).
+ \end{itemize}
+ \item sinon, si $\sigc(c, f_3)=\sigc(c, f_1)$~: $\Call(f_3)(c) = \Call(f_1)(c)$
+ \item sinon, si $\sigc(c, f_3)=\sigc(c, f_2)$~: $\Call(f_3)(c) = \Call(f_2)(c)$
+ \item sinon, $\Call(f_3)(c) = g_i$, et on crée une action
+ $g_i = \actCombine(\Call(f_1)(c), \Call(f_2)(c))$.
+\end{itemize}
+\bb
+
+Il faut noter que la création de $f_3$ ne modifie ni $f_1$, ni $f_2$.
+Si l'objectif est de remplacer $f_1$ et $f_2$ par $f_3$,
+cela peut être fait par une combinaison d'actions élémentaires
+(cf. \S\ref{sec-fusion}).
+
+\defaction{DeleteSlice}
+\subsubsection{Suppression d'une spécialisation~: \actDeleteSlice}\labact{DeleteSlice}{1}
+
+Une fonction spécialisée peut être supprimée à l'aide de l'action
+\actDeleteSlice$(f_i)$, mais cette action ne peut être appliquée que
+que si $f_i$ n'est pas appelée, sauf si elle n'est appelée que par elle même.
+Cela signifie que ses appels doivent être supprimés au préalable à l'aide
+d'actions \actChangeCall{} (ou de \actDeleteSlice{} sur les appelant...).
+
+
+\section{Sélection persistante}
+
+Après une première utilisation des fonctions présentées ci-dessus, il est apparu
+qu'un besoin utilisateur pouvait également être de marquer une instruction (ou
+une donnée à un point de programme) pour toutes les spécialisations d'une
+fonction. Ce type de sélection a été nommée
+\indextxtdef{persistante}{sélection!persistante}.
+Cela signifie que chaque fonction a, en parallèle de ses différents marquages,
+un marquage minimum qui est utilisé à la création de toute nouvelle
+spécialisation. Lorsque l'utilisateur ajoute une sélection persistante,
+elle est ajoutée à la fois dans ce marquage minimum, et dans toutes les
+spécialisations existantes. L'ajout d'une sélection persistante dans une
+fonction peut également rendre tous ses appels visibles (si l'option est
+positionnée) car l'utilisateur souhaite que le programme réduit passe aussi
+souvent au point marqué que le programme source~: cela suppose donc que tous les
+chemins qui mènent à la fonction soit visibles.
+
+\section{Gérer des actions élémentaires}\label{sec-multi-actions}
+
+Les actions élémentaires présentées ci-dessus doivent être combinées pour
+répondre à des requêtes de plus haut niveau.
+L'utilisateur exprime ses requêtes en ajoutant des actions dans la liste
+du projet, mais celles-ci doivent ensuite être décomposées pour être appliquées,
+et l'application d'actions élémentaires en génère d'autres.\\
+
+La granularité à laquelle l'utilisateur peut intervenir reste Ã
+définir en fonction de ce que l'on souhaite faire de l'outil.\\
+
+Nous allons tout d'abord examiner comment peut être gérée la liste d'action
+(\S\ref{sec-gestion-actions}), puis nous verrons un certain nombre d'exemple de
+combinaison d'actions élémentaires pour répondre à des requêtes de plus haut
+niveau.
+
+\subsection{Modification ou suppression d'actions}\label{sec-gestion-actions}
+
+Les actions de l'utilisateur peuvent être supprimées par ses soins avant d'être
+appliquée. En revanche, les actions générées telles que \actChooseCall{},
+\actMissingInputs{} ou \actMissingOutputs{} consistent à rendre un appel de
+fonction cohérent, elles ne peuvent donc pas être supprimées. Par contre,
+l'utilisateur peut les transformer en \actChangeCall{} pour préciser la fonction
+qu'il souhaite voir appeler. Dans ce cas, cette nouvelle action ne pourra à son
+tour pas être supprimée.
+
+\subsection{Ordre des actions}\label{sec-ordre}
+
+A priori, le marquage étant parfaitement défini, il ne dépend pas de l'ordre des
+calculs. Néanmoins, le résultat obtenu peut dépendre de l'ordre d'application
+des actions, car si on applique une action qui construit une nouvelle
+fonction $g_j$, puis une autre pour construire $f_i$ qui appelle une fonction
+$g$, $g_j$ va pouvoir être choisie pour l'appel, alors que si la première action
+n'avait pas encore été appliquée, c'est peut-être une autre spécialisation qui
+aurait été appelée, ou une nouvelle action qui aurait été générée.
+De plus, certaines actions ont une précondition qui n'est éventuellement
+satisfaite que si les actions générées sont appliquées dans l'ordre.
+On ne prévoit donc pas dans un premier temps
+de pouvoir modifier l'ordre des actions.
+
+\subsection{Propagation aux appelants}\label{sec-propagate-to-calls}
+
+Les actions élémentaires ne propagent le marquage des entrées d'une certaine
+fonction $f_i$ qu'aux appels $(c, h_k)$ tels que $\Call(h_k)(c) = f_i$.
+Si on souhaite construire de nouvelles fonctions spécialisées pour toutes les
+fonctions $h$ qui appellent $f$ afin de propager le marquage, il faut enchaîner
+différentes actions élémentaires.
+
+Voyons par exemple comment piloter l'ajout d'une marque utilisateur $m$ sur un
+élément $e$ de $f$ avec propagation dans les appelants~:
+\begin{itemize}
+ \item $f_i = \actNewSlice (f_0)$
+ \item $\actAddUserMark (f_i, (e, m))$
+ \item $\forall h_0. \exists c_f \in \call(h_0)
+ \imply h_k = \actNewSlice (h_0) \land \forall c_f. \actChangeCall(c_f, h_k,
+ f_i)$
+\end{itemize}
+
+\subsection{Fusion de deux spécialisation}\label{sec-fusion}
+
+Si deux spécialisations $f_1$ et $f_2$ ont été calculées, l'utilisateur peut
+vouloir les fusionner. Pour cela, il faut appliquer les actions suivantes~:
+\begin{itemize}
+ \item $f_3 = \actCombine (f_1, f_2)$
+ \item $\forall c, h_k. \Call(h_k)(c) = f_1 \imply \actChangeCall(c, h_k, f_3)$
+ \item $\forall c, h_k. \Call(h_k)(c) = f_2 \imply \actChangeCall(c, h_k, f_3)$
+ \item $\actDeleteSlice(f_1), \actDeleteSlice(f_2)$
+\end{itemize}
+
+% \subsection{autres exemples...}
+% \afaire{ compléter au fur et à mesure, en fonction des besoins.}
+
+%--------------------------------------
+\section{Production du résultat}
+
+On rappelle que l'objectif est de générer des fichiers source compilables.
+Or, après avoir effectué tout le travail de filtrage présenté précédemment,
+on obtient un projet contenant, pour chaque fonction, zéro, une, ou plusieurs
+fonctions filtrées, avec pour chaque fonction filtrée, une table de marquage
+permettant de déterminer les instruction visibles,
+et les appels de fonction.
+Voyons ce qu'il manque pour obtenir le résultat final.
+
+\subsection{Déclarations globales}
+
+Pour produire des fichiers de résultats, il faut avant tout être capable d'y
+mettre ce qui est en dehors des fonctions, à savoir les déclarations globales.
+
+Il aurait été possible de calculer des liens de dépendance vers les déclarations
+globales, mais on a considéré que la suppression de
+déclarations inutiles était une fonctionnalité intéressante en soi,
+et cela est donc fait sous forme d'une passe supplémentaire sur le résultat.
+
+\subsection{Fonctions}
+
+Pour une fonction qui a été analysée, on a calculé la représentation de la
+fonction source, ainsi qu'une ou plusieurs spécialisations.
+Les fonctions non analysées ne figureront pas dans le résultat
+car elles ne participent pas au calcul demandé.
+
+\subsubsection{Fonction spécialisée}
+
+Pour générer le code correspondant à une fonction spécialisée,
+il faut lui donner un nom qui n'entre pas en conflit avec celui de des fonctions
+source ou des autres spécialisation.
+Il faut également avoir sa signature pour savoir si elle possède une valeur
+de retour, et connaître la liste de ses arguments visibles.
+
+\subsubsection{Garder ou non la fonction source}
+
+Une fonction source n'a besoin d'être présente dans l'application générée
+que si elle est appelée.
+Le traitement d'un appel de fonction qui ne conduit pas à appeler une
+spécialisation doit donc mémoriser un lien avec la fonction source.
+
+\subsubsection{Variables locales statiques}
+
+Lorsqu'une fonction est présente en plusieurs exemplaires dans le résultat,
+il faut penser à sortir les éventuelles variables statiques communes à plusieurs
+spécialisations afin qu'elles soient partagées par les différentes fonctions.
+
+\subsubsection{Modification des appels}\label{sec-filtre-call}
+
+Pour générer un appel à une fonction spécialisée,
+il faut avoir les mêmes informations que celles qui sont utilisées pour la
+définition de la fonction, à savoir~:
+\begin{itemize}
+\item son nom,
+\item la liste des paramètres formels nécessaires au calcul des sorties
+sélectionnées,
+\item le type de retour pour savoir si la fonction produit un résultat.
+\end{itemize}
+
+\subsubsection{Génération des nouveaux prototypes}
+
+Lorsque l'on produit des fonctions spécialisées, il faut aussi
+générer les prototypes associés. Comme elles ont forcément la même portée que la
+fonction source, il suffit de générer ces nouveaux prototypes à l'endroit où
+l'on rencontre le prototype initial.
+
+\subsubsection{Gestion des blocs}
+
+Même si le graphe de dépendance contient des éléments représentant les blocs,
+et donc que le \slicing associe des marques à ces éléments,
+il est délicat de supprimer un bloc, même si est sensé être invisible.
+En effet, cela peut parfois changer la sémantique,
+et dans une construction \verb!if (c) { S1; } else { S2; }!,
+on peut même obtenir un résultat syntaxiquement incorrect
+si on n'y prend pas garde.\\
+
+Comme il peut être utile par ailleurs d'avoir un outil de nettoyage de code
+qui supprime proprement les blocs vide, on décide de ne pas les traiter
+au niveau du \slicing. Tous les blocs sont donc considérés comme visibles
+indépendamment de leur marque, et le nettoyage est effectué lors d'une passe
+supplémentaire sur le code généré.
+
+\subsection{Annotations}
+
+Les annotations peuvent être utilisées pour construire des requêtes de \slicing,
+mais au delà de cette possibilité, il faut déterminer si les annotations
+présentes dans le code source doivent être mises dans le résultat.
+On regarde pour cela si les données qui permettent d'évaluer la propriété sont
+préservées dans le programme réduit : si c'est le cas, l'annotation va être
+gardée, dans le cas contraire, elle va être slicée.
diff --git a/doc/slicing/intro.tex b/doc/slicing/intro.tex
new file mode 100644
index 0000000000000000000000000000000000000000..7f312529bebf333dfa3e2427babd70bc15d6a658
--- /dev/null
+++ b/doc/slicing/intro.tex
@@ -0,0 +1,394 @@
+\chapter{Introduction}
+
+
+L'objectif de ces travaux est de concevoir et développer un outil de \slicing
+se basant sur le noyau \ppc d'analyse statique de programme C
+en s'inspirant du module équivalent déjà développé
+sur la base de l'outil \caveat qui est décrit dans \cite{slicingCaveat}.
+
+
+
+\section{État de l'art}\label{sec-lart}
+
+Voyons tout d'abord
+ce que dit la littérature sur ce sujet
+afin de se positionner par rapport aux différentes méthodes.\\
+
+On s'appuie ici sur la présentation des travaux sur le calcul de PDG
+effectué dans un autre document.
+
+\subsection{Origine}
+
+La technique consistant à réduire un logiciel -~appelée \slicing en anglais~-
+a été beaucoup
+étudiée depuis son introduction par la thèse de \cite{weiser79}.
+L'article \cite{weiser81} rappelle que sa définition du \slicing est
+la suivante~:
+
+\begin{definition}{slicing selon Weiser}
+Le programme d'origine et le programme transformé doivent être identique
+si on les regarde à travers la fenêtre défini par le critère de \slicing
+défini par un point de programme et une liste de variable.
+C'est à dire que la séquence de valeurs observées pour ces variables
+à ce point doivent être les mêmes.
+
+De plus, le programme transformé doit être obtenu par suppression de certaines
+instructions du programme d'origine.
+\end{definition}
+
+Cette définition a été remise en cause par la suite
+au motif que cette définition n'est pas suffisante pour traduire
+la compréhension intuitive que l'on a du \slicing.
+On trouve l'exemple suivant dans \cite{kumar02better},
+mais cette critique revient a plusieurs reprises.
+
+\begin{exemple}
+\begin{center}
+\begin{tabular}{|l|l|l|}
+\hline
+P & P1 & P2 \\
+\hline
+a = 1; & & a = 1; \\
+b = 3; & & b = 3; \\
+c = a*b; & & \\
+a = 2; & a = 2; & \\
+b = 2; & b = 2; & \\
+d = a+b; & d = a+b; & d = a+b; \\
+\hline
+\end{tabular}
+\end{center}
+P1 est probablement ce qu'on attend du \slicing de P si l'on s'intéresse
+à la variable d après la dernière instruction, mais P2
+est aussi correct du point de vue de Weiser.
+\end{exemple}
+
+Il semble peu probable de construire un algorithme qui construit P2,
+mais on voit néanmoins que la définition est insuffisante
+pour spécifier complètement ce que doit être le résultat d'un \slicing.\\
+
+\cite{Choi94} formalise la définition de la façon suivante~:
+
+\begin{definition}{Correct-Executable-Slice}
+Let $P_{slice}$ be an executable slice of a program $P_{org}$,
+S be the set of statements in $P_{slice}$ and $Proj_S(P_{org}, \sigma_0)$
+be the projection of $Trace(P_{org}, \sigma_0)$ that contains
+only those statement traces produced by statements in S.
+$P_{slice}$ is a correct executable slice of $P_{org}$ if
+ $Proj_S(P_{org}, \sigma_0)$ is identical to $Trace(P_{org}, \sigma_0)$.
+\end{definition}
+
+Même si cette définition possède les mêmes inconvénients que celle d'origine,
+elle lui permet de faire des preuves de correction des ses algorithmes
+relativement à cette formalisation.
+
+\subsection{Graphes de dépendances}
+
+Comme on l'a vu dans \cite{ppcPdg} les graphes de dépendances sont à la base des
+calculs.
+\cite{Ottenstein84}, puis \\
+\cite{Ferrante87}
+introduisent la notion de PDG ({\it Program Dependence Graph}).
+Un tel graphe est utilisé pour représenter les différentes dépendances
+entre les instructions d'un programme.
+Ils l'exploitent pour calculer un {\it slicing non-executable}
+qui s'intéresse uniquement aux instructions
+qui influencent la valeur des variables,
+mais cette représentation sera également utilisée pour calculer un
+\slicing exécutable.\\
+
+Cette représentation, initialement intraprocédurale, a été étendue
+à l'interprocédurale dans \cite{horwitz88interprocedural} où elle
+porte le nom de SDG ({\it System Dependance Graph}).
+Dans ce papier, Susan Horwitz s'intéresse à un \slicing
+ayant la définition suivante~:
+
+\begin{definition}{slicing selon \cite{horwitz88interprocedural}}
+A slice of a program with respect to program point p and variable x
+consists of a set of statements of the program that might affect
+the value of x at p.
+\end{definition}
+
+Mais elle précise par ailleurs que x doit être défini ou utilisé en p.
+En effet, lorsque le graphe est construit, le \slicing se résume à un
+problème d'accessibilité à un noeud, or un noeud représente un
+point de programme et ne contient que les relations concernant les variables
+qui y apparaissent.\\
+
+Nous avons vu dans \cite{ppcPdg} que l'on peut lever cette limitation en gardant
+une correspondance entre les données à un point de programme et les noeud du
+graphe.
+
+\subsection{Slices vs. Chops}
+
+On a vu que le \slicing s'intéresse à ce qui se passe avant d'arriver
+Ã un certain point.\\
+
+La notion de {\it chopping} est similaire sauf qu'elle s'intéresse
+aux instructions qui vont être influencées par une certaine donnée
+Ã un certain point.
+
+\subsection{Critères de \slicing}
+
+Nous n'avons pour l'instant parlé que du \slicing dit {\bf statique}
+qui s'intéresse à toutes les exécutions d'un programme,
+par opposition au \slicingb {\bf dynamique}
+ qui considère la projection du programme
+sur l'exécution d'un jeu d'entrée particulier,
+ou {\bf quasi-statique} qui fixe uniquement une partie des entrées.\\
+
+Une version plus générale qui inclus à la fois l'un et l'autre
+est appelé \slicingb {\bf conditionnel} (\cite{fox-consit}).
+Il s'agit de spécifier le cas d'étude sous forme de
+des propriétés sur le jeu d'entrées (préconditions).\\
+
+Par la suite, la notion de {\bf \slicing conditionnel arrière}
+a été introduit dans plusieurs buts différents :
+\begin{itemize}
+\item la première technique décrite dans \cite{Comuzzi} et
+ appelée p-slice, s'intéresse aux instructions qui participent
+à l'établissement de la postcondition,
+\item alors que la deuxième (\cite{fox01backward})
+a un objectif un peu différent car vue
+comme une aide à la preuve permettant d'éliminer du programme
+tous les cas dans lesquels la propriété est vérifiée (automatiquement),
+pour ne garder que ceux pour lesquels le résultat n'est pas certain
+afin que l'utilisateur puisse se concentrer sur la vérification
+de cette partie.
+
+Dans \cite{Harman2001}, ces auteurs continuent
+les travaux précédents en combinant
+une propagation avant et une propagation arrière.
+Quelques exemples et la présentation d'un outil mettant en {\oe}uvre
+le travail de cette équipe est présenté dans \cite{daoudi-consus}.
+Ils définissent leur objectif de la façon suivante :
+\end{itemize}
+
+\begin{definition}{pre-post conditioned slicing}
+Statements are removed if they cannot lead to
+satisfaction of the negation of the post condition,
+when executed in an initial state which satisfies
+the pre-condition.
+\end{definition}
+
+\begin{itemize}
+\item une troisième approche est présentée très brièvement
+dans (\cite{Chung-2001}~:
+il s'agit également de spécifier le critère de slicing par une pré-post
+et de combiner une propagation avant et arrière de propriétés
+pour ne garder que ce qui participe
+à l'établissement de la post dans le contexte de la précondition.
+\end{itemize}
+
+
+% {\bf contraint} (\cite{Field95}),
+
+
+Ces nouveaux types de \slicing
+ne se basent plus uniquement sur des relations de dépendance,
+mais nécessitent différentes techniques complémentaires comme
+l'exécution symbolique ou encore le calcul de WP.\\
+
+Dans le cadre de notre étude, il semble intéressant d'explorer
+cette voie étant donné que nous disposons (ou disposerons)
+de tels outils d'analyse dans \ppc.\\
+
+
+
+
+
+
+
+\subsection{Transformations}
+
+Dans nos précédents travaux, nous avons exploré certaines transformations
+de programme comme la spécialisation de fonction
+(et donc la transformation des appels),
+et également la propagation de constantes.\\
+
+Divers papiers, dont \cite{harman01gustt},
+présentent un \slicing qu'ils appellent {\bf amorphe}
+dans lequel il s'agit de
+combiner des techniques de \slicing et de transformation de programme.
+
+ \cite{ward2002} (pour une raison qui m'échappe)
+préfère parler de \slicingb {\bf sémantique}\\
+
+% {\bf à développer !}
+
+
+\subsection{Outils}
+
+On peut citer deux outils qui mettent en {\oe}uvre cette technique sur les
+programmes C-ANSI~:
+\begin{itemize}
+\item {\it unravel}, présenté dans \cite{lyle97using},
+ est disponible sur le web (cf. [\cite{unravel}])~;
+\item et le {\it Wisconsin Program-Slicing Tool} (\cite{reps93wisconsin}),
+est commercialisé par {\it GrammaTech} sous le nom {\it CodeSurfer}
+(cf. site web [\cite{CodeSurfeur}]).\\
+\end{itemize}
+
+Ces outils permettent tous les deux~:
+\begin{itemize}
+\item de sélectionner les parties de code utiles au calcul
+d'une variable à un point de contrôle,
+\item de visualiser les instructions sélectionnées sur le
+code source de l'utilisateur,
+\item et de faire des opérations d'union et l'intersection entre plusieurs
+réductions.
+\end{itemize}
+
+\subsection{Pour en savoir plus}
+
+Un état de l'art en 1995 est présenté dans \cite{tip95survey}.\\
+Plus récemment, \cite{survey2005} font un tour très complet des évolutions
+jusqu'en 2005.
+
+Par ailleurs, un site internet~- dont l'adresse est donnée
+dans la bibliographie sous la référence \cite{wwwSlicing}~-
+a tenu à jour une liste des projets
+et une bibliographie très impressionnante sur le \slicing
+jusqu'en 2003, mais ce site ne semble plus maintenu.\\
+
+
+\section{Ce que l'on veux faire}\label{sec-but}\label{sec-defR}
+
+\newcommand{\remitem}[1]{\begin{itemize}\item #1 \end{itemize}}
+%\newcommand{\warnitem}[1]{\begin{itemize}\item[$\blacktriangle$] #1
+ %\end{itemize}}
+%\newcommand{\question}[1]{\begin{itemize}\item[{\bf ?}] #1 \end{itemize}}
+%\newcommand{\smilitem}[1]{\begin{itemize}\item[$\smiley$] #1 \end{itemize}}
+%\newcommand{\frownitem}[1]{\begin{itemize}\item[$\frownie$] #1 \end{itemize}}
+
+Le document \cite{baudinImpact} spécifie un outil d'aide à l'analyse d'impact
+après avoir analysé les besoins dans ce domaine.
+Le module de \slicing est présenté comme étant
+un composant important de cet outil.\\
+
+Résumons ici les caractéristiques principales de l'outil
+qui ont servies de spécification initiale~:
+
+\begin{itemize}
+\item l'outil sert à construire un programme compilable
+à partir d'un programme source, les deux programmes ayant le même
+comportement vis à vis des critères fournis par l'utilisateur~;
+\item la construction de ce programme résultat est un processus interactif.
+\item {\bf commandes} de l'outil
+\remitem{elles correspondent à des fonctions internes (en \caml)
+et doivent permettre d'accéder aux différentes fonctionnalités.\\
+Elles pourront être utilisées directement,
+combinées dans des {\it scripts} pour effectuer des opérations
+plus évoluées ou encore servir à construire un protocole de communication avec
+une interface graphique~;}
+\item commandes {\bf d'interrogation}
+\remitem{elles servent à questionner le système.
+Elles ne doivent pas modifier l'état interne de l'outil.
+Même si elles effectuent certains calculs pour répondre,
+et qu'elles stockent ces résultats pour éviter un recalcul ultérieur,
+ceci doit être transparent pour la suite des traitements~;}
+\item commandes dites {\bf d'action}
+\remitem{elles doivent permettent de construire
+le résultat du \slicing. Ces commandes doivent pouvoir s'enchaîner et se
+combiner~;}
+\item l'outil maintient une {\bf liste d'attente} des actions à effectuer.
+Ceci est utile car certains traitements peuvent être décomposés
+en plusieurs actions que l'utilisateur peut ensuite choisir d'appliquer ou non.
+Cela permet d'avoir un contrôle plus fin des calculs~;
+\item le programme résultant ne peut être généré
+que lorsque la liste d'attente est vide~;
+\item les traitements doivent être modulaires~;
+\item chaque fonction du programme source peut~:
+ \begin{itemize}
+ \item ne pas apparaître dans le résultat,
+ \item être simplement copiée dans le résultat,
+ \item correspondre à une ou plusieurs fonctions spécialisées du résultat.
+ \end{itemize}
+\item dans la représentation interne du résultat, les instructions
+sont associées à un marquage qui indique si elles doivent être cachées,
+ou sinon, la raison de leur présence, c'est-à -dire par exemple
+si elles participent au contrôle ou à la valeur d'une donnée sélectionnée, etc.
+
+\item identification d'instructions non significatives (ou superflues)
+\remitem{il s'agit d'être capable de distinguer ce que l'on doit ajouter
+lorsque l'on ne fait pas de spécialisation.
+Prenons par exemple le cas d'un appel $L : f(a,b);$
+où seul $a$ est nécessaire au calcul qui nous intéresse,
+mais que l'on ne souhaite pas spécialiser en $f(a);$.
+Il faudra alors ajouter ce qui permet de calculer $b$ en $L$
+aux instructions sélectionnées,
+mais en préservant l'information qu'elles sont {\it superflues}~;
+}
+
+\item spécialisation du code
+\remitem{il s'agit d'être capable d'effectuer des transformations syntaxiques
+pour réduire le code au maximum. Par exemple, si après une instruction
+\verbtt{y = x++;}, on n'a besoin que de \verbtt{x},
+il faut être capable de décomposer cette instruction
+afin de ne garder que \verbtt{x++;}
+
+Ce type de transformation étant déjà faite en amont du module de \slicing,
+le problème ne se pose plus pour ce type d'instruction,
+mais il existe encore pour la spécialisation des appels de fonction.
+En effet, si une fonction $f$ prend, par exemple,
+deux arguments dont un seul sert à calculer ce qui nous intéresse,
+on veut être capable de construire une fonction $f_1$
+qui ne prend qu'un seul argument,
+et transformer l'appel à $f$ en un appel à $f_1$.
+
+Par ailleurs, on peut également envisager de transformer des
+instructions lorsque l'on connaît la valeur constante d'une variable.
+}
+\end{itemize}
+
+
+\section{Plan des documents}
+
+Ce document présente uniquement les principes de ce qui a été développé.
+Pour plus de détail sur l'implémentation ou les commandes disponibles,
+le lecteur est invité à consulter la documentation du code
+car elle sera toujours plus détaillée et à jour que ce rapport.
+Comme la boîte à outil de \slicing est un greffon de \ppc,
+son interface est définie dans le module \verbtt{Db.Slicing}.
+Par ailleurs, l'introduction de la documentation interne du module
+donne une idée de l'architecture, et donne des points d'entrée.\\
+
+Les principes de calcul des graphes de dépendances
+sur lequel s'appuie le \slicing est présenté dans \cite{ppcPdg}.\\
+
+Le chapitre \ref{sec-filtrage-fct} présente
+la façon dont sont marquées les instructions d'une fonction pour
+effectuer une réduction intraprocédurale.\\
+
+Puis, le chapitre \ref{sec-interproc} expose comment sont organisés les calculs
+pour faire une propagation des réductions à l'ensemble de l'application,
+et comment on se propose de spécialiser les fonctions.\\
+
+Enfin, le chapitre \ref{sec-man} présente comment utiliser le module
+développé et propose donc une vision davantage dédiée à un utilisateur
+potentiel.\\
+
+
+Ce rapport étant un document de travail, il va évoluer au fur et à mesure des
+réalisations~:
+\begin{itemize}
+ \item la version 1.0 du 27 juin 2006 présentait
+les développements en cours concernant les graphe de dépendance
+et le marquage d'une fonction. La présentation des travaux à faire
+pour la gestion d'un \slicing interprocédural était moins détaillée car
+plus prospective. Suivait un chapitre contenant un manuel d'utilisation.
+Enfin, la conclusion présentait l'état courant de l'outil,
+et les perspectives d'évolution.
+\item dans la version 2.0 du 26 juin 2007, la partie sur le graphe de
+ dépendance a été extraite car elle fait l'objet d'un document séparé.
+ Le \slicing interprocédural est cette fois présenté en détail.
+ Les parties issues du document de spécification dont les idées
+ n'ont finalement pas été retenues ont été déplacées en annexe
+ \ref{sec-projets} pour mémoire. La partie sur l'utilisation de l'outil
+ a pour l'instant été conservée, même si elle n'est pas très spécifique Ã
+ l'utilisation du greffon de \slicing.
+\end{itemize}
+
+Fin 2008, ce document peut être considéré comme stable,
+car même si le développement évolue, il ne s'agit plus de modifier les
+fonctionnalité de bases, mais plutôt d'ajuster des points de détail pour
+améliorer la précision par exemple.
diff --git a/doc/slicing/macros_slicing.tex b/doc/slicing/macros_slicing.tex
new file mode 100644
index 0000000000000000000000000000000000000000..8e6b866c7cb643d377418cad661758f791675109
--- /dev/null
+++ b/doc/slicing/macros_slicing.tex
@@ -0,0 +1,187 @@
+%==============================================================================
+\usepackage{tabularx}
+\usepackage{alltt}
+\usepackage{ulem} %sout
+
+\usepackage{amsmath}
+\usepackage{wasysym}
+\usepackage{stmaryrd}
+\usepackage{listings}
+
+\usepackage[french]{varioref}
+
+%------------------------------------------------------------------------------
+\newcommand{\setenvclass}[2]{}
+
+\usepackage{listings}
+% TODO :
+\lstdefinestyle{clststyle}{}
+\lstnewenvironment{clisting}
+ {
+ \setenvclass{lstlisting}{clisting}
+ \lstset{language=C,
+ style=clststyle,
+ inputencoding=utf8,
+ extendedchars=true,
+ literate={ç}{{\c{c}}}1
+ {â}{{\^{a}}}1
+ {Ã }{{\`{a}}}1
+ {ê}{{\^{e}}}1
+ {ë}{{\"{e}}}1
+ {é}{{\'{e}}}1
+ {è}{{\`{e}}}1
+ {ï}{{\"{\i}}}1
+ {î}{{\^{\i}}}1
+ {ô}{{\^{o}}}1
+ {û}{{\^{u}}}1
+ {ü}{{\"{u}}}1}
+ }
+ {}
+
+\newcommand{\camlListingInput}[1]{
+ \begin{footnotesize}
+ \lstinputlisting[language=caml,
+ style=clststyle,
+ inputencoding=utf8,
+ extendedchars=true,
+ literate={ç}{{\c{c}}}1
+ {â}{{\^{a}}}1
+ {Ã }{{\`{a}}}1
+ {ê}{{\^{e}}}1
+ {ë}{{\"{e}}}1
+ {é}{{\'{e}}}1
+ {è}{{\`{e}}}1
+ {ï}{{\"{\i}}}1
+ {î}{{\^{\i}}}1
+ {ô}{{\^{o}}}1
+ {û}{{\^{u}}}1
+ {ü}{{\"{u}}}1]{#1}
+ \end{footnotesize}
+}
+
+%-----------------------------------------------
+% Commandes pour mettre des ref dans l'index :
+\newcommand{\idb}[1]{\textbf{#1}}
+\newcommand{\indextxt}[1]{\index{#1}{\bf #1}}
+\newcommand{\indexdef}[1]{\index{#1|idb}{{\bf #1}}}
+\newcommand{\indextxtdef}[2]{\index{#2|idb}{{\bf #1}}}
+
+%-----------------------------------------------
+% quelques "mots" spéciaux
+\newcommand{\slicing}{{\it slicing}\xspace}
+\newcommand{\slicingb}{{\it slicing\ }}
+ % permet de corriger les cas où \slicing est suivi d'une {
+ % car il semble que xspace gère mal ce cas.
+\newcommand{\caml}{{\sc Ocaml}\xspace}
+\newcommand{\caveat}{{\sc Caveat}\xspace}
+\newcommand{\cil}{{\sc CIL}\xspace}
+\newcommand{\ppc}{{\sc Frama-C}\xspace}
+\newcommand{\from}{{\sc From}\xspace}
+
+\newcommand{\mylet}{\text{\it let }}
+\newcommand{\myin}{\text{\it in }}
+
+\DeclareMathOperator{\Call}{\mathcal{C\mathit{all}}}
+
+\makeatletter
+\newcommand*{\motcle}[3]{%
+ \index{#2!#1}%
+ \expandafter \@ifdefinable \csname #3#1\endcsname {%
+ \global \@namedef{#3#1}{\textit{#1}}%
+ }%
+}
+\makeatother
+
+%------------------------------------------------------------------------------
+\newcommand{\verbtt}[1]{{\small{\tt{#1}}}}
+%------------------------------------------------------------------------------
+% Légende des figures :
+\usepackage[hang,small]{caption}
+\renewcommand{\captionfont}{\it}
+\renewcommand{\captionlabelfont}{\it \bf \small}
+%\renewcommand{\captionlabeldelim}{ : }
+%-----------------------------------------------
+% prend le nom du fichier
+% et éventuellement un facteur d'échelle (1 par défaut)
+\newcommand{\uneimage}[1]{
+ \includegraphics[width=1\textwidth]{#1}
+}
+%--------------------------------
+\newcommand{\labcenterepsfig}[3]{
+ \begin{center}
+ \begin{figure}[hbt]
+ \centering{
+ \leavevmode
+ \uneimage{#1}
+ }
+ \caption{\label{#3} #2}
+ \end{figure}
+ \end{center}
+ }
+%------------------------------------------------------------------------------
+\newenvironment{debutenv}[1]
+ {
+ \vspace{5mm}
+ \begin{footnotesize}
+ \setenvclass{minipage}{myminipage}
+ \noindent\begin{minipage}[t]{\textwidth}
+ \fbox{\bf #1} \hrule
+ \vspace{3mm}
+ }
+ {
+ \end{minipage}
+ \end{footnotesize}
+ }
+\newenvironment{finenv}
+ {
+ \begin{footnotesize}
+ \setenvclass{minipage}{myminipage}
+ \noindent\begin{minipage}[t]{\textwidth}
+ }
+ {
+ \hrule
+ \
+ \end{minipage}
+ \end{footnotesize}
+ \vspace{5mm}
+ }
+\newenvironment{monenv}[1]
+ {\begin{debutenv}{#1}}
+ {\end{debutenv}
+ \par
+ \begin{finenv}
+ \end{finenv}}
+
+\newcounter{numexemple}
+\newcommand{\titreexemple}{%
+ \stepcounter{numexemple}{Exemple \arabic{numexemple}}}
+
+\newenvironment{exemple}
+ {\begin{monenv}{\titreexemple}}
+ {\end{monenv}}
+
+\newenvironment{exemple1}
+ {\begin{debutenv}{\titreexemple}}
+ {\end{debutenv}}
+
+\newenvironment{exemple2}
+ {\begin{finenv}}
+ {\end{finenv}}
+
+\newenvironment{astuce}
+ {\begin{monenv}{Astuce}}
+ {\end{monenv}}
+
+\newenvironment{definition}[1]
+ {\begin{monenv}{Definition (#1)}}
+ {\end{monenv}}
+
+\newenvironment{algo}[1]
+ {\begin{monenv}{Algorithme (#1)}}
+ {\end{monenv}}
+
+\newcounter{numrque}
+\newenvironment{remarque}[1]
+ {\refstepcounter{numrque}{\bf Remarque \arabic{numrque}} :\label{#1}}
+ {}
+%==============================================================================
diff --git a/doc/slicing/main.tex b/doc/slicing/main.tex
new file mode 100644
index 0000000000000000000000000000000000000000..a95e2a4163b83cb2eaa8a26b036775a612a1dc0c
--- /dev/null
+++ b/doc/slicing/main.tex
@@ -0,0 +1,31 @@
+\documentclass[a4paper,11pt,twoside,openright,web,lang=french]{frama-c-book}
+
+%\usepackage[french]{babel}
+
+\input{macros_slicing.tex}
+%==============================================================================
+\begin{document}
+
+\coverpage{Slicing --- Documentation technique}
+
+\begin{titlepage}
+\begin{flushleft}
+\includegraphics[height=14mm]{../images/cealistlogo.jpg}
+\end{flushleft}
+\vfill
+\title{Documentation du greffon Slicing}{Conception d'un outil de Slicing}
+\author{Anne Pacalet et Patrick Baudin}
+\begin{tabular}{l}
+CEA List, Laboratoire de Sûreté et Sécurité des Logiciels, Saclay, F-91191 \\
+\end{tabular}
+\vfill
+\begin{flushleft}
+ \textcopyright 2006-2020 CEA LIST
+
+\end{flushleft}
+\end{titlepage}
+
+\begin{sloppypar}
+\input{slicing.tex}
+\end{sloppypar}
+\end{document}
diff --git a/doc/slicing/man.tex b/doc/slicing/man.tex
new file mode 100644
index 0000000000000000000000000000000000000000..a07780b7a58de5afc87bec93c8a8baca66816430
--- /dev/null
+++ b/doc/slicing/man.tex
@@ -0,0 +1,120 @@
+\chapter{Utilisation}\label{sec-man}
+
+Dans ce chapitre essaye de présenter quelques bases qui permettent de tester
+la boîte à outil de \slicing à partir de l'interpréteur ou
+d'un fichier de commande.
+Pour l'utilisation de l'interface graphique,
+ se reporter à la documentation correspondante.
+Il est également possible d'exécuter certaines actions élémentaires
+en ligne de commande. Voir les options proposées à l'aide de~:
+\begin{center}
+\verb!bin/toplevel.top --help!
+\end{center}
+
+\section{Utilisation interactive}
+
+Lorsqu'on lance l'outil pour faire du slicing, il faut lui fournir le ou les
+fichiers à analyser, et au minimum l'option \verbtt{-deps}
+qui permet d'effectuer l'analyse de
+dépendances (utiliser \verbtt{--help} pour voir les autres options)~:
+\begin{center}
+\verb!bin/toplevel.top -deps fichier.c!
+\end{center}
+
+On se retrouve alors avec un prompt \verb!#!
+qui signale que l'on est sous un interpréteur \caml.\\
+
+Pour quitter l'interpréteur, il faut utiliser la commande~:
+\begin{center}
+\verb!#quit;;!
+\end{center}
+
+(le \verb!#! n'est pas le prompt, il fait parti de la commande).
+On peut aussi utiliser \verbtt{Ctrl-D}.
+
+\begin{astuce}\label{astuce-ledit}
+Comme tout interpréteur \caml, il n'a pas de capacité d'éditer la ligne de
+commande (pour corriger une faute de frappe par exemple), ni d'historique (pour
+rappeler une commande précédente). Il est donc fortement conseillé, même si ce
+n'est pas indispensable, d'installer
+\indextxt{\verbtt{ledit}}, que l'on peut obtenir à l'adresse~: \\
+\url{ftp://ftp.inria.fr/INRIA/Projects/cristal/Daniel.de\_Rauglaudre/Tools/}.
+Il suffit ensuite de faire précéder le nom de la commande par \verbtt{ledit}, tout
+simplement.
+Faire \verbtt{man ledit} pour avoir plus d'information sur les possibilités de cet
+outil.
+\end{astuce}
+
+Sous l'interpréteur, on peut utiliser n'importe quelle instruction \caml,
+et toutes les commandes spécifiques à l'outil.
+
+Pour ceux qui ne sont pas familier avec \caml,
+pour lancer une commande, il faut taper son nom suivie des arguments,
+ou de parenthèses vide s'il n'y a pas d'arguments, et terminer par deux
+points-virgules.
+
+L'interpréteur affiche le type de retour de la commande
+(\verbtt{unit} correspond au type vide),
+suivi éventuellement de la valeur retournée.
+Dans la plupart des cas, la première information n'intéresse pas l'utilisateur,
+mais cet affichage ne peut pas être désactivé.
+Il peut parfois être utile pour retrouver la signature des commandes<
+par exemple~:
+
+\centerline{\tt module S = Db.Slicing;;}
+
+affiche le type du nouveau module S, et permet donc de voir la liste des
+commandes du module \verbtt{Db.Slicing}.\\
+
+L'organisation de \ppc regroupe toutes les commandes dans le module \verbtt{Db}.
+Le sous-module \verbtt{Db.Slicing} contient les commandes de \slicing.
+Le nom d'une commande doit normalement être préfixé par le nom du
+module a qui elle appartient.
+Pour pouvoir utiliser les noms sans
+préfixe, il faut ouvrir le module à l'aide de~:
+
+\centerline{\tt open Db;;}
+
+On peut aussi choisir de renommer le module pour avoir un préfixe plus court~:
+
+\centerline{\tt module S = Db.Slicing;;}
+
+Des commandes provenant d'autres modules sont également utiles
+dans le cadre de l'utilisation du \slicing.
+\verbtt{Kui}, en particulier,
+fournit des fonctions qui permettent de naviguer dans les
+informations générées par les autres analyseurs.
+
+\section{Fichier de commandes}
+
+Les commandes peuvent être tapées directement, mais on peut également charger
+des fichiers contenant les commandes grâce à la commande \verb!#use "cmds.ml";;!.
+Le contenu du fichier \verbtt{cmds.ml} est alors interprété comme si on l'avait
+tapé, et on reprend la main sous l'interpréteur à l'issue de son exécution.\\
+
+Si l'on veut simplement lancer un fichier de commandes,
+on peut utiliser la redirection Unix.
+L'interpréteur se terminera alors à la rencontre du EOF (fin de fichier).
+
+\begin{astuce}\label{astuce-jnl-ledit}
+En utilisant \verbtt{ledit} (voir l'astuce \vpageref{astuce-ledit})
+on obtient également la possibilité de mémoriser
+l'historique, et d'avoir donc une journalisation des commandes lancées (très
+pratique comme base pour écrire un script, ou pour rejouer une séquence).
+Pour cela, il suffit de taper~:
+
+\centerline{{\tt ledit -h cmds.ml bin/toplevel.top} ... arguments...}
+\end{astuce}
+
+\section{Exemples}
+
+Quelques exemples d'utilisation peuvent être trouvées dans le répertoire de
+test. Les deux fichiers suivant fournissent quelques fonctions qui facilitent
+l'utilisation~:
+\begin{itemize}
+ \item \verbtt{libSelect.ml} propose une interface simplifiée pour des sélections
+ simples,
+ \item \verbtt{libAnim.ml} permet de générer des représentations graphiques du
+ projet à différentes étapes de sa construction afin de visualiser
+ les relations entre les spécialisations.
+\end{itemize}
diff --git a/doc/slicing/projets.tex b/doc/slicing/projets.tex
new file mode 100644
index 0000000000000000000000000000000000000000..dabfdf57a982b47e52d8855a9dca8b8647246019
--- /dev/null
+++ b/doc/slicing/projets.tex
@@ -0,0 +1,335 @@
+\chapter{Projets}\label{sec-projets}
+
+Ce chapitre regroupe diverses idées qui ont été évoquées à un moment ou un
+autre, et qui ont soit été abandonnées, soit remises à plus tard.
+
+\section{Autres critères}
+
+\subsection{Spécifier ce qu'on ne veut plus}
+
+Un autre critère intéressant de \slicing, qui n'apparaît dans aucun papier,
+serait, je pense, de pouvoir spécifier ce que l'on veut enlever.
+Par exemple, {\it "que devient le programme si on ne s'intéresse pas
+à telle sortie ou à tel traitement"}.\\
+
+Par ailleurs, l'analyse de dépendance utilisée pour le \slicing
+peut également être utilisée pour calculer des informations utiles à d'autres
+analyses. On peut par exemple s'intéresser aux variables dont la valeur
+détermine la sortie d'une boucle; ce qui peut être utiliser comme un indice
+sur les élargissements à effectuer dans une interprétation abstraite.
+
+\subsection{Calcul d'une variable globale}
+
+Le premier filtrage global vise à sélectionner les instructions qui
+participent au calcul d'une variable globale donnée.
+Comme on a accès par ailleurs à la liste des sorties de chaque fonction,
+il suffit de générer les filtres permettant de calculer
+cette variable sur chaque fonction l'ayant comme sortie.
+
+\section{Utilisation de la sémantique}
+
+Cette partie regroupe quelques idées d'évolutions pour améliorer le \slicing
+d'une fonction en utilisant la sémantique des instructions.
+Certaines d'entre elles ont été implémentées dans l'outil précédent;
+d'autres ne sont que des pistes qui restent à explorer.
+
+\subsection{Réduction relative à une contrainte}
+
+Dans l'outil précédent, une commande permettait de couper une branche
+en remplaçant le test de la condition de chemin par un {\tt assert}.\\
+
+Plus généralement,
+on s'intéresse ici à une contrainte représentant une assertion dans le code.
+On aimerait déplacer cette contrainte
+afin de déterminer un point où elle est impossible (réduite à {\it false}).
+On pourrait alors {\it couper} alors la branche correspondante.
+
+Le test conditionnel
+permettant d'accéder à cette branche peut être transformé en assertion,
+ou être supprimé (option ?).
+Dans le premier cas, les données utilisées dans le test
+sont visibles alors que dans le second,
+elles peuvent éventuellement être supprimées
+si elles ne servent pas par ailleurs.
+
+On peut aussi ôter les instructions qui ne sont plus utiles.
+La détection de code mort permet par exemple de supprimer les éléments qui
+n'étaient utilisés que dans la branche supprimée.
+
+\begin{exemple}
+Dans la séquence suivante~:
+\begin{center}
+\mbox{\texttt x = c+1; a = 2; if (c) x += a; y = x+1;}
+\end{center}
+
+si on demande à sélectionner les dépendances de \verbtt{y}, puis à supprimer la
+branche \verb!if (c)!, on obtient~:
+\begin{center}
+\mbox{\texttt x = c+1; \sout{a = 2;} {\bf assert (!c);} \sout{x += a;} y = x+1;}
+\end{center}
+
+où l'on voit que l'instruction \verb!a=2;! disparaît puis qu'elle ne sert plus.\\
+
+On verra ci-dessous comment on peut aussi déterminer que \verbtt{x} vaut alors $1$
+Ã l'aide du calcul de WP, et que donc, \verbtt{y} vaut 2 Ã l'aide de la
+propagation de constantes.
+\end{exemple}
+
+Le problème général lorsque l'on impose des contraintes,
+c'est qu'elles peuvent aussi influencer les résultats d'autres analyses
+comme l'analyse de valeur. On en verra un cas particulier
+ci-dessous avec la propagation de constante.
+
+%--------------------------------------
+\subsection{Passage à un point de programme}
+
+La contrainte dont nous venons de parler peut également être donnée
+implicitement en spécifiant un point de programme. Il s'agit alors d'être
+capable de supprimer ce qui ne sert pas lorsque l'exécution de la fonction passe
+par ce point. Une telle requête peut par exemple être utilisée dans le cadre
+d'une analyse d'impact.\\
+
+Une première étape peut consister à supprimer les branches incompatibles avec le
+point en ne regardant que la syntaxe.
+
+\begin{exemple}
+Dans la séquence suivante~:
+\begin{center}
+\mbox{\texttt if (c) P: x += a; else y = x+1;}
+\end{center}
+si l'utilisateur souhaite examiner le passage au
+point P, on peut éliminer la branche {\texttt else}~:
+\begin{center}
+\mbox{\texttt {\bf assert (c);} P: x += a; \sout{else y = x+1;}}
+\end{center}
+Attention, ceci n'est vrai que si la séquence n'est pas dans une boucle...
+\end{exemple}
+
+Mais il peut être plus intéressant de calculer une précondition qui assure que
+l'on passe par le point donné, et d'utiliser ce résultat comme une contrainte.\\
+
+\remarque{rem-wp} Attention,
+il faut noter que cette précondition ne peut généralement pas être
+calculée par un simple WP car celui-ci assure qu'une propriété est vraie
+si la fonction est exécutée avec des entrées satisfaisant la précondition,
+mais il n'assure pas qu'il n'y a pas d'autres cas possibles.
+Ceci est du à l'approximation introduite par le calcul de WP des boucles.
+
+%--------------------------------------
+\subsection{Propagation de constantes}
+
+D'autres réductions peuvent être effectuées en exploitant
+les constantes du programme.
+
+\begin{exemple}
+Dans la séquence suivante~:
+\begin{center}
+ \verb!x = c ? 1 : -1; if (x<0) f(x); else g(x); !
+\end{center}
+si l'on étudie cette séquence avec une valeur initiale 0 pour \verbtt{c}
+on aimerait savoir déterminer que :
+\begin{itemize}
+\item \verb!x=-1!,
+\item donc que le second test est vrai,
+\item que donc \verbtt{g} ne sera pas appelé,
+\item et que \verbtt{f} sera appelé dans ce contexte avec la valeur \verb!-1!.\\
+\end{itemize}
+
+On souhaite donc obtenir~:
+\begin{center}
+ \verb!assert (c == 0); x = -1; f(-1); !
+\end{center}
+\end{exemple}
+
+Ce calcul peut facilement être effectué par une analyse de valeur externe,
+mais il faut pouvoir lui transmettre la contrainte (ici~: $c=0;$).\\
+
+
+Dans l'outil précédent, le module de \slicing (FLD) avait été couplé Ã
+un module de propagation de constante (CST) de la façon suivante~:
+\begin{itemize}
+ \item pour chaque fonction filtrée, on calcule les états CST correspondants,
+ \item si une branche est supprimée à la demande de l'utilisateur,
+ CST en est informé pour réduire l'état,
+ \item si une constante est associée à une donnée,
+ (par exemple lors de la spécialisation d'une fonction avec un paramètre
+constant)
+ CST en est également informé,
+ \item lors du calcul d'une fonction filtrée, pour chaque saut conditionnel,
+ on interroge CST pour savoir si une branche est inaccessible ($\bot$),
+ et si c'est le cas, les éléments correspondant sont marqués $mM$ (code
+ mort),
+ \item pour chaque appel de fonction, si l'on sait déterminer qu'une ou
+ plusieurs entrées sont constantes, on demande la spécialisation de cette
+ fonction,
+ \item pour chaque appel de fonction, si l'on sait déterminer qu'une ou
+ plusieurs sorties sont constantes, on fournit l'information à CST pour qu'il
+ puisse la propager.
+\end{itemize}
+
+\begin{exemple}
+ Reprenons l'exemple précédent où l'on sait que $c=0$ en 1~:
+\begin{center}
+ \verb!/*1*/ x = c ? /*2*/1 : /*3*/-1; /*4*/if (x<0) /*5*/f(x); else /*6*/g(x); !
+\end{center}
+On a donc~:
+\begin{itemize}
+ \item en \verb!/*1*/! : $c=0$,
+ \item en \verb!/*2*/! : $\bot$ puisque le test est faux,
+ \item en \verb!/*4*/! : $x=-1$,
+ \item en \verb!/*5*/! : toujours $x=-1$,
+ \item en \verb!/*6*/! : $\bot$ puisque le test est toujours vrai,
+\end{itemize}
+Cette séquence est donc réduite à ~:
+\begin{alltt}
+ x = \sout{ c ? 1 : } -1; \sout{ if (x>0)} f\_1(x); \sout{ else g(x); }
+\end{alltt}
+où \verbtt{f\_1} est la fonction \verbtt{f} spécialisée avec son entrée à -1.\\
+\end{exemple}
+
+Quand l'analyse permet de déterminer la valeur précise d'une variable,
+il peut également être intéressant d'utiliser cette information pour effectuer
+une transformation de programme juste avant de produire le résultat.
+On ne peut pas vraiment le faire avant, car on peut être amené à regrouper
+plusieurs fonctions où la valeur peut être différente.\\
+
+
+L'implémentation des points suivants n'a pas été fait dans l'outil précédent,
+et il faudrait donc voir s'il est possible de les intégrer
+dans le nouveau~:
+ \begin{itemize}
+ \item supprimer l'argument correspondant à une entrée constante.
+En effet, lors du calcul de la fonction spécialisée, on ne savait
+pas supprimer l'argument correspondant,
+mais on propageait tout de même la valeur pour supprimer les éventuelles
+branchesmortes.
+\begin{exemple}
+Dans l'exemple précédent,
+on peut spécialiser \verbtt{f} en \verbtt{f\_1} car on sait que $x=-1$.
+\begin{tabular}{ccl}
+Mais on aimerait aussi transformer &:& \verb! void f_1 (int x) { ... }!\\
+en &:& \verb! void f_1 (void) { int x = -1; ... }!
+\end{tabular}
+\end{exemple}
+\item supprimer le calcul d'une condition de \verbtt{if} toujours vraie quand il
+ n'y a pas de \verbtt{else}. Cela n'avait pas été fait car dans
+le module de propagation de constante,
+il n'y avait pas de point de programme correspondant à la branche
+\verbtt{else} manquante. L'état $\bot$ qui lui aurait été
+ associé n'était donc pas là pour permettre cette suppression.
+
+ \end{itemize}
+
+%--------------------------------------
+\subsection{Utilisation de WP}
+
+Comme on l'a vu, la propagation de constante peut permettre de
+spécialiser les fonctions et de couper des branches de programme.
+
+Ce type calcul s'effectue a priori par propagation avant.
+Pour faire de la propagation arrière,
+nous aimerions utiliser un calcul de WP.
+
+Le principe d'utilisation serait le suivant~:
+
+\begin{exemple1}
+ L'utilisateur s'intéresse uniquement à la branche {\it then} du {\it if}.
+ On introduit donc l'assertion $y<0$~:\\
+
+\begin{center}
+\begin{footnotesize}
+\begin{tabular}{|p{5cm}|p{5cm}|}
+ \hline
+Programme source & coupure de branche \\
+ \hline
+\begin{verbatim}
+int f (int c, int x) {
+
+ int y = c ? 1 : -1;
+ if (y < 0) {
+ int z = y - 1;
+ g (z);
+ return z + x;
+ }
+ else
+ return 0;
+}
+\end{verbatim}
+&
+\begin{alltt}
+int f (int c, int x) \{
+
+ int y = c ? 1 : -1;
+ {\bf assert (y < 0); }\{
+ int z = y - 1;
+ g (z);
+ return z + x;
+ \}
+
+
+\}
+\end{alltt}
+\\
+\hline
+\end{tabular}
+\end{footnotesize}
+\end{center}
+\end{exemple1}
+\begin{exemple2}
+\begin{center}
+\begin{footnotesize}
+\begin{tabular}{|p{5cm}|p{5cm}|}
+\hline
+WP & Propagation de constante \\
+\hline
+\begin{alltt}
+int f (int c, int x) \{
+ {\bf /* (c == 0); */ }
+ int y = c ? 1 : -1;
+ assert (y < 0); \{
+ int z = y - 1;
+ g (z);
+ return z + x;
+ \}
+
+\}
+\end{alltt}
+&
+\begin{alltt}
+int f (int c, int x) \{
+ /* (c == 0); */
+ int y = {\bf /* 0 ? 1 : */} -1;
+ assert ({\bf -1} < 0); \{
+ int z = {\bf -1} - 1;
+ g ({\bf -2});
+ return {\bf -2} + x;
+ \}
+
+\}
+\end{alltt}
+\\
+\hline
+\end{tabular}
+\end{footnotesize}
+\end{center}
+
+Sur cet exemple, l'utilisation du WP permet de déterminer que $c$ vaut 0,
+et qu'il est alors possible de propager cette constante.\\
+
+\end{exemple2}
+
+
+La principale difficulté de l'utilisation d'un tel calcul est le pilotage des
+opérations.
+
+Le plus simple est de laisser l'utilisateur contrôler la propagation
+en utilisant des commandes interactives.
+
+L'idée est de lui permettre de donner une contrainte,
+de la remonter à l'aide de WP, et d'en déduire d'autres propriétés,
+utilisable par exemple par l'analyse de valeur.\\
+
+Attention, ici encore, comme dans la remarque \vref{rem-wp},
+il faudra préalablement
+s'assurer que l'approximation introduite par le WP des boucles est
+bien dans le bon sens relativement à ce que l'on souhaite obtenir...
diff --git a/doc/slicing/propagation.fig b/doc/slicing/propagation.fig
new file mode 100644
index 0000000000000000000000000000000000000000..512154ae8aa67a221b98d4d19c31b84c7ff9e7ae
--- /dev/null
+++ b/doc/slicing/propagation.fig
@@ -0,0 +1,100 @@
+#FIG 3.2
+Landscape
+Center
+Metric
+A4
+100.00
+Single
+-2
+1200 2
+0 32 #ff9902
+0 33 #caa671
+0 34 #ff77ff
+0 35 #000000
+5 1 0 1 0 7 75 -1 -1 0.000 0 1 1 0 1366.500 -412.500 990 1080 1440 1125 1890 1035
+ 2 1 1.00 60.00 120.00
+5 1 0 1 0 7 75 -1 -1 0.000 0 0 1 0 2002.500 1552.500 1935 2025 1530 1620 1935 1080
+ 2 1 1.00 60.00 120.00
+5 1 0 1 0 7 75 -1 -1 0.000 0 1 1 0 1957.500 922.500 2025 1080 2115 990 2025 765
+ 2 1 1.00 60.00 120.00
+5 1 0 1 0 7 75 -1 -1 0.000 0 1 1 0 3505.500 2272.500 3645 2610 3870 2250 3645 1935
+ 2 1 1.00 60.00 120.00
+6 1305 1125 1575 1440
+1 2 0 1 0 7 50 -1 -1 0.000 1 0.0000 1440 1282 90 112 1350 1282 1530 1282
+4 0 0 75 -1 18 14 0.0000 4 150 120 1395 1350 2\001
+-6
+1 2 0 1 0 7 50 -1 -1 0.000 1 0.0000 1303 2362 90 112 1213 2362 1393 2362
+1 2 0 1 0 7 50 -1 -1 0.000 1 0.0000 3103 2137 90 112 3013 2137 3193 2137
+1 2 0 1 0 7 50 -1 -1 0.000 1 0.0000 3015 675 90 112 2925 675 3105 675
+2 4 0 1 0 7 100 -1 -1 0.000 0 0 7 0 0 5
+ 4770 2880 0 2880 0 0 4770 0 4770 2880
+2 1 0 1 0 7 80 -1 20 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ 990 2250 1890 2250
+2 3 0 1 0 7 75 -1 20 0.000 0 0 -1 0 0 4
+ 1971 1872 1971 1962 2061 1917 1971 1872
+2 3 0 1 0 7 75 -1 20 0.000 0 0 -1 0 0 4
+ 2025 2565 1935 2610 2025 2655 2025 2565
+2 3 0 1 0 7 75 -1 20 0.000 0 0 -1 0 0 4
+ 2025 2475 1935 2520 2025 2565 2025 2475
+2 1 0 1 0 7 80 -1 20 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ 2610 2250 3510 2250
+2 1 0 1 0 7 75 -1 -1 0.000 0 0 -1 1 0 2
+ 2 1 1.00 60.00 120.00
+ 2070 495 2070 225
+2 3 0 1 0 7 50 -1 0 0.000 0 0 7 0 0 4
+ 1971 1962 1971 2052 2061 2007 1971 1962
+2 3 0 1 0 7 75 -1 20 0.000 0 0 -1 0 0 4
+ 3645 2475 3555 2520 3645 2565 3645 2475
+2 3 0 1 0 7 75 -1 20 0.000 0 0 -1 0 0 4
+ 2025 630 1935 675 2025 720 2025 630
+2 3 0 1 0 7 75 -1 20 0.000 0 0 -1 0 0 4
+ 2025 1125 1935 1170 2025 1215 2025 1125
+2 3 0 1 0 7 75 -1 20 0.000 0 0 -1 0 0 4
+ 1935 945 1935 1035 2025 990 1935 945
+2 3 0 1 0 7 75 -1 20 0.000 0 0 -1 0 0 4
+ 2025 1215 1935 1260 2025 1305 2025 1215
+2 3 0 1 0 7 50 -1 0 0.000 0 0 7 0 0 4
+ 3555 1962 3555 2052 3645 2007 3555 1962
+2 3 0 1 0 7 50 -1 0 0.000 0 0 7 0 0 4
+ 3555 1872 3555 1962 3645 1917 3555 1872
+2 3 0 1 0 7 50 -1 0 0.000 0 0 7 0 0 4
+ 3645 2565 3555 2610 3645 2655 3645 2565
+2 3 0 1 0 7 50 -1 0 0.000 0 0 7 0 0 4
+ 1935 450 1935 540 2025 495 1935 450
+2 3 0 1 0 7 50 -1 0 0.000 0 0 7 0 0 4
+ 1935 540 1935 630 2025 585 1935 540
+2 3 0 1 0 7 50 -1 0 0.000 0 0 7 0 0 4
+ 2025 720 1935 765 2025 810 2025 720
+2 3 0 1 0 7 50 -1 0 0.000 0 0 7 0 0 4
+ 1935 1035 1935 1125 2025 1080 1935 1035
+2 4 0 1 0 7 80 -1 18 0.000 0 0 7 0 0 5
+ 2610 2700 1890 2700 1890 1800 2610 1800 2610 2700
+2 4 0 1 0 7 90 -1 18 0.000 0 0 7 0 0 5
+ 2610 1350 1890 1350 1890 270 2610 270 2610 1350
+2 4 0 1 0 7 80 -1 15 0.000 0 0 7 0 0 5
+ 4230 2700 3510 2700 3510 1800 4230 1800 4230 2700
+2 4 0 1 0 7 50 -1 10 0.000 0 0 7 0 0 5
+ 990 2700 270 2700 270 1800 990 1800 990 2700
+2 4 0 1 0 7 50 -1 10 0.000 0 0 7 0 0 5
+ 990 1350 270 1350 270 270 990 270 990 1350
+3 2 0 1 0 7 75 -1 -1 0.000 0 0 0 3
+ 3555 1935 3015 810 2025 495
+ 0.000 -1.000 0.000
+3 2 0 1 0 7 75 -1 -1 0.000 0 1 0 4
+ 2 1 1.00 60.00 120.00
+ 2070 765 2700 1170 3060 2250 3555 2610
+ 0.000 -1.000 -1.000 0.000
+4 0 0 40 -1 18 12 0.0000 4 135 75 540 225 f\001
+4 0 0 40 -1 18 12 0.0000 4 180 345 450 1080 g();\001
+4 0 0 40 -1 18 12 0.0000 4 150 105 540 1710 g\001
+4 0 0 40 -1 18 12 0.0000 4 180 315 2070 1710 g_1\001
+4 0 0 40 -1 18 12 0.0000 4 180 285 2070 180 f_1\001
+4 0 0 89 -1 18 12 0.0000 4 180 555 2070 675 g_2();\001
+4 0 0 89 -1 18 12 0.0000 4 180 555 2070 1215 g_1();\001
+4 0 0 40 -1 18 12 0.0000 4 180 345 450 720 g();\001
+4 0 0 40 -1 18 12 0.0000 4 180 315 3690 1710 g_2\001
+4 0 0 75 -1 18 14 0.0000 4 150 120 1260 2430 1\001
+4 0 0 75 -1 18 14 0.0000 4 150 120 3060 2205 3\001
+4 0 0 75 -1 18 14 0.0000 4 150 120 2970 765 4\001
diff --git a/doc/slicing/slicing.tex b/doc/slicing/slicing.tex
new file mode 100644
index 0000000000000000000000000000000000000000..451b46fef43b3658a22e01569bc75cea49c135ca
--- /dev/null
+++ b/doc/slicing/slicing.tex
@@ -0,0 +1,79 @@
+%===============================================================================
+% Versions
+\section*{Versions}
+
+\begin{small}
+Seules les versions Vx.0 sont des documents achevés~;
+les autres sont à considérer comme des brouillons.
+
+\begin{enumerate}
+ \item[V4.0 -] 2 novembre 2020~:
+ \begin{itemize}
+ \item Document sous licence Creative Commons
+ ``Attribution-ShareAlike 4.0 International''
+ \url{https://creativecommons.org/licenses/by/4.0/}.
+ \end{itemize}
+ \item[V3.0 - ] 3 décembre 2008~:
+ \begin{itemize}
+ \item corrections mineures,
+ \item ajouts sur le \slicing des déclarations globales,
+ \item ajouts de la gestion des annotations.
+ \end{itemize}
+ \item[V2.0 - ] 26 juin 2007~:
+ \begin{itemize}
+ \item extraction de la documentation du PDG,
+ \item mise à jour vis à vis de l'état de l'outil,
+ \item fusion de la documentation sur l'interprocédural,
+ \item réorganisation de la partie sur l'interprocédural,
+ \item mise en annexe des projets non implémentés.
+ \end{itemize}
+ \item[V1.0 - ] 27 juin 2006~:
+ \begin{itemize}
+ \item ajout de la présentation du document,
+ \item ajout du chapitre "Utilisation" (manuel),
+ \item développement du calcul de certains ensembles sur les graphes de
+ dépendances,
+ \item mise à jour du chapitre sur l'interprocédural,
+ \item ajout d'une conclusion résumant l'état d'avancement des travaux.
+ \end{itemize}
+ \item[V0.2 - ] 27 avril 2006~:
+ \begin{itemize}
+ \item réorganisation de la définition des ensembles d'instructions,
+ \item corrections diverses.
+ \end{itemize}
+ \item[V0.1 - ] 22 février 2006~:
+ \begin{itemize}
+ \item bibliographie sur le \slicing,
+ \item analyse du document \cite{baudinImpact},
+ \item ce qu'on prévoit de faire,
+ \item premiers éléments sur la construction de graphe de dépendances,
+ \item intégration et tri des fichiers de l'ancien document (FLD),
+ \item algorithme de calcul des dépendances de contrôle.
+ \end{itemize}
+\end{enumerate}
+\end{small}
+%-------------------------------------------------------------------------------
+% Table des matières
+\cleardoublepage
+\tableofcontents
+%===============================================================================
+\cleardoublepage\input{intro.tex}
+\cleardoublepage\input{fonction.tex}
+\cleardoublepage\input{interproc.tex}
+\cleardoublepage\input{man.tex}
+\cleardoublepage\input{conclusion.tex}
+%===============================================================================
+\appendix
+%--------------------------------------
+\cleardoublepage \input{algo.tex}
+\cleardoublepage \input{interexples.tex}
+\cleardoublepage \input{intercmds.tex}
+\cleardoublepage \input{projets.tex}
+%-------------------------------------------------------------------------------
+\cleardoublepage
+\bibliographystyle{abbrvnat}
+\bibliography{bib-slicing}
+%--------------------------------------
+\cleardoublepage
+\printindex
+%===============================================================================