Code intermédiaire

Analyse sémantique (un peu)
Code intermédiaire.

Les phases « sémantiques »

Elle reposent sur la sémantique du langage et s'effectue sur l'arbre de syntaxe abstraite.

Une seule phase réellement indispensable : la génération de code.
En pratique, bien d'autres phases :
- Vérification (synthèse) des types.
- Emploi des noms (pas de doublon des fonctions en Pseudo-Pascal), incluses dans le typage le plus souvent.
- Optimisations de « haut-niveau ».

Toutes ces phases ont en commun de suivre la sémantique des noms.

Portée lexicale

let x = "coucou" in x ^ (let x = 1 in string_of_int (x+1)) ^ x)

Conséquence à l'évaluation :

créer une liason entre x et "coucou", pour évaluer x ^,
créer une liaison entre x et 1 pour évaluer string_of_int (x+1),
retrouver la première liaison pour évaluer ^ x.

Ou encore :

string_of_int (x+1) est évalué dans un environnement où x vaut 1.
x ^ et ^ x sont évalués dans un environnement où x vaut "coucou".

Tables d'associations impératives

Comme les tableaux, les indices sont quelconques.

Nous avons besoin :

get : string -> 'a. Pour accéder aux valeurs des variables.
set : string -> 'a -> 'a option. Pour mettre à jour la valeur d'une variable (renvoie l'ancienne valeur).
restore : string -> 'a option -> unit. Pour remettre une ancienne valeur.

let eval = function | Var x -> get x | Let (x, ex, e) -> let vx = eval ex in let old_vx = set x vx in let ve = eval e in restore x old_vx ; ve

Réalisation, par les tables de hachage bien sûr

exception Free of string let env = Hashtbl create 17 let get x = try Hashtbl.find env x with Not_found -> raise (Free x) let set x v = let old_v = try Some (get x) with Free _ -> None in Hashtbl.replace env x v ; old_v let restore x old_v = match old_v with | None -> Hashtbl.remove env x (* détruire la liaison de x *) | Some v -> Hashtbl.replace env x v (* restaurer la liaison de x *)

Associations fonctionelles

