"In compiler design, static single assignment form (often abbreviated as SSA form or SSA) is an intermediate representation (IR) in which every variable is assigned exactly once. Existing variables in the original IR are split into versions, new variables typically indicated by the original name with a subscript, so that every definition gets its own version. In SSA form, use-def chains are explicit and each contains a single element."
En gros c'est une analyse de flot light. Cela permet de faire pas mal d'optimisation intéressantes, mais on n'atteint pas une analyse de code logique
Dans une analyse de flot "profonde", l'ensemble du graphe du code est analysé. L'ensemble étant tous le code concerné pour la création du binaire. Cela suppose bien sûr d'accéder à la totalité du source.
Le compilateur possédant une représentation du code, il va pouvoir faire pas mal d'optimisation classique et moins classique. Classique, les propagations de contantes, suppression de code morts, renomage de registre, etc... Moins classique les analyses logique de code, comme la dérurcivation d'une récuricive, ou comme par exemple détecter qu'une variable entière est définie comme paire et que 10 km plus loin, on test son imparité, là le moteur logique peut supprimer ce test inutile.
Une personne que je connais bien a écris ce genre de chose, qui est difficilement utilisable dans le monde industriel car c'est très couteux en mémoire.
Réaliser un tel compilateur pose un problème : la taille de la grammaire. Plus celle-ci est grosse, plus l'optimisation et la taille du compilateur est difficile et imposante. En effet, l'optimisation se concentre sur la sémantique du code. Un test if..then...else, un while, un for, une résolution dynamique de message entre deux objets héritant d'un autre reviennent tous à la même sémantique : le test. Certains d'entre eux sont un peu cachés.
Une grosse grammaire implique pour les concepteurs du compilateur d'écrire une traduction sémantique de chacune des primitives... ce qui est un énorme travail.
Une bonne sémantique pour une bonne analyse de flot doit comporter au maximum une dizaine de primitives (test, <, =, &,*,/, -,...).
Le moteur logique de l 'analyse de flot détecte ensuite des pattern (des sous graphes assez court) et applique des règles transformant le graphe du code quand ces pattern sont détectés en association avec d'autres, je pense à l'exemple de test de parité dont je parlais plus haut.
L'augmentation de la taille de la mémoire disponible sur les machines de monsieur tout le monde va peut être permettre à terme d'aller vers l'utilisation de ce genre de compilateur qui ont le gros défaut d'être exponentiels (mais on peut toujours finasser...). On pourrait aussi imaginer de descendre encore plus bas dans la sémantique, comme par exemple se restreindre aux portes {et,ou, non} ce qui permettrait des optimisations assez halucinantes mais qui implique aussi des modèles de processeurs totalement différents puisqu'ils seraient bit à bits.
Bref, d'intéressantes perpectives...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Houla, forcément, si on fait un icc -Ox uniquement...
Posté par Ontologia (site web personnel) . En réponse au journal Benchmarks de GCC 4.1. Évalué à 10.
"In compiler design, static single assignment form (often abbreviated as SSA form or SSA) is an intermediate representation (IR) in which every variable is assigned exactly once. Existing variables in the original IR are split into versions, new variables typically indicated by the original name with a subscript, so that every definition gets its own version. In SSA form, use-def chains are explicit and each contains a single element."
En gros c'est une analyse de flot light. Cela permet de faire pas mal d'optimisation intéressantes, mais on n'atteint pas une analyse de code logique
Dans une analyse de flot "profonde", l'ensemble du graphe du code est analysé. L'ensemble étant tous le code concerné pour la création du binaire. Cela suppose bien sûr d'accéder à la totalité du source.
Le compilateur possédant une représentation du code, il va pouvoir faire pas mal d'optimisation classique et moins classique. Classique, les propagations de contantes, suppression de code morts, renomage de registre, etc... Moins classique les analyses logique de code, comme la dérurcivation d'une récuricive, ou comme par exemple détecter qu'une variable entière est définie comme paire et que 10 km plus loin, on test son imparité, là le moteur logique peut supprimer ce test inutile.
Une personne que je connais bien a écris ce genre de chose, qui est difficilement utilisable dans le monde industriel car c'est très couteux en mémoire.
Réaliser un tel compilateur pose un problème : la taille de la grammaire. Plus celle-ci est grosse, plus l'optimisation et la taille du compilateur est difficile et imposante. En effet, l'optimisation se concentre sur la sémantique du code. Un test if..then...else, un while, un for, une résolution dynamique de message entre deux objets héritant d'un autre reviennent tous à la même sémantique : le test. Certains d'entre eux sont un peu cachés.
Une grosse grammaire implique pour les concepteurs du compilateur d'écrire une traduction sémantique de chacune des primitives... ce qui est un énorme travail.
Une bonne sémantique pour une bonne analyse de flot doit comporter au maximum une dizaine de primitives (test, <, =, &,*,/, -,...).
Le moteur logique de l 'analyse de flot détecte ensuite des pattern (des sous graphes assez court) et applique des règles transformant le graphe du code quand ces pattern sont détectés en association avec d'autres, je pense à l'exemple de test de parité dont je parlais plus haut.
L'augmentation de la taille de la mémoire disponible sur les machines de monsieur tout le monde va peut être permettre à terme d'aller vers l'utilisation de ce genre de compilateur qui ont le gros défaut d'être exponentiels (mais on peut toujours finasser...). On pourrait aussi imaginer de descendre encore plus bas dans la sémantique, comme par exemple se restreindre aux portes {et,ou, non} ce qui permettrait des optimisations assez halucinantes mais qui implique aussi des modèles de processeurs totalement différents puisqu'ils seraient bit à bits.
Bref, d'intéressantes perpectives...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker