Analisi e Verifica di Programmi Laboratorio di AVP Corso di Laurea in Informatica AA 2004-05 Tino Cortesi.

Presentazione sul tema: "Analisi e Verifica di Programmi Laboratorio di AVP Corso di Laurea in Informatica AA 2004-05 Tino Cortesi."— Transcript della presentazione:

1 Analisi e Verifica di Programmi Laboratorio di AVP Corso di Laurea in Informatica AA 2004-05 Tino Cortesi

2 Analisi e Verifica di Programmi 2 Analisi e Verifica Cosa Individuare proprietà interessanti dei nostri programmi: Valori prodotti, dipendenze, uso, terminazione Perché: Verifica, Debugging Type checking Verifica di asserzioni Ottimizzazioni: Compile time garbage collection Ottimizzazioni source-to-source Come Le proprietà non banali dei programmi sono indecidibili o computazionalmente molto costose (NP) Approssimazioni o condizioni sufficienti

3 Tino CortesiAnalisi e Verifica di Programmi 3 Guyana francese, 4 giugno 1996 $600 miliardi di dollari bruciati per un errore del software

4 Tino CortesiAnalisi e Verifica di Programmi 4 Marte, 3 dicembre 1999 Crashed due to uninitialized variable

5 Tino CortesiAnalisi e Verifica di Programmi 5 Sillabo del corso Introduzione Interpretazione Astratta Correttezza dellanalisi - Connessioni di Galois - Widening Domini astratti per lanalisi di linguaggi dichiarativi Domini astratti per lanalisi di linguaggi ad oggetti Dataflow Analysis Liveness Analysis Reaching Definitions - Constant Folding - Available Expressions Basic Blocks - Value Numbering - Alias Analysis Loop Optimizations Model Checking Type Systems

6 Tino CortesiAnalisi e Verifica di Programmi 6 Bibliografia F.Nielson, H.R.Nielson, C. Hankin Principles of Static Analysis Springer Verlag, 1999 A. W. Appel Modern Compiler Implementation in Java Cambridge Univ. Press, 1998 Steven Mucknick Compiler Design Implementation Morgan Kaufmann Publ., 1997 Articoli su journals o proceedings di conferenze

7 Introduzione

8 Tino CortesiAnalisi e Verifica di Programmi 8 Analisi Metodo conoscitivo che procede dallindividuazione e dallo studio dei particolari Scomposizione di un tutto organico nelle sue parti

9 Tino CortesiAnalisi e Verifica di Programmi 9 Analisi di Programmi Tecniche automatiche per inferire a tempo di compilazione informazione approssimata sul comportamento run-time dei programmi Applicazioni: Ottimizzazione di compilatori Verifica automatica dei programmi Certificazione - validazione del software Sicurezza

10 Tino CortesiAnalisi e Verifica di Programmi 10 Etichettatura input n; m:=2; while n>1 do m:= m * n; n:= n-1; output m; (1) input n; (2) m:=2; while (3) n>1 do (4) m:= m * n; (5) n:= n-1; (6) output m;

11 Tino CortesiAnalisi e Verifica di Programmi 11 Grafo di flusso (1) input n; (2) m:=2; while (3) n>1 do (4) m:= m * n; (5) n:= n-1; (6) output m; input n m:= 2 n > 1 m:= m*n n:= n-1 output m 1 2 3 6 4 5

12 Tino CortesiAnalisi e Verifica di Programmi 12 Possiamo inferire mediante analisi statica che al punto (6) il valore della variabile m sarà pari per qualsiasi valore di input n. Per fare questo lanalisi dovrà propagare parity information Possiamo assegnare ad ogni variabile uno dei tre valori: Pariil valore è sicuramente pari Dispari il valore è sicuramente dispari Non_Soil valore può essere pari oppure dispari input n m:= 2 n > 1 m:= m*n n:= n-1 output m 1 2 3 6 4 5

13 Tino CortesiAnalisi e Verifica di Programmi 13 (1) input n; (2) m:= 2; while (3) n>1 do (4) m:= m * n; (5) n:= n - 1; (6) output m; (1) n Non_So m Non_So (2) n Non_So m Non_So (3) n Non_So m Pari (4) n Non_So m Pari (5) n Non_So m Pari (6) n Non_So m Pari

14 Tino CortesiAnalisi e Verifica di Programmi 14 Questo programma, dato un intero positivo n, calcola il doppio del fattoriale: 2 * (n!) n=1 … loutput è 2 n=2 … loutput è 4 n=3 … loutput è 12 n=4 … loutput è 48 pari! (1) input n; (2) m:= 2; while (3) n>1 do (4) m:= m * n; (5) n:= n - 1; (6) output m;

15 Tino CortesiAnalisi e Verifica di Programmi 15 Questo programma, dato un intero positivo n, calcola il fattoriale: n! In questo caso lanalisi precedente non restituisce nessuna informazione utile sulla parità di m. Questo è corretto (per n=1…) Ma nemmeno se restringiamo linput a n pari e n>1 lanalisi è precisa: in (3) sia n che m sono Non_So. (1) input n; (2) m:= 1; while (3) n>1 do (4) m:= m * n; (5) n:= n - 1; (6) output m;