Le style impératif est peu sûr (on a vite fait d'oublier un restore).

On souhaite adopter le style de la sémantique avec un environnement passé en argument.

let rec eval env = function | Var x -> get env x | Let (x, ex, e) -> let vx = eval env ex in eval (extend x vx env) e | ...

Plutôt que des tables d'associations, on veut des associations tout court.

Réalisation naïve

Avec des listes bien sûr.

(* On pourrait utiliser List.assoc qui fait la même chose *) let rec get x env = match env with | [] -> raise (Free x) | (y,v)::rem -> if x=y then v else get x rem let extend x v env = (x,v)::env

Noter que les liaisons sont cachées et non plus détruites.

get devient innefficace pour les environnements sont un peu grands.

Réalisation efficace

(* Module des chaînes ordonnées *) module OrderedString = struct type t = string let compare s1 s2 = Pervasive.compare s1 s2 (* ordre standard *) end (* Application du foncteur => associations aux chaînes *) module StringMap = Map.Make OrderedString let get x env = try StringMap.find x env with Not_found -> raise (Free x) let extend x v env = StringMap.add x v env

Catégories (ou espaces) de noms

Diverses entitées sont nommées (presque) indépendamment.

Pseudo-Pascal : fonctions et variables.
Java : classes, méthodes, variables.
C : fonctions, variables, étiquettes d'enregistrements etc. (toutefois, interdiction de mélanger fonctions et variables de même nom).

À l'usage, c'est le contexte (syntaxique) qui détermine les espaces de noms :

f() ¬ ∼f := ...

Réalisation par des enregistrements, une association par catégorie.

Interface des environnements en Pseudo-Pascal

type ('a, 'b) environment exception VarNotFound of string val find_var : ('a,'b) environment -> string -> 'a val find_definition : ('a,'b) environment -> string -> 'b val create_global : (string * 'a) list -> (string * 'b) list -> ('a,'b) environment val add_local_vars : ('a,'b) environment -> (string * 'a) list -> ('a,'b) environment val change_local_vars : ('a,'b) environment -> (string * 'a) list -> ('a,'b) environment

Environnements lors de l'exécution

Les noms des variables n'existent plus. Les variables sont des cases :

Des cases mémoire.
Des registres machine.

Dans le cas traditionnel :

Une fonction : l'adresse de son code (étiquette quand même).
Une variables globale : une case dans le segment statique de données.
Une variable locale : une case dans la pile.
Un paramètre : une case dans la pile.

L'allocation en pile provient de la récursivité : les variables (locales) appartiennent aux appels.

Chaque appel possède une tranche (un frame) de pile. Il accède aux variables par le fond (fp), et dispose du sommet à sa guise (sp).

Organisation traditionelle de la pile

Séquence d'appel traditionelle

L'appelant empile les paramètres effectifs (et une place pour ranger la valeur de retour).
L'appelant exécute une instruction d'appel de sous-routine.
L'appelé empile le registre fp, puis copie sp dans fp.
L'appelé alloue l'espace nécessaire aux variables locales.
L'appelé s'exécute. il doit rendre sp comme en 4.
L'appelé rend l'espace de pile des variables locales.
Il dépile dans fp, qui retrouve sa valeur de l'étape 1.
Instruction de retour (pop and branch).
L'appelant dépile les arguments par lui empilés au début.

Méthode moderne

Il y a bien un frame par appel. Mais...

On peut se passer de fp, si
- Pas d'allocation arbitraire en pile (alloca).
- Compilation un peu plus complexe acceptée.
- Pas d'interaction avec un debugger.
Surtout : les paramètres et variables locales peuvent être en registres (fixés au passage d'arguments pour les premiers).

Conséquence pour la compilation
On ne choisit pas tout de suite si les variables locales vont en registre ou en pile.

Pour le moment, les variables locales sont des « temporaires ». C'est un premier exemple d'une construction de code dit « intermédiaire ».

Pourquoi un code intermédiaire?

Partage du travail

Entre plusieurs langages, et plusieurs machines

Java

C

...

Caml

Ocaml
⎫
⎪
⎬
⎪
⎭

CI
⎧
⎪
⎨
⎪
⎩

MIPS

xx86

...

Sparc

Byte-code
Entre les différentes constructions d'une même langage ou d'une même machine
- La syntaxe abstraite comporte trop de constructions voisines
- Le code assembleur comporte trop d'instructions voisines

Le principe du code intermédiaire

Le code intermédiaire est celui d'une machine idéale.

Les détails dépendant de l'architecture sont relégués à une phase ultérieure de sélection d'instructions.

Quelques caractéristiques du code intermédiaire:

Les branchements sont explicites.
Code arborescent (expressions) ou linéaire (instructions)
Utilise une infinité de registres (temporaires), dont l'utilisation est privilégiée (réversible) et le coût négligé.
L'adressage en mémoire est une forme séparée qui n'est retenue que lorsque c'est indispensable (irréversible).
L'appel de fonction reste dans le flou, et sera résolu dans une phase ultérieure. (il depend lourdement du processeur ciblé)

Notre code intermédiaire

Expressions (en arbre)

type exp = Const of int (* Entiers et Booléens *) | Name of Gen.label (* Adresse mémoire nommée *) | Temp of Gen.temp (* Lecture d'un temporaire *) | Mem of exp (* Lecture mémoire *) | Bin of binop * exp * exp (* Opération binaire *) | Call of Frame.frame * exp list (* Appel de fonction ou appel système *)

Note Données dans le code intermédiare

Les temporaires Gen.temp
Les étiquettes Gen.label
Les fonctions Frame.frame

Instructions (à plat ou presque)

and stm = | Label of Gen.label (* Étiquette (dans le code) *) | Move_temp of Gen.temp * exp (* Écriture dans un temporaire *) | Move_mem of exp * exp (* Écriture en mémoire *) | Seq of stm list (* Séquence d'instructions *) | Exp of exp (* Expression évaluée pour son effet *) | Jump of Gen.label (* Saut non conditionnel *) | Cjump of (* Saut conditionnel *) relop * exp * exp * (* - Comparaison *) Gen.label * Gen.label (* - si vrai/si faux *)

Noter les modules de « service » (Gen et Frame).

Compiler vers le code intermédiaire

Une phase en trois passes

Principe :

La première passe (simple) introduit des innefficacités, ou fait le travail à moitié.
Les suivantes (générales) corrigent.

Avantages : Robustesses, modularité, généralité.

Les temporaires

« Sémantique »

Les temporaires ne sont pas tout à fait des registres, car...
Les appels de fonction ne modifient pas leur contenu.
Comme : les variables locales des fonctions récursives.
Il revient aux phases suivantes de réaliser leur sémantique, avec les moyens de la vraie machine.

Interface (module Gen)

type temp val new_temp : unit -> Gen.temp

Génération de code, cas simples

Fonctions [[ _ ]]_ρ^e (expressions) et [[ _ ]]_ρ^s (instructions).

Cas de bases (simples).
[[Int n]]_ρ^e = Const n [[Bool true]]_ρ^e = Const 1 [[Bool false]]_ρ^e = Const 0
Étapes inductives (simples).

[[Bin (op, e₁, e₂)]]_ρ^e = Bin (op, [[e₁]]_ρ^e, [[e₂]]_ρ^e)

[[Sequence (s₁; …; s_n)]]_ρ^s = Seq [[[s₁]]_ρ^s; …; [[s_n]]_ρ^s]

Tableaux (pourrait être bien plus compliqué).

[[`Geti` (e₁, e₂)]]_ρ^e	=
`Mem` (`Bin` (`Plus` , [[e₁]]_ρ^e, `Bin` (`Times` , `Const` w, [[e₂]]_ρ^e)))
[[`Seti` (e₁, e₂, e₃)]]_ρ^s	=
`Move_mem` (`Bin` (`Plus` , [[e₁]]_ρ^e, `Bin` (`Times` , `Const` w, [[e₂]]_ρ^e)), [[e₃]]_ρ^e)

Conditionnelle

Test direct (<, ≤, etc.)

[[If (Bin (relop, e₁, e₂), s_t, s_f)]]_ρ^s =

Seq

⎡
⎢
⎢
⎢
⎣

Cjump (relop, [[e₁]]_ρ^e, [[e₂]]_ρ^e, l_t, l_f);

Label l_t; [[s_t]]_ρ^s; Jump fi;

Label l_f; [[s_f]]_ρ^s; Jump fi;

Label fi;

⎤
⎥
⎥
⎥
⎦

Sinon, à la C :

[[If (e₁, s_t, s_f)]]_ρ^s = [[If (Bin (Ne , e₁, Const 0), s_t, s_f)]]_ρ^s

Noter les étiquettes sont « fraîches » (obtenues par Gen.new_label).

La boucle while est similaire.

[[While (Bin (relop, e₁, e₂), s_l)]]_ρ^s =

Seq

⎡
⎢
⎢
⎢
⎣

Label test;

Cjump (relop, [[e₁]]_ρ^e, [[e₂]]_ρ^e, loop, fi);

Label loop; [[s_l]]_ρ^s; Jump test;

Label fi;

⎤
⎥
⎥
⎥
⎦

Les variables

Les environnements associent les noms des variables à, ...

un temporaire t,

[[Get x]]_ρ^e = Temp t

[[Set (x, e)]]_ρ^s = Move_temp (t, [[e]]_ρ^e)
une adresse mémoire a,

[[Get x]]_ρ^e = Mem a

[[Set (x, e)]]_ρ^s = Move_mem (a, [[e]]_ρ^e)
un frame F (représentation ad-hoc des fonctions)

[[Procedure_call (f, [ e₁ ; … ; e_n ])]]_ρ^s = Exp (Call (F, [ [[e₁]]_ρ^e ; … ; [[e_n]]_ρ^e ]))

[[Function_call (f, [ e₁ ; … ; e_n ])]]_ρ^e = Call (F, [ [[e₁]]_ρ^e ; … ; [[e_n]]_ρ^e ])

Fabriquer les environnents

Dans le cas simple de Pseudo-Pascal.

La i-ième variable globale est rangée en mémoire, d'adresse :
Plus (Const (w*(i−1)), Name l_globals)
Autrement dit les variables globales sont en mémoire à la queue-leu-leu. L'adresse de cette zone est une étiquette définie dans le module Frame. On peut aussi décider qu'un registre Frame.global_register est réservé pour contenir cette adresse.
Plus (Const (w*(i−1)), Temp r_globals)
Les autres variables (variables locales, arguments) sont des temporaires.
Les noms de fonction sont associés à une structure ad-hoc, nommée frames.

En pratique

Le type générique des environnements (module Env) est :

type ('a, 'b) environment

Les environnements utilisés pour compiler Pseudo-Pascal :

(case, Frame.frame) environment

Où case est du style :

type case = | Tempo of Gen.temp (* La variable est un temporaire *) | Memoire of Code.expr (* La variable est en mémoire *)

Introduction des temporaires

Un temporaire « frais » pour chaque variable locale. (ie. un temporaire obtenu par un appel à Gen.new_temp).
Un temporaire par paramètre formel (et pour le résultat).
- Pour ne pas dépendre des conventions d'appel à ce niveau.
- Pour donner une chance d'aller en registre.

Les frames (représentation des fonctions) contiennent la liste des temporaires représentant leurs paramètres (et leur résultat éventuel).

Les frames (enfin)

C'est un point de rendez-vous dans tout le back-end.

type frame = { name : Gen.label; (* Point d'entrée (prologue) *) return_label : Gen.label; (* Adresse de l'épilogue *) args : Gen.temp list; (* Temporaire des arguments *) result : Gen.temp option; (* Temporaire du résultat (ou rien) *) mutable mysize : int; (* Taille nécessaire sur la pile *) }

Mais le type des frames est abstrait, dans frame.mli, on aura la déclaration : type frame. En effet

Le type frame peut changer (machine ciblée, langage compilé).
Il est compliqué.

Interface (fichier frame.mli)

type frame (* Création *) val named_frame : string -> Pp.var_list -> Pp.type_expr option -> frame (* Accéder aux informations *) val frame_name : frame -> label val frame_args : frame -> temp list val frame_result : frame -> temp option val frame_return : frame -> label

Compilation des programmes

Compiler une fonction
En deux étapes.

Créer le frame.
Compiler le corps :
- Fabriquer le bon environnement.
- Compiler le corps (une liste d'instructions) dans cet environnement.

val cfun : (access, Frame.frame) Env.environment -> string * Pp.definition -> Frame.frame * Code.stm

Compiler un programme
En quatre étapes :

Fabriquer tous les frames (à cause des appels potentiellement récursifs).
Fabriquer un environnement initial.
Ajouter une fonction « principale ».
Compiler toutes les fonctions.

type 'a procedure = Frame.frame * 'a type 'a program = { number_of_globals : int; main : 'a procedure; procedures : 'a procedure list } val program : Pp.program -> Code.stm program

Code intermédiaire, deuxième partie

Notre code n'est pas encore prêt pour la phase suivante (la séléction).
On peut optimiser le contrôle (e.g éviter des sauts inutiles).

Notre code n'est pas prêt

En première approximation, notre code est prêt pour la sélection si sa traduction en code assembleur est simple et indépendante de l'ordre d'évaluation des expressions.

On veut une liste d'instructions (supprimer les Seq ).
On veut des sauts conditionnels raisonables.
Cjump (relop, e₁, e₂, l_T, l_F) ; Label l_F
Mais surtout, les expressions sont des arbres trop génériques.

Pouvoir de la sélection

Il est souhaitable que les expressions soient des arbres.

Move (t₀, Bin (Plus , e₁, e₂))

Est selectionnable de au moins deux façons :

Code qui calcule e₁ dans r

Code qui calcule e₂ dans r

Code qui calcule e₂ dans r'

Code qui calcule e₁ dans r'

⇓

t₀ ← r+r'

À quoi bon ? Par exemple, bonne utilisation des registres.

N(e₁ + e₂) =

⎧
⎨
⎩

max(N(e₁), N(e₂))		Si N(e₁) ≠ N(e₂)
N(e₁) + 1		Sinon

À condition de mettre en premier l'argument de N(e_i) maximal.

Sélection

Bin (Plus , Bin (Plus , Temp t₁, Const 2), Bin (Plus , Temp t₂, Const 1))

Peut donner lieu à deux selections

add t₃, t₁, 2 add t₄, t₂, 1 add t₅, t₃, t₄

add t₃, t₂, 1 add t₄, t₁, 2 add t₅, t₃, t₄

On peut laisser la sélection décider : il n'y aucune implication sémantique.

Sélection, autre exemple

Bin (Plus , Call (f,[e₁]), Call (g, [e₂]))

On ne peut pas laisser la sélection décider : les deux choix ont des sémantiques différentes (effets de bords dans les fonctions).

Comment s'en tirer :

Ne pas (trop) spécifier l'ordre d'évaluation : une idée discutable.
- Le résultat des programmes mal-écrits n'est pas intuitif.
- Des programes optimisés/non optimisés peuvent donner des résultats différents.
- C'est pas moderne.
Tenir compte de l'ordre d'évaluation dans la sélection : une mauvaise idée.
- C'est compliqué.
- La sélection dépendrait alors du langage compilé !

Plus grave, la compilation des appels imbriqués

Call (f, Call (g, e₁), Call (h, e₂))

Ici c'est grave, la selection la plus naïve est incorrecte.

`a0` ← e₁	#	argument de g
`call` g	#	le résultat de g...
`a0` ← `v0`	#	est le premier argument de f.
`a0` ← e₂	#	argument de h
…	#

Notons qu'il est possible de s'en tirer dans la selection.

`a0` ← e₁	#	argument de g
`call` g	#	le résultat de g...
`t0` ← `v0`	#	« sauver » le premier argument de f.
`a0` ← e₂	#	argument de h
`call` h	#
`a0` ← `t0`	#	premier argument de f
`a1` ← `v0`	#	second argument de f
`call` f	#

Une fois de plus, c'est compliqué (et dupliqué dans chaque sélecteur).

Une solution définitive et modulaire

Avant la sélection, le code est « canonisé ».

Le code canonique est un code intermédiaire contraint :

Il n'y a pas d'instructions Seq.
Et surtout : les appels de fonctions sont contraints.
Move (t, Call (f, …)) Exp (Call (f, …))
Idée : quelque soit la sélection des expressions, l'ordre d'évaluation est préservé.
Il suffit de respecter l'ordre des instructions.

Un example de canonisation

Seq [Move (t₀, Bin (Plus , Call (f,e₁), Call (g, (Call (h, e₂))))) ; …]

Se canonise en :

Move (t₁, e₁)

Move (t₂, Call (f, Temp t₁))

Move (t₃, e₂)

Move (t₄, Call (h, Temp t₃))

Move (t₅, Call (g, Temp t₄))

Move (t₀, Bin (Plus , Temp t₁, Temp t₅))

…

Décrire la canonisation : l'arme absolue

Règle (de réécriture) e → s ⊕ c. Une expression e se réduit un code s et une expression résiduelle c canoniques.

Const _ → ⊕ Const _ Temp _ → ⊕ Temp _ Name _ → ⊕ Name _

e → s ⊕ c

Mem e → s ⊕ Mem c

e₁ → s₁ ⊕ c₁ e₂ → s₂ ⊕ c₂

Bin (op, e₁, e₂) → s₁ ; Move (t, c₁) ; s₂ ⊕ Bin (op, Temp t, c₂)

e₁ → s₁ ⊕ c₁ ⋯ e_n → s_n ⊕ c_n

Call (f,[e₁ ; … ; e_n]) → s₁ ; Move (t₁, c₁) ; … ; s_n ; Move (t_n, c_n) ;Move (t_n+1, Call (f,[Temp t₁ ; … ; Temp t_n])) ⊕ Temp t_n+1

Arme absolue II

L'instruction s se canonise en la liste d'instructions s' (s → s').

s₁ → s'₁ ⋯ s_n → s'_n

Seq [s₁ ; … s_n] → s'₁ ; ⋯ ; s'_n

e → s ⊕ c

Move (t, e) → s ; Move (t, c)

e₁ → s₁ ⊕ c₁ e₂ → s₂ ⊕ c₂

Move_mem (e₁, e₂) → s₁ ; Move (t,c₁) ; s₂ ; Move_mem (t, c₂)

e₁ → s₁ ⊕ c₁ e₂ → s₂ ⊕ c₂

Cjump (relop, e₁, e₂, l_T, l_F) → s₁ ; Move (t,c₁) ; s₂ ; Cjump (relop, t, c₂, l_T, l_F)

On peut éviter quelques transferts:

e → s ⊕ c

Move (t, Call (f, e)) → s ; Move (t, Call (f, c))

Bref, on met à plat les Seq et on canonise les expressions.

Une arme trop puissante

Move (t₀, Bin (Plus , Bin (Mult , Temp t₁, Const 4), Const 7))

Se canonise en :

Move (t', Bin (Mult , Temp t₁, Const 4))

Move (t₀, Bin (Plus , Temp t', Const 7))

Et c'est bien domage car certains processeurs peuvent selectionner une seule instruction.

leal 7(,t₁,4), t₀

Donc, on cherche à garder des expressions en arbre le plus possible.

Commutation

Informellement, deux expressions commutent si on peut les évaluer n'importe comment sans mettre la sémantique en danger.

Alors la règle suivante semble correcte.

e₁ → s₁ ⊕ c₁ e₂ → s₂ ⊕ c₂

e₁ et e₂ commutent

Bin (op, e₁, e₂) → s₁ ; s₂ ⊕ Bin (op, c₁, c₂)

Si on réfléchit à la correction :

c₁ et c₂ commutent toujours (voir les règles).
On veut seulement évaluer c₁ après s₂, la sémantique commandant le contraire.

e₁ → s₁ ⊕ c₁ e₂ → s₂ ⊕ c₂

c₁ et s₂ commutent

Bin (op, e₁, e₂) → s₁ ; s₂ ⊕ Bin (op, c₁, c₂)

Exemples de commutation

On se pose donc la question de savoir si évaluer c₁ avant ou après s₂ est indifférent.

Si c₁ est une constante ? s₂ quelconque.
Si c₁ est un temporaire t ? s₂ n'écrit pas dans t.
Si c₁ est Bin (op, e₁, e₂) ? s₂ commute avec e₁ et e₂.
Si c₁ est un appel de fonction ? C'est un piège, c₁ est canonique.

Comment généraliser ?

On commute si c₁ ne lit pas « ce qui » est écrit par s₂ :
temporaires,
et mémoire.

Autres occurences de la commutation

Par exemple, pour l'écriture en mémoire :

e₁ → s₁ ⊕ c₁ e₂ → s₂ ⊕ c₂

c₁ et s₂ commutent

Move_mem (e₁, e₂) → s₁ ; s₂ ; Move_mem (c₁, c₂)

Et surtout pour les arguments des fonctions :

[ ] → ⊕ [ ]

e₁ → s₁ ⊕ c₁ [e₂ ; ⋯ ; e_n] → s ⊕ [c₂ ; ⋯ ; c_n]

[e₁ ; e₂ ; ⋯ ; e_n] → s₁ ; Move (t₁, c₁) ; s ⊕ [t₁ ; c₂ ; ⋯ c_n]

e₁ → s₁ ⊕ c₁ [e₂ ; ⋯ ; e_n] → s ⊕ [c₂ ; ⋯ ; c_n]

c₁ et s commutent

[e₁ ; e₂ ; ⋯ ; e_n] → s₁ ; s ⊕ [c₁ ; c₂ ; ⋯ c_n]

Se débarasser du Cjump bi-étiquette

Facile, à l'aide d'une fenêtre se déplaçant sur le code. (Procédé « trou de serrure » ou peephole).

`Jump` l ; `Label` l	→	`Label` l
`Cjump` (relop, e₁, e₂, l_t, l_f) ; `Label` l_f	→	`Cjump` (relop, e₁, e₂, l_t, l_f) ; `Label` l_f
`Cjump` (relop, e₁, e₂, l_t, l_f) ; `Label` l_t	→	`Cjump` (¬ relop, e₁, e₂, l_f, l_t) ; `Label` l_t
`Cjump` (relop, e₁, e₂, l_t, l_f)	→	`Cjump` (relop, e₁, e₂, l_t, l) ; `Label` l; `Jump` l_f

Bien, mais on voudrait aussi, quand c'est possible :

Jump l ; Label l →

C'est possible quand l n'apparaît pas dans le code.

Optimisation du contrôle

Le code à plat s'y prête très mal. (Même si le Cjmp bi-étiquette explicite la totalité du contrôle).

On transforme le code en « graphe de flot ».

Les sommets sont des blocs de bases (basic blocks).
Des suites (maximales) d'instructions ne contenant ni étiquettes ni saut.
Il y a un arc de b₁ à b₂ si b₁ se termine par un saut (possible) vers le début de b₁.
Il y une entrée (un arc partant de rien) et une (des) sortie (un arc n'allant nulle part).

Structures de données pour le graphe flot

Les sommets du graphe : des blocs de base.

type basic_block = {enter:Gen.label ; (* Étiquette d'entrée *) mutable succ:stm ; (* Dernière instruction (un saut) *) body:stm list ;} (* Instructions du bloc *)

La liste des blocs suffit pour représenter le graphe de flot.

Par souci d'efficacité, on ajoute une association étiquette → bloc.

type graph = basic_block list * (Gen.label, basic_block) Hashtbl.t let get_block (_,t) l = Hashtbl.find t l

Exemple de graphe de flot

Le code :

Label test; Cjump (relop, [[e₁]]_ρ^e, [[e₂]]_ρ^e, loop, fi);

Label loop; … ; Jump test;

Label fi;

Le graphe :

Application du graphe de flot

On compile l'instruction :

If (Bin (op₁, e₁, e₂), s_t, If (op₂, e₃, e₄, s_ft, s_ff))

Le code :

Label start ; Cjump (op₁, _, _, l_t, l_f);

Label l_t; … ; Jump fi₁;

Label l_f;

Cjump (op₂, _, _, l_ft, l_ff) ;

Label l_ft; … ; Jump fi₂

Label l_ff; … ; Jump fi₂

Label fi₂

Jump fi₁;

Label fi₁;

Deux graphes équivalents

Optimisation du contrôle

Principe

Transformer le code (d'une fonction) en graphe de flot.
Transformer le graphe.
Transformer le graphe en code (et appliquer le trou de serrure).

Deux optimisation simples

Court-circuiter les blocs vides.
Éviter les sauts vers les sauts.
Identifier le code mort.
Supprimer du code inutile (cosmétique).

Court-circuit, en pratique

Court-circuiter une étiquette

let rec shorten_lab (_,t) lab = try let b = Hashtb.find t lab in match b with | {body=[]; succ=Jump olab} -> shorten_lab t olab | _ -> lab with | Not_found -> lab

Ne fonctionne pas toujours !

Boucle en cas de bloc vide bouclant sur lui-même.

Traiter un (les) bloc(s)

let shorten_block t b = match b.succ with | Jump lab -> b.succ <- Jump (shorten_lab t lab) | Cjump (op,e1,e2,lab1,lab2) -> b.succ <- Cjump (op, e1, e2, shorten_lab t lab1, shorten_lab t lab2) | _ -> assert false let shorten_blocks (blocks,t) = List.iter (shorten_block t) blocks, t

Pour identifier le code mort :

Un bête parcours de graphe (puis un filtrage de la liste de blocs).

Encore plus fort

Modifier l'ordre de présentation des blocs, pour optimiser.

Sur le graphe de la boucle :

⇒

Code initial :

Label test; Cjump (relop, _, _, loop, fi);

Label loop; … ; Jump test;

Label fi;

Code final :

Jump test; Label loop; … ; Jump test;

Label test; Cjump (relop, _, _, loop, fi);

Label fi;

Est-ce bien utile ? Hum.

De plus en plus fort

Dans un graphe arbitraire, retrouver une structure de boucle imbriquée cachée (goto...).

Assez dur en pratique. Dommage.

Organisation de nos optimisations

On ne touchera pas à l'ordre des blocs (ne pas détruire la structure du code, déjà convenable, en voulant faire mieux).

Couper en blocs de base.
Produire le graphe.
Court-cicuiter les blocs vides.
Éliminer les blocs de code mort.
Fusionner le code des blocs mis bout-à bout.

Optimisations « trou de serrure » (peephole) et mise en place des test-and-branch style machine à la fin.

`Jump` l ; `Label` l	→	`Label` l
`Cjump` (relop, e₁, e₂, l_t, l_f) ; `Label` l_f	→	`Cjump` (relop, e₁, e₂, l_t, l_f) ; `Label` l_f
`Cjump` (relop, e₁, e₂, l_t, l_f) ; `Label` l_t	→	`Cjump` (¬ relop, e₁, e₂, l_f, l_t) ; `Label` l_t
`Cjump` (relop, e₁, e₂, l_t, l_f)	→	`Cjump` (relop, e₁, e₂, l_t, l) ; `Label` l; `Jump` l_f

Les projets

Voir la page du cours. Modifications de notre compilateur zyva.

Recibler pour le Pentium.
Produire un système à bytecode.
Ajouter le passage par variable puis les fonctions locales.
votre projet

Ce document a été traduit de L^AT_EX par H^EV^EA

Analyse sémantique (un peu) Code intermédiaire.

Les phases « sémantiques »

Portée lexicale

Tables d'associations impératives

Réalisation, par les tables de hachage bien sûr

Associations fonctionelles

Réalisation naïve

Réalisation efficace

Catégories (ou espaces) de noms

Interface des environnements en Pseudo-Pascal

Environnements lors de l'exécution

Organisation traditionelle de la pile

Séquence d'appel traditionelle

Méthode moderne

Pourquoi un code intermédiaire?

Le principe du code intermédiaire

Notre code intermédiaire

Compiler vers le code intermédiaire

Les temporaires

Génération de code, cas simples

Conditionnelle

Les variables

Fabriquer les environnents

En pratique

Introduction des temporaires

Les frames (enfin)

Compilation des programmes

Code intermédiaire, deuxième partie

Notre code n'est pas prêt

Pouvoir de la sélection

Sélection

Sélection, autre exemple

Plus grave, la compilation des appels imbriqués

Une solution définitive et modulaire

Un example de canonisation

Décrire la canonisation : l'arme absolue

Arme absolue II

Une arme trop puissante

Commutation

Exemples de commutation

Autres occurences de la commutation

Se débarasser du Cjump bi-étiquette

Optimisation du contrôle

Structures de données pour le graphe flot

Exemple de graphe de flot

Application du graphe de flot

Deux graphes équivalents

Optimisation du contrôle

Court-circuit, en pratique

Encore plus fort

De plus en plus fort

Organisation de nos optimisations

Les projets

Analyse sémantique (un peu)
Code intermédiaire.