%% %% $Id$ %% %% Copyright 1989-2016 MINES ParisTech %% %% This file is part of PIPS. %% %% PIPS is free software: you can redistribute it and/or modify it %% under the terms of the GNU General Public License as published by %% the Free Software Foundation, either version 3 of the License, or %% any later version. %% %% PIPS is distributed in the hope that it will be useful, but WITHOUT ANY %% WARRANTY; without even the implied warranty of MERCHANTABILITY or %% FITNESS FOR A PARTICULAR PURPOSE. %% %% See the GNU General Public License for more details. %% %% You should have received a copy of the GNU General Public License %% along with PIPS. If not, see . %% % Rapport dret144 % Manuel Utilisateur du Paralléliseur % Version 1.0 % rendue le 07.01.91 % Version 1.1 % preparee a partir du 15.03.91 (apres la recette) % % Il faudra faire evoluer ce manuel en tenant compte des remarques des % utilisateurs et au fur et a mesure de l'evolution de PIPS. % Les corrections les plus urgentes sont specifiees en commentaire % commencant par %% \documentclass[12pt]{article} \usepackage[latin1]{inputenc} \input{/usr/share/local/lib/tex/macroslocales/Dimensions.tex} \newcommand{\titre}{PROJET PIPS \\ Manuel Utilisateur du Paralléliseur Batch (Version 1.1)} \newcommand{\auteur}{ François IRIGOIN \\ Pierre JOUVELOT\\ \vspace{0.5cm} {\it Le présent document a été établi en exécution du contrat No.~88.017.01 passé par la Direction des Recherches, Etudes et Techniques (Délégation Générale pour l'Armement)} } \newcommand{\docdate}{15 Décembre 1990} \newcommand{\numero}{E144} \begin{document} \input{/usr/share/local/lib/tex/macroslocales/PageTitre.tex} {\it Le présent document a été établi en exécution du contrat No.~88.017.01 passé par la Direction des Recherches, Etudes et Techniques (Délégation Générale pour l'Armement)} \section*{Introduction} Le Paralléliseur Interprocédural de Programmes Scientifiques PIPS est un compilateur-restructureur {\em source à source} qui transforme du code Fortran séquentiel en du code Fortran parallèle. La version actuelle de PIPS ne vise pas une machine particulière. L'objectif est simplement de détecter autant de parallélisme que possible. Cette notice s'adresse à l'utilisateur averti qui a de bonnes connaissances en programmation et en parallélisation automatique. Il convient de porter son attention directement sur les exemples, en réservant la compréhension de toutes les explications à une lecture postérieure. Elle est restreinte à la version {\em batch} de PIPS. La version multifenêtre de PIPS, {\tt wpips}, n'est pas présentée. Nous présentons tout d'abord les principes et le vocabulaire de base. Nous montrons ensuite comment initialiser l'espace de travail qui va permettre de conserver les nouvelles versions du programme et les informations qui y sont attachées. Nous détaillons ensuite la commande {\em Display} qui permet d'afficher directement des résultats à l'écran. Une utilisation plus complète des fonctionalités de PIPS nécessite l'utilisation d'autres commandes comme {\em Select} qui permet de choisir des options de compilation ou d'analyse, {\em Build} qui permet de calculer des informations ou de transformer le programme sans afficher les résultats et {\em Perform} qui permet d'effectuer des transformations de programme explicitement. Nous donnons ensuite la liste des analyses et des transformations de programme qui peuvent être effectuées avec PIPS. \section{Principes du fonctionnement} %est décrite par le schema 1. Pour préserver les fichiers sources, pour permettre le développement de plusieurs versions et pour regrouper en un unique endroit l'ensemble des fichiers qui sont créés au cours de la compilation d'un programme, l'analyse et les transformations de programme sont réalisées dans le cadre d'un {\bf workspace} (espace de travail) qui n'est qu'un sous-répertoire du répertoire courant. A cet espace de travail est associée une base de données qui indique à chaque instant quelles sont les informations disponibles et quelles sont les options choisies. Chaque {\bf phase} du compilateur va ajouter dans le {\em workspace} de nouveaux fichiers, appelés {\bf ressources} dans la terminologie PIPS. Plusieurs {\em phases} sont généralement enchaînées pour satisfaire une seule requête de l'utilisateur. Afin d'assurer la cohérence de cet enchaînement, toutes les requêtes de l'utilisateur sont effectuées par {\bf Display}, {\bf Build} ou {\bf Perform} ainsi que {\bf Interchange}. Ces commandes calculent l'enchaînement nécessaire à la construction cohérente de la ressource demandée ou à l'application correcte d'une règle. A un programme source donné peuvent naturellement correspondre plusieurs espaces de travail, contenant chacun des versions parallélisées différentes, obtenues par la sélection d'options de compilation différentes ou par l'application explicite de diverses transformations de programmes. \subsection{Notion de workspace} % programme ressource Pour travailler sur un code source, il faut donc commencer par créer un {\bf workspace}, composé de {\bf modules}. Plusieurs {\em workspaces} peuvent être créés à partir des mêmes fichiers sources, afin d'obtenir plusieurs versions d'analyses et de transformations d'un programme. Un {\bf module} correspond à une procédure du programme associé au workspace. \subsection{Notion de ressource et de requête} % pipsdbm, ressources, actions (ex création d'une ressource) Les {\bf ressources} sont des objets typés, qui correspondent à des structures de données. Chacune d'entre elles est stockée d'une manière permanente dans un fichier portant le même nom. Elles sont entièrement gérées par le {\em contrôleur de ressources}, qui permet de disposer des ressources sur disque comme en mémoire. Les ressources de chaque type sont produites lors de l'exécution d'une {\bf phase} particulière de PIPS, et sont relatives soit au programme tout entier, soit à un module particulier, qu'il s'agisse du programme principal, d'une procédure ou d'une fonction. % a une entité du {\em workspace} (dite {\em % owner}): PROGRAM pour le {\em programme}, MODULE pour le {\em module}, % CALLERS pour les modules {\em appelants} le module courant ou CALLEES % pour les modules {\em appelés} par le module courant. % Gestion de la base (ne rien faire en dehors de pips) Les ressources sont créées directement par une requête explicite de l'utilisateur, ou indirectement parce qu'elles s'avèrent nécessaires au calcul d'une autre ressource demandée, elle, explicitement. On peut considérer les requêtes essentielles comme une action sur la base de ressources. Afin de préserver la cohérence de cette base de ressources, il ne faut manipuler ces ressources qu'avec les utilitaires PIPS décrits dans cette notice: {\tt Display}, {\tt Build}, {\tt Perform}, {\tt Interchange} ainsi que {\tt Delete}. \subsection{Manipulations du workspace. Contrôleur de ressources} %% Etre explicite sur le controleur de ressources %% Donner dans Build et Perform l'explication de: %% Request: Build RESOURCE for module MODULE... %% Request: Perform RULE for module MODULE... Afin de minimiser le temps de calcul et de rendre PIPS interactif malgré son caractère interprocédural, les ressources ne sont construites qu'à la demande. A l'intérieur de {\tt Display}, {\tt Build}, {\tt Perform} et {\tt Interchange}, des mécanismes de type {\em make} enchaînent récursivement l'exécution de chaque règle (ie. chaque phase) requise au moment où les ressources dont elle a besoin ont été produites. Ces mécanismes s'appellent dans PIPS les contrôleurs de ressources (pipsmake). Cela assure aussi la réutilisation des ressources, dans la mesure où pour chaque règle les ressources produites sont postérieures aux ressources requises. \subsection{Analyses et Transformations} De nombreuses phases d'analyse et de transformation du programme peuvent être appliquées successivement, sans souci de la cohérence des enchaînements, qui est prise en charge par le contrôleur de ressources. Ainsi l'utilisateur peut-il se concentrer sur le travail où sa connaissance du programme est réellement utile. \section{Création d'un workspace: Init} \subsection{Environnement de PIPS} % repertoire, source lu seulement Pour utiliser PIPS, il faut pouvoir exécuter {\tt Init}, {\tt Build}, {\tt Perform} et {\tt Select}. Il convient d'ajouter à son path la directory où se trouvent ces shell-scripts et de définir quelques variables d'environnement. Pour cela, il suffit d'exécuter l'un des shell-scripts (selon votre shell usuel) fourni avec PIPS: {\tt . Pips/pipsrc.sh} (shell sh ou ksh) ou {\tt source Pips/pipsrc.csh} (shell csh ou tcsh). Si vous utilisez PIPS plusieurs fois, cette commande devrait être placée dans votre fichier d'initialisation du shell. Toutes ces commandes seront appelées depuis le répertoire où sont situés les fichiers sources du programme que vous voulez paralléliser. PIPS nécessite beaucoup de place à la fois en mémoire et sur disque. Assurez-vous que vous disposez d'une capacité suffisante avant de commencer une nouvelle session... \subsection{Init} % Utilisation, resultats Usage: {\bf Init workspace [file.f] ...} Pour créer un workspace de nom {\tt wspace} pour paralléliser les fichiers sources Fortran {\tt src1.f} et {\tt src2.f}, faire: {\tt \$ Init wspace src1.f src2.f} Les structures créées sont les suivantes: {\em wspace.schema} qui décrit la base de ressources, {\em wspace.database}, répertoire qui comprendra toute la base de ressources, chaque ressource étant un fichier; elle est initialisée avec les SOURCE\_FILE, correspondant au source de chacunes des procédures du programme (ou {\em modules}). Ces SOURCE\_FILEs sont dérivés, à l'aide de l'utilitaire {\em fsplit}, à partir de vos propres fichiers sources, qui sont aussi vus comme des ressources, dites USER\_FILE mais qui sont exceptionnellement en dehors du répertoire {\em wspace.database} et qui ne seront jamais modifiés. Chaque fichier SOURCE\_FILE ne contient donc qu'un unique module et prend comme nom le nom de ce module. Pour revenir à un workspace déjà existant, utiliser: {\tt \$ Init wspace} Si vous n'êtes pas seul à travailler dans un même répertoire, il vous faut spécifier votre workspace à chaque commande (option {\tt -w}). \subsection{Exemple} Soit le fichier matmul.f qui comprend les procédures mm et saxpy. Pour créer le programme mm1 à partir de ce fichier, placez-vous sous un répertoire qui contient matmul.f et tapez la commande: {\tt \$ Init mm1 matmul.f} Les messages qui notifient l'activité de PIPS sont nombreux afin de suivre les calculs réalisés. Remarquer simplement parmi ceux de la commande Init: \begin{verbatim} Spliting file matmul.f Module MM Module SAXPY \end{verbatim} Nous savons donc que les modules de mm1 sont MM et SAXPY (qui peuvent être spécifiés en lettres minuscules dans les commandes suivantes). Les fichiers créés sont {\tt mm1.schema}, {\tt mm1.database/mm.f} et {\tt mm1.database/saxpy.f} \subsection{Destruction d'un workspace: Delete} Afin de supprimer un workspace de nom wspace, il suffit de faire: {\tt Delete wspace} Noter que les sources réels du programme (ressources USER\_FILE) ne sont pas effacés par {\tt Delete}. \section{Affichage des résultats: Display} \subsection{Principe} La plupart des analyses et des transformations de programme produisent des résultats lisibles dans l'une des ressources PRINTED\_FILE ou PARALLELPRINTED\_FILE, construites avec les règles adéquates. Les transformations de code sont alors effectuées, et les analyses du code sont visibles en commentaire de ces fichiers Fortran. La fabrication des ressources et leur affichage est automatiquement réalisé par la commande {\tt Display}, qui exécute un appel à {\tt Build}. \subsection{Display} Usage: {\bf Display [-w wspace] [-m module] pretty-print} où les valeurs possibles de pretty-print sont: {\tt para code tran prec comp prop cumu cg cgl cgc para90 }, et la valeur par défaut est {\tt para}. Le workspace (resp. le module) courant est utilisé à moins qu'un nom ne soit spécifié par l'option {\tt -w} (resp. {\tt -m}). {\bf pretty-print} est une clé à laquelle sont associés des traitements PIPS qui aboutissent à la fabrication d'une ressource PRINTED\_FILE ou PRINT\_CALL\_GRAPH ou encore PARALLELPRINTED\_FILE; ces ressources sont des fichiers de texte qui permettent d'afficher les analyses et transformations de programme. \paragraph{PRINTED\_FILE} construit avec: \begin{itemize} \item{\tt code} donne le pretty-print de la représentation intermédiaire du module qu'utilise PIPS; \item{\tt tran} donne en plus l'analyse sémantique des transformers en commentaire; \item{\tt prec} fait de même avec les préconditions; \item{\tt comp} fait de même avec les complexités; \item{\tt prop} fait de même avec les effets propres; \item{\tt cumu} fait de même avec les effets cumules. \end{itemize} \paragraph{PRINT\_CALL\_GRAPH} construit avec: \begin{itemize} \item{\tt cg} affiche le graphe des appels \item{\tt cgl} donne en plus les boucles qui comprennent des appels \item{\tt cgc} fait de même avec les structures de contrôle. \end{itemize} \paragraph{PARALLELPRINTED\_FILE} construit avec: \begin{itemize} \item{\tt para} donne le pretty-print du code parallèle; \item{\tt para90} donne aussi le pretty-print du code parallèle, mais avec la notation Fortran 90. \end{itemize} La ressource construite est affichée sur le fichier de sortie standard stdout, alors que les messages informatifs sortent sur le fichier d'erreur standard stderr. \subsection{Exemple} Pour visualiser la version parallèle du module MM de mm1, taper: {\tt \$ Display -m mm} Toutes les phases doivent s'enchaîner pour construire la ressource \newline PARALLELPRINTED\_FILE du module MM. Finalement, on obtient: \begin{verbatim} Display of file mm1.database/MM.parf C C MATRIX MULTIPLICATION - VERSION WITH CALL TO SAXPY C C PARALLELIZATION OF LOOPS INCLUDING CALLS TO PROCEDURE C SUBROUTINE MM(N, A, B, C) C REAL*8 A(N,N), B(N,N), C(N,N), XAUX(0:127) C DOALL I = 1,N,1 PRIVATE I DOALL J = 1,N,1 PRIVATE J C(I,J) = 0.0 0006 ENDDO ENDDO C DOALL J = 1,N,1 PRIVATE J DO K = 1,N,1 PRIVATE K CALL SAXPY(N, C(1,J), A(1,K), B(K,J)) 0011 ENDDO ENDDO RETURN END \end{verbatim} Pour conserver dans le fichier mm1.mm.prec les préconditions de ce module, faire: {\tt \$ Display prec > mm1.mm.prec} Il faut noter que malgré sa grande utilité, la commande {\tt Display} ne permet pas de bénéficier de toute la puissance de PIPS. Aussi faut-il savoir recourir à {\tt Select} , {\tt Perform}, {\tt Build} et {\tt Interchange}. \section{Choix des options: Select} % Makefile reconfigurable Pour initialiser un {\em workspace}, il faut spécifier quelles sont les règles de construction des ressources. Une phase est une exécution d'une règle, et à chaque ressource est associée au moins une règle de production. Un exemple de règle par défaut est fourni dans le fichier {\tt \$LIBDIR/pipsmake.rc} \subsection{Fichier pipsmake.rc} Au premier appel de {\tt Build}, {\tt Perform} ou {\tt Select}, un fichier {\tt pipsmake.rc} est lu pour apprendre à PIPS les règles de production des ressources: celui du répertoire courant s'il existe, celui de {\tt \$LIBDIR} à défaut. Aussi pouvez-vous créer votre propre fichier d'initialisation de PIPS en copiant {\tt pipsmake.rc} et en le modifiant (voir la syntaxe de ce fichier en annexe {\em pipsmake}). Lorsque plusieurs règles sont disponibles dans {\tt pipsmake.rc} pour créer une même ressource, la première d'entre elles est sélectionnée. Une autre règle pourra être sélectionnée à la place de la première au moyen de la commande {\tt Select}. Une règle sélectionnée sera au besoin utilisée pour une phase afin de calculer une ressource requise. C'est là le principe du {\em make}. Une fois que {\tt pipsmake.rc} a été lu, il ne sera plus jamais utilisé pour ce workspace, puisqu'une représentation interne du pipsmake est conservée et tenue à jour pour chaque workspace. Elle est stockée dans le fichier {\tt wspace.pipsmake}. \subsection{Select} Usage: {\bf Select [-w wspace] rule [rule] ...} Le workspace courant est utilisé à moins qu'un nom ne soit spécifié par l'option {\tt -w}. Les règles à sélectionner sont spécifiables soit par un nom interne à PIPS \newline (ex. {\tt rice\_full\_dependence\_graph}), soit par un alias géré par le shell-script {\tt Build} (ex. {\tt rfulldg}). Voir l'annexe {\em alias}. \subsection{Exemple} Soit le programme {\tt choles.f}. Montrons qu'il est nécessaire de sélectionner la règle \newline {\tt rice\_full\_dependence\_graph} pour le paralléliser: {\tt \$ Init c2 choles.f} Un seul module: CHOLES. {\tt \$ Perform -m choles privatizer} Ainsi sont privatisées les variables pour lesquelles cette transformation est licite. {\tt \$ Display para >c2.para} %%on pourrait faire 2>/dev/null (...) mais ne marche pas sous csh ni tcsh Mais ce pretty-print n'est pas parallèle: \begin{verbatim} $ cat c2.para C C CHOLESKI METHOD - VERSION 1 C C PRIVATIZATION C DEPENDENCE COMPUTATION WITH AND WITHOUT EXECUTION CONTEXT C SUBROUTINE CHOLES(A, P, N) REAL X, A(N,N), P(N) C DO I = 1,N,1 PRIVATE I,KK,J,K,X X = A(I,I) 0004 DO K = 1,(I-1),1 PRIVATE K X = (X-(A(I,K)*A(I,K))) 0007 ENDDO P(I) = (1.0/SQRT(X)) 0008 DO J = (I+1),N,1 PRIVATE J,KK,X X = A(I,J) 0011 DO KK = 1,(I-1),1 PRIVATE KK X = (X-(A(I,J)*A(I,KK))) 0014 ENDDO A(J,I) = (X*P(I)) 0015 ENDDO ENDDO RETURN END \end{verbatim} Donc il convient de choisir une règle qui implémente un algorithme qui tienne compte des préconditions: {\tt \$ Select rfulldg} Ainsi la règle RICE\_FULL\_DEPENDENCE\_GRAPH est sélectionnée. {\tt \$ Display para >c2.para} Qui calcule une version effectivement parallèle: \begin{verbatim} $ cat c2.para C C CHOLESKI METHOD - VERSION 1 C C PRIVATIZATION C DEPENDENCE COMPUTATION WITH AND WITHOUT EXECUTION CONTEXT C SUBROUTINE CHOLES(A, P, N) REAL X, A(N,N), P(N) C DO I = 1,N,1 PRIVATE I,KK,J,K,X X = A(I,I) 0004 DO K = 1,(I-1),1 PRIVATE K X = (X-(A(I,K)*A(I,K))) 0007 ENDDO P(I) = (1.0/SQRT(X)) 0008 DOALL J = (I+1),N,1 PRIVATE J,KK,X X = A(I,J) 0011 DO KK = 1,(I-1),1 PRIVATE KK X = (X-(A(I,J)*A(I,KK))) 0014 ENDDO A(J,I) = (X*P(I)) 0015 ENDDO ENDDO RETURN END \end{verbatim} \subsection{Avertissement} Comme nous le constatons sur l'exemple précédent, certaines règles ne doivent pas être sélectionnées, mais appliquées. L'application consiste à demander l'exécution {\em immédiate} d'une règle spécifique; elle est toujours licite. Par contre, la sélection consiste à choisir la règle qui sera utilisée {\em ultérieurement} par défaut pour produire une ressource d'un certain type. Toutes les règles ne peuvent pas être sélectionnées, afin de ne pas introduire de cycle dans l'enchaînement des règles. Par exemple, la règle de nom {\tt distributer}, qui effectue la distribution de boucles, et la règle {\tt privatizer}, qui privatise les variables scalaires dans les boucles, produisent toutes deux la ressource {\tt CODE} à partir d'une ressource {\tt CODE} qui doit être déjà disponible pour le même module. Il faut donc que reste sélectionnée une autre règle qui produise initialement {\tt CODE} ({\tt link} par défaut). Cela ne serait plus vrai si l'on sélectionnait {\tt distributer} ou {\tt privatizer} (cf. section {\em Application d'une règle: Perform}). \section{Demande d'une ressource: Build} \subsection{Build} Usage: {\bf Build [-w wspace] [-m module] [-s selected\_rule[,selected\_rule]...] [-p performed\_rule] resource} Le workspace (resp. le module) courant est utilisé à moins qu'un nom ne soit spécifié par l'option {\tt -w} (resp. {\tt -m}). La règles et la ressource peuvent être spécifiées par leur vrai nom ou par un alias. Les alias sont généralement plus explicites mais aussi plus longs. Les règles {\tt selected\_rule} éventuellement spécifiées avec l'option -s sont sélectionnées (cf. {\em Select}). Ensuite la règle {\tt perform\_rule} éventuellement spécifiée avec l'option -p est appliquée (cf. {\em Perform}). Pour finir, la ressource {\tt resource} est calculée (build), à moins que ce ne soit une chaîne vide, auquel cas seuls le Select et le Perform sont effectués. Il faut remarquer qu'un effet équivalent à celui d'un Select ou d'un Perform peut être obtenu en utilisant des options de Build\footnote{En fait, Select et Perform font un appel à Build qui effectue les conversions et vérifications requises puis appelle les binaires nécessaires. De cette façon, les alias peuvent être modifiés dans Build et valoir pour les autres shell-scripts (cf. annexe {\em Alias}).}. \subsection{Application} Vous souhaitez une ressource qui ne soit pas visualisable à l'écran comme les effets d'une procédure ou un graphe de dépendance (cf. annexe {\em Base de ressources}). Pour l'obtenir, vous devez alors utiliser Build. Cela est utile à des fins de debug ou bien pour récupérer des résultats partiels à l'intention d'un autre logiciel. Le graphe de dépendance pourrait ainsi être réutilisé pour faire de l'ordonnancement d'instructions. \section{Application d'une règle: Perform} \subsection{Perform} Usage: {\bf Perform [-w wspace] [-m module] rule} Le workspace (resp. le module) courant est utilisé à moins qu'un nom ne soit spécifié par l'option {\tt -w} (resp. {\tt -m}). La règle rule peut être spécifiée par son nom vrai ou par son nom d'alias. Il est nécessaire d'appliquer explicitement les règles qui ne produisent pas diectement une ressource mais qui la modifie. C'est notamment le cas de {\tt distributer} et {\tt privatizer} pour la production de CODE. \subsection{Exemple} Voir la section Select. \section{Analyses} % chains et dg lost Les phases décrites ci-dessous sont celles pour lesquelles il est possible de choisir un algoritme en utilisant {\em Select}. Il s'agit du calcul des prédicats (les transformers et les préconditions) pour l'analyse sémantique, ainsi que du calcul du graphe de dépendance. Cf. rapport EMP-CAI-I E/137 pour plus de détails. \subsection{Transformers} Quatre algorithmes sont disponibles et leur distinction se fait sur deux critères: Ils sont plus ou moins précis et intra ou inter-procéduraux. Les règles associées à ces algorithmes sont: TransFormers\_intra\_fast (alias tf), TransFormers\_intra\_FULL (alias tffull), TransFormers\_INTER\_fast (alias tfinter) TransFormers\_INTER\_FULL (alias tfinterfull). \subsection{Préconditions} De manière similaire, les règles sont: PreConditions\_intra (alias pc),\newline PreConditions\_INTER\_fast (alias pcinter), PreConditions\_INTER\_FULL (alias pcinterfull). \subsection{Graphe de dépendance} Deux algorithmes sont disponibles: Rice\_fast\_Dependence\_Graph (alias rdg) et \newline Rice\_FULL\_Dependence\_Graph (alias rfulldg), qui prend en compte les prédicats. \section{Transformations du programme} \subsection{Privatisation de variables} Celle-ci est toujours réalisée pour les indices de boucle sans qu'elle soit demandée. Par contre il faut appliquer la règle {\tt PRIVatizer} (alias {\tt priv}) pour privatiser toutes les variables qui peuvent l'être, avant de demander la parallélisation, naturellement. \subsection{Distribution de boucles} Elle est réalisée en appliquant la règle {\tt DISTributer} (alias {\tt dist}). \subsection{Echange de boucles: Interchange} Cette transformation fait exception quant à son utilisation. Elle n'est pas appliquée avec Perform parce qu'il faut préciser le label de la boucle à échanger avec la boucle la plus interne du nid de boucle. Elle est accessible de cette interface par la commande {\bf Interchange} dont la syntaxe est: {\tt \$ Interchange [-w wspace] [-m module] label} Cette commande effectue l'équivalent de Perform d'une règle qui produirait la ressource CODE et enchaîne immédiatement un Display du pretty-print code. \subsubsection{Exemple} Soit le code initial de loop4.f: \begin{verbatim} program loop4 real t(10,10) real v(10,10) do 100 i = 1, 5 do 100 j = 1, i t(j+1,i)=t(j,i) + v(j,i) 100 continue end \end{verbatim} Pour obtenir l'inversion des deux boucles: \begin{verbatim} $ Init l4 loop4.f $ Interchange -m loop4 100 >l4.inv $ cat l4.inv PROGRAM LOOP4 REAL T(10,10) REAL V(10,10) DO 100 Ip = 1,5,1 0004 DO 100 Jp = Ip,5,1 0006 T((1+Ip),Jp) = (T(Ip,Jp)+V(Ip,Jp)) 0007 100 CONTINUE 0008 ENDDO ENDDO RETURN END \end{verbatim} % \subsubsection{Avertissement} % Il n'est pas vérifié que cette transformation est licite. Il convient % donc de l'appliquer en connaissance des effets. Pour plus de détails, % se référer au rapport EMP-CAI-I E/143. \subsection{Parallélisation de nid de boucles} C'est la transformation de programme par défaut; elle est obtenue en demandant {\tt Display [para]}, qui construit la ressource PARALLELPRINTED\_FILE. A la différence des transformations précédentes, celle-ci est élaborée à partir de la ressource PARALLELIZED\_CODE distincte de la ressource CODE à partir de laquelle elle a été construite. Elle peut donc être demandée implicitement. Ainsi, la parallélisation interprocédurale d'un module \verb+foo+ d'un programme Fortran \verb+bar+ contenu dans le fichier \verb+source.f+ se résume à: \begin{verbatim} $ Init bar-v1 source.f $ Display -m foo \end{verbatim} où \verb+bar-v1+ est la zone contenant la première version parallélisée du programme \verb+bar+. Une deuxième procédure, \verb+foofoo+, peut être ensuite traitée par une unique commande dans le même espace de travail \verb+bar-v1+: \begin{verbatim} $ Display -m foofoo \end{verbatim} à condition, bien sûr, que son code se soit trouvé dans votre fichier Fortran \verb+source.f+. \newpage \section*{Conclusion} PIPS est un paralléliseur interprocédural expérimental. La version décrite dans ce rapport est la première qui soit mise entre les mains d'utilisateurs extérieurs à l'Ecole des Mines. Il est vraisemblable que de nombreuses erreurs subsistent et nous vous sommes d'avance reconnaissant de nous les signaler. Néanmoins nous espérons que PIPS vous permettra d'obtenir des résultats intéressants en parallélisation interprocédurale. %\section{Récupération d'erreurs} %\section{Debug} \newpage \section*{Annexe 1: Installation de PIPS} La version initiale de PIPS est fournie pour stations et serveurs SUN4, exploités sous SUNOS~4.0.3. PIPS fonctionne avec 8~Mo de mémoire physique et 14~Mo d'espace {\em swap} pour de petits programmes, mais il faut disposer de plus d'espace de swap pour des programmes de plusieurs milliers de lignes, et si possible de plus de mémoire. La configuration utilisée à l'Ecole des Mines consiste en un SUN~4/260, 32~Mo de mémoire et 50~Mo d'espace de swap. Il faut: \begin{enumerate} \item effectuer un \verb+tar x Pips+ dans le répertoire où Pips doit être installé \item mettre à jour la variable shell PIPSDIR dans les fichiers {\tt pipsrc.sh} et {\tt pipsrc.csh} en fonction du répertoire qui a été choisi; il est préférable de lui donner un nom absolu; \item exécuter celui de ces deux fichiers qui correspond à l'analyseur de commande retenu (cf. section {\em Environnement de PIPS}) \end{enumerate} %%Preciser la structure de la cassette \newpage \section*{Annexe 2: Fortran PIPS} Le compilateur PIPS n'accepte pas l'ensemble du langage Fortran tel qu'il est défini dans la norme Fortran-77. Les restrictions et extensions qui lui ont été apportées sont définies et justifiées en détail dans le rapport EMP-CAI-I~E/103. Les restrictions essentielles au langage sont les suivantes: \begin{itemize} \item ENTRY \item BLOCKDATA \item ASSIGN et GOTO assigné \item RETURN multiple \item GOTO calculé \item opérateur substring // \item initialisation de type Hollerith \item le caractère {\em double quote} est prohibé comme dans la norme bien que de nombreux compilateurs acceptent un jeu de caractères plus grand que celui qui est spécifié dans la norme. \end{itemize} Ces restrictions peuvent être contournées en modifiant {\em syntaxiquement} le programme (voir le rapport EMP-CAI-I~E/103). Les mécanismes fondamentaux de Fortran sont bien tous traités par PIPS. Il n'est pas non plus possible d'utiliser la même chaîne de caractères pour un symbole global comme un nom de module ou de common et pour un symbole local comme un nom de variable ou de paramètre formel. Cette dernière restriction est une source d'erreurs quelques fois difficiles à comprendre. Il faut s'assurer que tous les modules sont explicitement nommés par une instruction \verb+PROGRAM+, \verb+SUBROUTINE+ ou \verb+FUNCTION+. Cela veut dire qu'il faut ajouter l'instruction: \begin{center} \begin{verbatim} PROGRAM MAIN \end{verbatim} \end{center} aux programmes principaux qui ne comprennent pas d'instructions \verb+PROGRAM+. Un nom plus évocateur que \verb+MAIN+ peut bien sûr être choisi. L'objectif n'étant pas d'écrire un compilateur commercial, les messages d'erreurs ne sont pas forcément très explicites. Il faut donc s'assurer au préalable que le programme soumis à PIPS est accepté par un compilateur conventionnel. Les options de compilation choisie devraient être aussi sévères que possible de manière à éliminer au maximum les extensions par rapport à la norme Fortran-77. \newpage \section*{Annexe 3: Messages d'erreur} De nombreux messages d'erreurs ou d'avertissement peuvent être émis par PIPS (fichier non existant, erreur de syntaxe, option inconnue, etc...). Les erreurs propres au compilateur provoquent volontairement un message {\em core dumped} de manière à pouvoir analyser ce qui s'est passé. \section*{Annexe 4: Erreurs connues} L'algorithme de parallélisation ne prend pas en compte les dépendances portant sur les {\em bornes} de boucles. Une distribution de boucle malencontreuse est parfois appliquée à des affectations de variables scalaires locales. Il faut essayer d'éliminer ces variables scalaires en remplaçant leurs occurences par leur expression d'initialisation. Le programme résultant est faux. L'algorithme de calcul des {\em use-def chains} crée de fausses dépendances sur des indices de boucle. Elles sont dues à l'utilisation d'un indice identique dans un DO implicite ou dans une expression de bornes d'autres boucles. Ce problème est facilement identifiable parce que l'indice de la boucle non parallélisée n'est pas déclaré {\tt PRIVATE.} Le programme résultant n'est pas optimal mais est correct. Ces deux comportements aberrants sont dus au calcul des effets des instructions. Nous n'avons pas encore trouvé une solution qui soit à la fois correcte et efficace. Les commentaires portant sur les instructions {\tt GOTO} et {\tt RETURN} sont perdus. Ceci est dû au traitement des {\tt RETURN} comme des {\tt GOTO} vers la fin de la procédure courante et à la conversion des {\tt GOTO} en arcs du graphe de contrôle. Il n'a pas été prévu de faire porter des commentaires par ces arcs. \newpage \section*{Annexe 5: Base de ressources} Les calculs effectués, la ressource sera disponible dans le fichier \newline {\tt wspace.database/MODULE.extension}. extension est en lettres majuscules s'il s'agit d'une ressource structurée pour PIPS (et correspond au nom de la ressource), et en lettres minuscules s'il s'agit d'une ressource construite par un pretty-printer (qui génère du code plus des commentaires). Les ressources structurées pour PIPS ne sont pas lisibles, et ne peuvent servir qu'à de futurs calculs dans la base. Parmi les pretty-prints, on aura les extensions {\tt f} pour le Fortran du SOURCE\_FILE, {\tt pref} pour le pretty-print du Fortran séquentiel, {\tt parf} pour le pretty-print du Fortran parallèle, {\tt pred} pour le pretty-print des prédicats. Pourtant, il est préférable d'utiliser la commande Display qui fournit une version toujours mise à jour du pretty-print requis. Les manipulation directes du workshpace sont à prohiber parce qu'elles risquent d'engendrer des incohérences entre la base et son schéma. \newpage \section*{Annexe 6: Contrôleur de ressources pipsmake} La syntaxe d'une règle du fichier pipsmake.rc est la suivante: \begin{verbatim} rule > OWNER.resource [> OWNER.resource]... [< OWNER.resource]... \end{verbatim} Ces règles ne doivent pas être modifiées, mais il est possible d'en changer l'ordre. Cf. rapport EMP-CAI-I~E/133 pour plus de détails. La manipulation directe du fichier \verb+pipsmake.rc+ est aussi à éviter. Tous les résultats souhaitables doivent pouvoir être obtenus à l'aide de la commande {\em Select}. \newpage \section*{Annexe 7: Alias} Les alias sont utilisables pour les règles et les ressources, dans chacun des arguments correspondants de Build, Perform et Select. Pourtant leur usage n'est jamais nécessaire (les noms de règles ou les ressources sont aussi valides). Les alias sont implémentés dans le shell-script de Build (présent dans {\tt \$UTILDIR/Build}), au moyen de la commande {\tt sed} de la fonction {\tt rename()}. Une ligne correspond à un alias, et la syntaxe est la suivante: {\tt s/alias\_name/true\_name/;} Lorsque l'alias\_name est une sous-chaîne d'un autre alias, il faut qu'il soit positionné après lui. %% Autres regles a preciser Chaque utilisateur peut donc redéfinir les alias, qui sont initialisés ainsi: % A chaque modification de lzone verbatim suivante, refaire M-x untabify % sur la region. \begin{verbatim} # resources s/PPF/ParallelPrinted_File/; \ s/CGF/CallGraph_File/; \ s/PF/Printed_File/; \ # rules for #dg s/rfulldg/Rice_FULL_Dependence_Graph/; \ s/rdg/Rice_fast_Dependence_Graph/; \ #transformers s/tffull/TransFormers_intra_FULL/; \ s/tfinterfull/TransFormers_INTER_FULL/; \ s/tfinter/TransFormers_INTER_fast/; \ s/tf/TransFormers_intra_fast/; \ #preconditions s/pcinterfull/PreConditions_INTER_FULL/; \ s/pcinter/PreConditions_INTER_fast/; \ s/pc/PreConditions_intra/; \ #callgraph_file s/prcgl/PRint_Call_Graph_with_Loops/; \ s/prcgc/PRint_Call_Graph_with_Control/; \ s/prcg/PRint_Call_Graph/; \ #printed_file s/prct/PRint_Code_Transformers/; \ s/prcpe/PRint_Code_Proper_Effects/; \ s/prcce/PRint_Code_Cumulated_Effects/; \ s/prcp/PRint_Code_Preconditions/; \ s/prcc/PRint_Code_Complexities/; \ s/prc/PRint_Code/; \ #Transformations to perform: s/dist/DISTributer/; \ s/priv/PRIVatizer/; \ \end{verbatim} \end{document}