16 Tino CortesiAnalisi e Verifica di Programmi 16 Precisione e Correttezza Questa perdita di precisione è una caratteristica comune delle tecniche di analisi statica La maggior parte delle proprietà sui programmi che si vogliono inferire sono indecidibili (o NP-complete), quindi non possiamo pensare di inferirle con precisione (ed in tempi ragionevoli) Dobbiamo assicurarci che il risultato dellanalisi sia in ogni caso corretto: Se lanalisi dice SI allora sicuramente la proprietà è verificata Se lanalisi dice NO allora può darsi che la proprietà non sia verificata

17 Tino CortesiAnalisi e Verifica di Programmi 17 Esempio Sappiamo che il problema della terminazione è indecidibile (halting problem) programmi programmi che terminano

18 Tino CortesiAnalisi e Verifica di Programmi 18 programmi programmi che sicuramente terminano programmi che terminano programmi che potrebbero terminare

19 Tino CortesiAnalisi e Verifica di Programmi 19 Precisione e Correttezza Unanalisi di terminazione può essere quindi di due tipi: Definite SIil programma sicuramente termina NOil programma potrebbe non terminare Possible SIil programma può terminare NOil programma sicuramente non termina

20 Tino CortesiAnalisi e Verifica di Programmi 20 Precisione e Correttezza Le tecniche di analisi che introdurremo si dicono semantics-based. Questo significa che linformazione ottenuta dallanalisi può essere dimostrata corretta rispetto alla semantica del linguaggio di programmazione

21 Tino CortesiAnalisi e Verifica di Programmi 21 Compilatori ottimizzanti Un compilatore ottimizzante trasforma un programma per migliorare la sua efficienza senza modificarne loutput. Trasformazioni che migliorano lefficienza: Allocazione dei registri Eliminazione delle sotto-espressioni comuni: se una espressione viene calcolata più di una volta, elimina le ripetizioni Eliminazione di dead-code: cancella una computazione il cui risultato non viene mai usato Constant folding: se gli operandi di unespressione sono costanti, il calcolo può essere fatto a tempo di compilazione.

22 Tino CortesiAnalisi e Verifica di Programmi 22 Escape Analysis Consideriamo queste due procedure in C: typedef int A[10000]; typedef A* B; void esegui1(){ int i; B b; b = (A*) malloc(sizeof(A)); for (i=0; i<100; i++) (*b)[i]=0; free(b); } void esegui2(){ int i; A a; for (i=0; i<100; i++) a[i]=0; }

23 Tino CortesiAnalisi e Verifica di Programmi 23 typedef int A[10000]; typedef A* B; void esegui1(){ int i; B b; b = (A*) malloc(sizeof(A)); for (i=0; i<100; i++) (*b)[i]=0; free(b); } B b int i ambiente stack memoria heap 0 Larray viene allocato nello heap e poi eliminato...

24 Tino CortesiAnalisi e Verifica di Programmi 24 A a int i ambiente stack memoria heap typedef int A[10000]; void esegui2(){ int i; A a; for (i=0; i<100; i++) a[i]=0; } Larray viene allocato nello stack e poi eliminato... 0

25 Tino CortesiAnalisi e Verifica di Programmi 25 allocare nello heap costa... for (i=0; i<1000000; i++) esegui1(); // circa 90 sec for (i=0; i<1000000; i++) esegui2();// circa 35 sec I programmi sembrano uguali, ma lallocazione nello heap fa sì che il primo sia tre volte più lento del secondo... Se riesco a predire che una variabile dinamica non esce dalla procedura dovè introdotta, posso sostituirla con una variabile locale.

26 Tino CortesiAnalisi e Verifica di Programmi 26 Esiste il compilatore ottimo? Definiamo fully optimizing compiler un compilatore che trasforma un programma P nel programma Opt(P) che è il più piccolo programma con lo stesso output di P. Dato un programma Q che non produce nessun output e non termina, Opt(Q) è facile da trovare: è il programma L1: goto L1; Supponiamo di avere un fully optimizing compiler. Potremmo usarlo per risolvere il problema della terminazione: per vedere se esiste un input per il quale P termina, basta vedere se Opt(P) è il programma L1: goto L1; Ma sappiamo che il problema della terminazione è indecidibile, ovvero che non esiste nessun algoritmo che lo risolve. Quindi non può esistere nemmeno un fully optimizing compiler.

27 Tino CortesiAnalisi e Verifica di Programmi 27 Ottimizzazione del codice Control-Flow Analysis Analisi Trasformazioni Idea: anziché chiedere al programmatore di preoccuparsi dellefficienza del programma, si può demandare a un compilatore ottimizzanti la trasformazione di un codice inefficiente in uno (equivalente) con performances migliori

28 Tino CortesiAnalisi e Verifica di Programmi 28 Trasformazioni ottimizzanti Le trasformazioni che un compilatore ottimizzante può operare seguono principalmente la seguente metodologia: Analisi: attraversa il grafo di flusso del programma e raccogli informazioni su cosa può succedere a tempo si esecuzione Trasformazioni: modifica il programma per renderlo in qualche modo più veloce. Linformazione ottenuta dallanalisi garantisce che il risultato del nuovo programma è uguale a quello del programma originario

29 Tino CortesiAnalisi e Verifica di Programmi 29 Tecniche di Analisi Statica Per definire unanalisi statica dobbiamo preoccuparci di: Come specificarla Come implementarla efficientemente Come provarne la correttezza

30 Tino CortesiAnalisi e Verifica di Programmi 30 Principali tecniche Abstract Interpretation Valutazione Parziale Dataflow Analysis Control Flow Analysis Model Checking Type Systems