On comprend vite que sur un programme ou sous-programme non-trivial, la combinatoire est explosive.
Pas moi en tout cas : sur ton exemple, on a 3 blocs de codes, et 3 noeuds et 6 arcs, en O(2*n) en fonction du nombre de ligne de code au pire, linéaire donc.
Si ce schéma est imbriquée dans d'autres structures, il ne sera pas reproduit dans mon idée des graphes de flots en tout cas.
bloc A'
while ( cond1) do
/* Ton bloc if */
done
bloc B'
ca rajoute deux noeuds, 3 arcs, c'est tout.
Je vois donc pas ce qui peut êxploser de ce côté, sauf si il y a reproduction de ces structures quand ce sont des fonctions, genre inlining en C++.
Donc je crois pas que le graphe en soit bouffe tant d'espace.
L'analyse de flot, qui est censée traiter tous les chemins possibles c'est évidemment différent. Dites moi si (où sûrement ;) ) je me trompes.
[^] # Re: Compilation lente <=> Analyse de flot
Posté par thoasm . En réponse à la dépêche Lancement du projet GlobalGCC. Évalué à 2.
Pas moi en tout cas : sur ton exemple, on a 3 blocs de codes, et 3 noeuds et 6 arcs, en O(2*n) en fonction du nombre de ligne de code au pire, linéaire donc.
Si ce schéma est imbriquée dans d'autres structures, il ne sera pas reproduit dans mon idée des graphes de flots en tout cas.
bloc A'
while ( cond1) do
/* Ton bloc if */
done
bloc B'
ca rajoute deux noeuds, 3 arcs, c'est tout.
Je vois donc pas ce qui peut êxploser de ce côté, sauf si il y a reproduction de ces structures quand ce sont des fonctions, genre inlining en C++.
Donc je crois pas que le graphe en soit bouffe tant d'espace.
L'analyse de flot, qui est censée traiter tous les chemins possibles c'est évidemment différent. Dites moi si (où sûrement ;) ) je me trompes.