Pour la création de cette bibliothèque en OCaml nous avons dans un pre- mier temps développé un analyseur lexical et syntaxique permettant d’ac- cepter un fichier au format de la SMT-LIB 2 natif. Nous l’avons ensuite étendu pour y ajouter notre extension de syntaxe. Il nous a suffi pour cela de modifier la grammaire pour que les expressions paramétrables acceptent la syntaxe précédemment présentée. Notre parser traite les commandes au format SMT-LIB 2 les unes après les autres. Nous créons alors un AST re- présentant la liste des commandes du fichier d’entrée au format SMT-LIB 2.
Pour notre vérificateur de type, nous nous sommes tout d’abord pen- chés sur la déclaration de la logique utilisée. Tel qu’expliqué auparavant, la déclaration de la logique utilisée va nous permettre d’ajouter dans notre en- vironnement de typage ses types et fonctions. Les différentes théories gérées par le standard ont été présentées dans l’état de l’art. Les fonctions et types déclarés par les théories sont ajoutés à notre environnement de typage en accord avec les règles présentées précédemment. Une fois la définition des logiques traitées, nous avons fait de même pour les autres commandes du standard en respectant notre système de type.
Cette bibliothèque, appelée psmt2-frontend1 permet donc de lire et vé-
rifier les types d’une partie du standard de la SMT-LIB 2 avec une extension polymorphe. En effet tout le standard de la SMT-LIB 2 n’est pas géré ac- tuellement par cette bibliothèque. Nous ne nous sommes penchés que sur les commandes que nous avons présentées dans ce document. Nous ne sup- portons pas l’ensemble de théories du standard comme les théories des bit- vecteurs et des flottants. Le but était d’obtenir rapidement une bibliothèque permettant de gérer le format SMT-LIB 2 polymorphe dans Alt-Ergo.
2.2 Intégration à Alt-Ergo
Une fois notre bibliothèque développée, nous avons pu brancher l’AST typé qu’elle génère dans Alt-Ergo comme représenté sur la figure 5.14. Du fait qu’au moment où nous avons développé le frontend, Alt-Ergo utilisait la phase de typage pour calculer les triggers des termes quantifiés, nous avons
AST parsé
AST parsé AST typé Fichier smt2 Fichier ae Typecheker + triggers Parsing Parsing Structures de données hashconsé Vers le backend Hashconsing AST typé Psmt2- frontend Alt-ergo frontend
Figure 5.14 – Architecture du branchement de psmt2-frontend à Alt-Ergo.
dû nous brancher sur l’AST non typé de celui-ci. À partir de notre AST typé du fichier smt2 nous générons un AST parsé dans Alt-Ergo. Alt-Ergo étant un solveur de logique du premier ordre, il fait une différence stricte entre les termes et les formules (contrairement à SMT-LIB 2), nous avons dû effectuer quelques modifications pour pouvoir générer un AST au format d’Alt-Ergo. Cette différenciation amène Alt-Ergo à générer deux types de fonctions,
lespredicate, qui retournent une proposition de logique du premier ordre,
et leslogic qui sont des fonctions pouvant retourner tout autre type. Pre-
nons par exemple l’exemple suivant : (<= (f (or A B)) c). (or A B) va être interprété comme une formule par Alt-Ergo, or il n’est pas possible de déclarer une formule au sein d’un terme, ici (f (or A B)). Pour résoudre ce problème il a fallu abstraire les formules contenues dans les termes par des variables booléennes fraîches. Nous avons utilisé pour cela des let-in. Avec une telle abstraction nous obtenons (let ((fresh_b (or A B))) (<= (f fresh_b) c)) pour l’exemple précédent.
Ces abstractions nous ont aussi permis d’étendre le support des if-then-else et des let-in d’Alt-Ergo pour pouvoir supporter toute forme de ces expres- sions comme par exemple (<= x (ite (A or B) 1 (+ y 2))). Ces abstrac- tions pouvant être effectuées au typage cela nous permet de contourner les spécificités d’Alt-Ergo sans pour autant modifier toutes les structures et rai- sonnements internes de ce dernier, comme les structures qvec du partage (hashconsing) du backend représentant les termes, littéraux et formules.
Bien que notre travail diffère peu d’un point de vue syntaxe et typage du travail de Bonichon et al [16], il diffère complètement concernant le raisonne- ment modulo polymorphisme. En effet, comme présenté dans l’état de l’art, Alt-Ergo a été conçu pour supporter nativement le polymorphisme au sein du moteur d’instanciation. Le raccordement de l’aspect polymorphe de notre frontend à Alt-Ergo s’est donc fait de façon triviale. Aucun solveur SMT à notre connaissance ne sait faire cela aujourd’hui. Des expériences ont été menées dans CVC4 mais sans succès pour l’instant.
3. Résultats expérimentaux 113
3
Résultats expérimentaux
Alt-Ergo supportant maintenant partiellement le standard SMT-LIB 2 avec une extension polymorphique de celle-ci, nous avons souhaité pouvoir montrer l’avantage de traiter des fichiers utilisant du polymorphisme ainsi que son traitement natif par le solveur. Pour cela il nous a fallu générer un ensemble de bancs de tests contenant des fichiers au format psmt2, notre format SMT-LIB 2 avec polymorphisme. Nous présenterons comment l’outil Why3 nous a permis de générer nos jeux de tests. Puis, nous présenterons les résultats concernant l’impact du polymorphisme sur les performances de notre solveur. Enfin nous pourrons comparer Alt-Ergo avec d’autres solveurs SMT sur des fichiers d’entrée identiques.
Les fichiers que nous avons utilisés sont des problèmes fournis en partie par nos partenaires industriels comme les fichiers du banc d’essai SPARK [48] qui proviennent de la société AdaCore. Les exemples de la catégorie EACSL proviennent de fichiers C du projet “EACSL by Exemple” de Fraunhofer Fokus. Les quatre catégories BWARE [35] proviennent de projet industriels ayant été pré-traités par l’Atelier-B [21, 53]. DAB et RCS3 ont été fournis par Mitsubishi Electric R&D Centre Europe tandis que la société ClearSy a fourni les catégories P9 et P4. Enfin, nous utilisons aussi les fichiers issus de la galerie de vérification de programmes de Why3.
En ce qui concerne les spécifications techniques, nous avons utilisé comme pour les résultats expérimentaux précédents la plate-forme Starexec. Là en- core, nous utiliserons une limite de temps de 60 secondes et une limite de consommation mémoire de 2 Go.