Analyse du flux de données avec exceptions

L'analyse du flux de données fonctionne sur un graphique de flux de contrôle. Lorsqu'un langage considéré prend en charge les exceptions, le graphique du flux de contrôle peut exploser.

Quelles sont les techniques standard pour faire face à cette explosion? Pouvons-nous ignorer les bords induits par exception? Les analyses de flux de données calculent de toute façon des sur-approximations, nous nous retrouverions donc avec une solution moins précise mais saine. Est-ce vrai?

Mise à jour : Voici quelques liens utiles que j'ai pu découvrir à la fin:

programming-languages program-optimization software-verification

— bellpeace
source

Qu'entendez-vous par "exploser"? Savons-nous statiquement quelles exceptions peuvent être levées où? Quel type d'augmentation de taille seriez-vous prêt à accepter?

— Raphael

Par exploser, je veux dire que le nombre de blocs de base est augmenté et le nombre de bords les reliant, ce qui entraîne des temps d'exécution de l'analyse potentiellement plus élevés. Mon hypothèse, peut-être erronée, était que cela pourrait être un problème dans les compilateurs et qu'il existe peut-être un moyen de le résoudre. Je suis intéressé à comprendre le sujet.

— bellpeace

Ignorer les exceptions n'est pas valable. Exemple:

let g = {
     raise E;
}
let f = {
     x := interesting_stuff();
     g();
     x := 0;
}

Lors de l'analyse f, vous devez prendre en compte le fait que gdéclenche une exception, sinon vous concluriez à tort que xc'est toujours 0 au retour de f.

Je ne sais pas s'il existe une technique «standard» pour traiter les exceptions. Il y a de la littérature sur le sujet, je n'ai aucune idée de quels articles sont pertinents que je peux trouver par une recherche Google.

Formellement, les exceptions peuvent être transformées en instructions conditionnelles qui se propagent dans la chaîne d'appels, ce qui fait bien sûr exploser le graphique du flux de contrôle. Dans de nombreux cas concrets, le cas d'exception est le cas le moins intéressant, où beaucoup de données sont tuées, donc elles doivent être traitées paresseusement dans une approche directe (pas besoin d'analyser la vivacité sur le chemin d'exception si le gestionnaire tue les données) .

— Gilles 'SO- arrête d'être méchant'
source

Une question de suivi, si cela ne vous dérange pas. Essentiellement, si je manque des bords, je peux obtenir un résultat non fiable. Que se passe-t-il si j'ai des bords codant le flux de contrôle qui ne sont en fait pas affichés lors de l'exécution du programme? Aurais-je un résultat solide, mais potentiellement moins précis?

— bellpeace

@bellpeace Si un bord correspond à un chemin qui n'est jamais emprunté pendant l'exécution, c'est du code mort, il peut donc être supprimé sans affecter la solidité. Le résultat serait plus précis: vous avez une meilleure approximation du programme, donc vous pouvez obtenir une meilleure approximation de son comportement.

— Gilles 'SO- arrête d'être méchant'

Donc, essentiellement, l'ajout de bords supplémentaires n'affectera pas la solidité mais uniquement la précision?

— bellpeace

@bellpeace Oui: si vous ajoutez des chemins potentiels, vous pourriez introduire de nouveaux flux potentiels qui ne peuvent pas réellement se produire, mais vous n'effacerez aucun flux qui se produit.

— Gilles 'SO- arrête d'être méchant'

Attendez, dans cet exemple, x est toujours nul au retour de f. Si g lève une exception, f ne revient pas. Maintenant, si f a pris l'exception (et peut-être repensé), ce serait une question différente, mais ce serait un bord explicite dans le graphique de flux.

— Pseudonyme