Les compilateurs offrent un excellent compromis entre le temps de développement et les performances de l'application. Actuellement l'efficacité de leurs optimisations reste limitée lorsque les architectures cibles sont des multi-cœurs ou si les applications demandent des calculs intensifs. Il est difficile de prendre en compte les nombreuses configurations existantes et les nombreux paramètres inconnus à la compilation et donc disponibles uniquement pendant l'exécution. En se basant sur les techniques de compilation polyédrique, nous proposons deux solutions complémentaires pour contribuer au traitement de ces problèmes. Dans une première partie, nous présentons une technique automatique à la fois statique et dynamique permettant d'optimiser les boucles des programmes en utilisant les possibilités offertes par l'auto-tuning dynamique. Cette solution entièrement automatique explore de nombreuses versions et sélectionne les plus pertinentes à la compilation. Le choix de la version à exécuter se fait dynamiquement avec un faible surcoût grâce à la génération de versions interchangeables: un ensemble de transformations autorisant le passage d'une version à une autre du programme tout en faisant du calcul utile. Dans une seconde partie, nous offrons à l'utilisateur une nouvelle façon d'interagir avec le compilateur polyédrique. Afin de comprendre et de modifier les transformations faites par l'optimiseur, nous traduisons depuis la représentation polyédrique utilisée en interne n'importe quelle transformation de boucles impactant l’ordonnancement des itérations en une séquence de transformations syntaxiques équivalente. Celle-ci est compréhensible et modifiable par les programmeurs. En offrant la possibilité au développeur d'examiner, modifier, améliorer, rejouer et de construire des optimisations complexes avec ces outils de compilation semi-automatiques, nous ouvrons une boîte noire du compilateur: celle de la plateforme de compilation polyédrique. / Compilers usually offer a good trade-off between productivity and single thread performance thanks to a wide range of available automatic optimizations. However, they are still fragile when addressing computation intensive parts of applications in the context of parallel architectures with deep memory hierarchies that are now omnipresent. The recent shift to multicore architectures for desktop and embedded systems as well as the emergence of cloud computing is raising the problem of the impact of the execution context on performance. Firstly, we present a static-dynamic compiler optimization technique that generates loop-based programs with dynamic auto-tuning capabilities with very low overhead. Our strategy introduces switchable scheduling, a family of program transformations that allows to switch between optimized versions while always processing useful computation. We present both the technique to generate self-adaptive programs based on switchable scheduling and experimental evidence of their ability to sustain high-performance in a dynamic environment.Secondly, we propose a novel approach which aims at opening the polyhedral compilation engines that are powering loop-level optimization and parallelization frameworks of several modern compilers.Building on the state-of-the-art polyhedral representation of programs, we present ways to translate comprehensible syntactic transformation sequences to and from the internal polyhedral compiler abstractions. This new way to interact with high-level optimization frameworks provides an invaluable feedback to programmers with the ability to design, replay or refine loop-level compiler optimizations.

Le langage APL a été défini en 1962 par K.E. Iverson dans un ouvrage intitulé " A Programming Language " [Iverson62]. En dépit des difficultés nouvelles que ce langage posait aux concepteurs, des interprètes APL furent rapidement disponibles chez I.B.M. [Chomat71, Iverson73]. Ce langage s'étant d'emblée révélé intéressant pour toutes les applications réclamant plus de programmation que de longs calculs, plusieurs systèmes virent le jour chez d'autres constructeurs [Martin72, Girardot76]. Réalisés pour la plupart sur de gros ordinateurs, ils réclament des ressources hors de proportion avec les moyens habituels mis à la disposition des ingénieurs ou des étudiants. Parallèlement de nombreux travaux de recherche ont été menés afin d'accélérer l'interprétation du langage. P.S. Abrams fut le premier à introduire certaines notions fondamentales d'optimisation comme le beating devenu classique de nos jours. Il a également envisagé la construction d'un matériel muni d'un code machine très voisin du langage APL [Abrams70]. D'autres approches ont consisté à réaliser un maximum de fonctions au niveau matériel, en microprogrammant un sous-interprète scalaire ou vectoriel, et en rédigeant ensuite, dans l'APL restreint ainsi obtenu, l'interprète complet. L'étude des divers systèmes existants montre que les architectures purement logicielles, utilisant presque toujours une technique d'interprétation naïve sont les plus répandues. Cependant, même si les architectures sont restées identiques, l'évolution des techniques d'implantation a permis des progrès considérables. De fait, il semble assez difficile de progresser beaucoup dans une voie purement logicielle si ce n'est par des approches radicalement différentes comme celles décrites dans [Hewlett77]. Ce système APL réalisé sur HP 3000 est en fait un compilateur incrémental générant pour chaque ligne de code qu'il exécute pour la première fois, un fragment de code machine. , Une signature associée à ce code permet de savoir ultérieurement si la réutilisation de ce code est possible.

Le compilateur de parties opératives Apollon qui est présenté dans cette thèse, génère automatiquement le dessin des masques de parties opératives de circuits VLSI de type microprocesseur à partir d'une description comportementale de niveau transfert de registres constituée d'un ensemble non ordonné d'instructions opératives. Une instruction opérative est formée d'un ensemble d'actions opératives dont le format est prédéfini (transferts - opérations unaires ou binaires et entrées-sorties) devant se dérouler en parallèle en au plus deux cycles opératifs. Un cycle opératif comprend 4 phases qui correspondent aux 4 phases d'exécution d'un transfert entre 2 registres. Apollon est basé sur un modèle dérivé de la partie opérative du MC68000. Ce modèle fournit à la fois: un modèle architectural: la partie opérative est formée d'un ensemble de sous parties opératives alignées à deux bus qui traversent tous les éléments d'une sous partie opérative; un modèle temporel: une opération prend 2 cycles, un transfert un seul; un modèle électrique: les bus sont complémentés et à précharge; un modèle topologique: le plan de masse est basé sur la structure en tranches appelée communément bis slice. Le compilateur génère d'abord l'architecture de la partie opérative, puis les spécification des masques à partir de cette architecture. Pour générer l'architecture de la partie opérative en un temps raisonnable, le compilateur doit recourir à des heuristiques. Pour générer le dessin des masques, le compilateur utilise l'assembleur de silicium Lubrick qui permet d'assembler et de connecter automatiquement les cellules de base des éléments fonctionnels de la partie opérative. Les spécifications des masques sont générées à partir des spécifications des cellules prédéfinies d'une bibliothèque NMOS.

La présente étude s'insère dans le domaine de la sûreté de fonctionnement et se veut être une aide à la conception d'un calculateur tolérant des pannes. Plus précisément nous nous intéresserons à la prise en compte de quatre paramètres : la sécurité, la fiabilité, la performance et le coût de ce calculateur

.

.

.

.

.

.