program slicing techniques

Corso di Analisi e Verifica di Programmi 2005/2006

Program slicing TechniquesProgram slicing Techniques(Frank Tip)

Alberto Franzin 807980Alice Marchiori 805090


• Cos’è una slice• Slicing Statico :

– Intraprocedurale• Dataflow equation• PDG approach

– Interprocedurale• Dataflow equation• SDG approach

SommarioSommario


• Definizione originaria (Weiser) : La Program Slice S è un programma ridotto ed eseguibile ottenuto da un programma P, rimuovendo parti di codice, tale che S replichi parte del comportamento di P.

• Ricavare una slice significa ridurre un programma alle sole istruzioni che influenzano il valore delle variabili in un determinato punto del codice che viene denominato slicing criterion

• Slicing criterion: (n, V) – numero di riga n, insieme di variabili da controllare V

• La tecnica di calcolare una program slice è detta Program Slicing

Program slice - DefinizioneProgram slice - Definizione


Due caratteristiche fondamentali:– Minimale– Eseguibile

• Minimale contiene il minor numero di linee di codice tali da rappresentare tutti i

punti di interesse per lo slicing criterion (non deve esistere un’altra slice con un minor numero di istruzioni)

• Eseguibile comportamento deve essere uguale a quello del programma originale

per le parti considerate e per tutti i possibili valori in input

Program slice - ProprietàProgram slice - Proprietà


(1) read (n);(2) i := 1;(3) sum := 0;(4) product := 1;(5) while i<= n do begin(6) sum:= sum +i ;(7) product := product *i;(8) i:= i + 1; end(9) write(sum);(10) write (product)

Esempio Esempio

(1) read (n);(2) i := 1;(3) (4) product := 1;(5) while i<= n do begin(6) (7) product := product *i;(8) i:= i + 1; end(9) (10) write (product)

(a) esempio di programma (b) Una slice del programma rispetto al criterio (10,product)


1- BASIC ALGORITHM FOR 1- BASIC ALGORITHM FOR STATIC SLICING STATIC SLICING


• Nessuna assunzione sull’input• Informazioni disponibili staticamente• Probabilistico approssimazione

Static SlicingStatic Slicing


Intraprocedural Static Slicing Intraprocedural Static Slicing


• Processo iterativo, computo insiemi consecutivi di variabili rilevanti per ogni nodo del CFG– Determino le variabili direttamente rilevanti seguendo le

dipendenze dati (data dependences), da qui derivo un insieme di comandi direttamente rilevanti

– Determino le variabili indirettamente rilevanti a partire dai comandi presenti nei predicati di controllo

• Parto da uno slicing criterion C = (n,V)• Ripeto l’iterazione finchè non arrivo ad un punto fisso (l’ultima

iterazione non trova nuovi comandi rilevanti)

Tecnica backward riconducibile al “reaching definition”

Dataflow Equation - WeiserDataflow Equation - Weiser


• CFG – Control Flow Graph– Ogni comando del programma è un nodo – Arco dal nodo i al nodo j corrisponde a possibile control flow da i

a j – Nodi speciali : Start e Stop

• DEF(i): insiemi di variabili definite al nodo i• REF(i): insiemi di variabili referenziate al nodo i • INFL(i): insiemi di nodi influenzati da i

Dataflow Equation – DefinizioniDataflow Equation – Definizioni


CFG – Control Flow Graph CFG – Control Flow Graph

Start read(n) i:=1 product:=1sum:=0 i<=n

sum:=sum+i

product:=product*i

i:=i+1

write(sum)write(product)Stop

CFG del programma

(1) (2) (3) (4) (5)

(6)

(7)

(8)

(9)(10)



Iterazione 0

Variabili direttamente rilevanti R0C(i):

• R0C(i)= V quando i = n

• per ogni arco da i a j nel CFG, R0C(i) contiene tutte le variabili v tali

che– o 1) v R0

C(j) e v DEF(i) – o 2) v REF(i) e DEF(i)∩ R0

C(j) ≠Comandi direttamente rilevanti S0

C: S0

C= {i| DEF(i) ∩ R0C(j) ≠ , per ogni j successore di i}

Comandi indirettamente rilevanti B0C:

B0C= {b| i S0

C , i INFL (b) }

Dataflow Equation - AlgoritmoDataflow Equation - Algoritmo


Esecuzione algoritmoEsecuzione algoritmoNodo DEF REF INFL R0

C R1C

1 {n}

2 {i}

3 {sum}

4 {product}

5 {i , n} {6,7,8}

6 {sum} { sum , i}

7 {product} {product , i}

8 {i} {i}

9 {sum}

10 {product}


{product}

{product}

{product}

{product}

{product , i}

{product ,i}

{product , i}

{product , i}

{i}

{i}

S0C={2,4,7,8}

B0C={5}

C1=(5,{i,n})

C=(10,{product})


Iterazione k+1

Variabili indirettamente rilevanti Rk+1C(i):

• Rk+1C(i)= Rk

C(i) R0(b,REF(b))(i)

Comandi indirettamente rilevanti S0C:

Sk+1C= Bk

C {i| DEF(i) ∩ Rk+1C(j) ≠, per ogni j successore di i}

Comandi indirettamente rilevanti B0C:

Bk+1C= {b| i Sk+1

C , i INFL (b) }

Il punto fisso della computazione di Sk+1C costituisce lo slice del

programma

Dataflow Equation - AlgoritmoDataflow Equation - Algoritmo

bBkC


Esecuzione algoritmoEsecuzione algoritmo

Nodo DEF REF INFL R0C1

1 {n}

2 {i}

3 {sum}

4 {product}

5 {i , n} {6,7,8}

6 {sum} { sum , i}

7 {product} {product , i}

8 {i} {i}

9 {sum}

10 {product}

{i,n}

{i,n}

{i,n}

{n}

C1=(5,{i,n})

{i,n}

{i,n}

{i,n}


Esecuzione algoritmoEsecuzione algoritmoNodo DEF REF INFL R0

C R1C

1 {n}

2 {i} {n}

3 {sum} {i} {i , n}

4 {product} {i} {i , n}

5 {i , n} {6,7,8} {product , i} {product, i, n}

6 {sum} { sum , i} {product , i} {product, i, n}

7 {product} {product , i} {product , i} {product, i, n}

8 {i} {i} {product , i} {product, i, n}

9 {sum} {product} {product}

10 {product} {product} {product}


S1C={1,2,4,5,7,8}


PDG Approach – Horwitz, Reps e BinkleyPDG Approach – Horwitz, Reps e Binkley

Il P.D.G. del programma P, denotato con GP, è un grafo orientato

I veritci del GP rappresentano: Assignment statments: Comandi di assegnamento Control predicates: Predicati di controllo (if, while)

Inoltre, sono presenti tre altre categorie di vertici: Entry vetrex Finale Use(x): Per ogni variabile x presente nel comando end, c’è un

vertice chiamato final use di x. Rappresenta il valore finale di x in P.


ENTER Main

sum := 0 i := 1 while i < 11 FinalUse(sum)

sum := sum+i

FinalUse(i)

i := i +1

Program Main sum := 0 i := 1 while i < 11 do sum := sum+i; i := i+1 odend(sum,i)


Un arco del GP rappresenta dipendenze tra le componenti del programma

Control dependence Etichettati con true o false Partono da un entry vertex o da un predicate vertex Etichettato con v1 →c v2, significa che durante l’esecuzione, ogni qual volta il comando

rappresentato da v1 viene valutato e il suo valore fa match con l’etichetta dell’arco verso v2, allora la parte del programma rappresentata da v2 viene eseguita

GP contiene un arco control dependence da v1 a v2 se sono soddisfatte una delleseguenti condizioni: v1 è un entry vertex e v2 rappresenta una componente di P che non è inserita all’interno di un

comando if o while; l’arco è etichettato con true v1 rappresenta un predicato di controllo e v2 rappresenta una componente di P inserito

all’interno del while o dell’if Caso while: arco etichettato con true Caso if: arco è etichettato con true se v2 occorre nel then, con false se occorre nell’else

Program Dependence GraphProgram Dependence Graph


ENTRY


sum := sum+i

FinalUse(i)

i := i +1


T T T TT

T T

control dependence

loop-indipendent

loop-carried


Data dependence Dal vertice v1 a v2 significa che la computazione del programma P cambia se

l’ordine relativo delle componenti rappresentate da v1 e v2 è invertito

Flow dependences (v1 →f v2) da v1 a v2 se tutte le seguenti condizioni sono soddisfatte:

1) v1 definisce la variabile x

2) v2 usa la variabile x

3) C’è un cammino nel control flow nel quale la definizione di x di v1 “arriva” a v2

Può essere classificata in:Loop carried: generata dal loop L, v1 →lc(L) v2

Loop indipendent: denotata con v1 →li v2

Program Dependence GraphProgram Dependence Graph


ENTRY

sum := 0 i := 1 while i < 11 FinalUse(i)

sum := sum+i

FinalUse(sum)

i := i +1


T T T TT

T T

control dependence

loop-indipendent

loop-carried


Per il vertice s del program dependence graph G, lo slice di G che rispetta s, denotato G/s è: Un grafo contenente tutti i vertici con i quali s ha una dipendenza flow o control Tutti i vertici che possono “raggiungere” (reach) s attraverso un arco flow e/o control

V(G/s) = { w | w V(G) and w →*c,f s }

Possiamo estendere la definizione ad un insieme di vertici S = i si :

V(G/S) = i V(G/si)

Gli archi del grafico G/S sono essenzialmente quelli di G inclusi da V(G/S), formalmente:E(G/S) = {(v →f w) | (v →f w) E(G) and v,w V(G/S)}

{(v →c w) | (v →c w) E(G) and v,w V(G/S)}

Program Slices - DefinizioneProgram Slices - Definizione


Program Maini := 1 while i < 11 do i := i+1 odend(i)

ENTRY

sum := 0 i := 1 while i < 11 FinalUse(i)

sum := sum+i

FinalUse(sum)

i := i +1


T T T TT

T T

Slice che rispetta il vertice FinalUse(i)

ENTRY

i := 1

i := i +1

while i < 11

control dependence

loop-indipendent

loop-carried


Interprocedural Static Slicing Interprocedural Static Slicing


Approccio a due fasii. Computo la slice della procedura P che contiene il criterio

originaleii. Creo nuovi criteri per procedure Q chiamate da P e per

procedure R che chiamano P

Le fasi si ripetono finchè non ci sono più nuovi criteri da generare

Dataflow Equation - Weiser Dataflow Equation - Weiser


1.Computo la slice della procedura che contiene il criterio originale:• MOD(P) e USE(P) delle procedure chiamate da Example• Chiamata a procedura trattata come se definisse tutte le variabili in MOD e

usasse le variabili in USE della procedura stessa (parametri attuali sostituiti a quelli formali)

• Problema: slice impreciso

Dataflow Equation – Fase 1 Dataflow Equation – Fase 1

C

USE(P)={v,w}MOD(P)={x,y}

Potrebbe esser tolto perché P non usa a per calcolare d ma Weiser considera rilevanti tutti i parametri passati a P (non considera dipendenze input output)

REF(4)={a,b}DEF(4)={c,d}


2. Creo nuovi criteri:i. per procedure Q chiamate da P eii. per procedure R che chiamano P

I nuovi criteri:i. (nq,Vq) – nq ultimo comando di Q, Vq variabili rilevanti in P che

sono nello scope di Q (formali sostituiti agli attuali)ii. (NR,VR) – NR chiamata a P in R, VR variabili rilevanti al primo

comando di P che sono nello scope di R (attuali sostituiti ai formali)

Funzioni UP e DOWN formalizzano:i. UP(S) : un insieme di criteri per le procedure che chiamano Pii. DOWN(S): un insieme di criteri per le procedure chiamate da P

Dataflow Equation – Fase 2 Dataflow Equation – Fase 2


Esempio Esempio

C=(10,{product})

USE(Add)={a,b} MOD(Add) ={a}

USE(Multiply) ={c,d}MOD(Multiply) ={c}

Nuovi Criteri:

UP(10, {product})=DOWN(10,{product})=(11,{a}), (17, {c,d})

Applicando passo 1 ottengo la slice: {1,2,4,5,7,8}

Calling Context: quando la computazione scende in una procedura Q chiamata da P risalirà a tutte le procedure che chiamano Q non solo a P

Problema : generando lo slice sulla procedura Multiply le chiamate a Add (15,16) causa la generazione di un nuovo criterio (11,{a,b}) reslicing di Add


Il System Dependence Graph è un’estensione del PDG per la gestione di procedure

e delle chiamate a procedura ed include: Program Dependence Graph: rappresenta il programma main Procedure Dependence Graphs: rappresentano le procedure ausiliarie

Assunzione: paramentri passati per valore

Obbiettivi della progettazione del SDG : costruire il Procedure Depencence Graph attraverso la conoscenza minima

degli altri componenti del sistema facile costruire, possibilmente in modo diretto, il SDG partendo dal PDG e

dai vari procedure dependence graphs possibile estrarre uno slice interprocedurale preciso in modo efficiente

System Dependence Graph – Horwitz, Reps e BinkleySystem Dependence Graph – Horwitz, Reps e Binkley


Il meccanismo per il passaggio dei parametri è il seguente:

Quando la procedura P chiama la procedura Q:

Prima della chiamata, P copia i valori dei parametri attuali nelle call temporaries

Q inizializza i propri parametri formali da queste temporaries

Prima della fase di ritorno, Q copia i valori di ritorno nelle return temporaries

P preleva i valori da queste temporaries

Passaggio dei parametriPassaggio dei parametri


Questo modello viene rappresentato nel procedure dependence graph attraverso l’utilizzo di seguenti nuovi tipi di vertici:

Call site vertex: rappresenta il punto della chiamata

L’informazione trasferita viene rappresentata da quattro tipi di paremeter vertices:

Dalla parte del chiamante, insieme di vertici actual-in e actual-out Rappresentano gli assegnamenti che copiano i valori dei parametri attuali nelle call

temporaries e delle return temporaries nei parementri attuali, ripettivemente control dependent con call site vertex actual-in è etichettato con r_in := e actual-out vertex, etichettato con a:= r_out

Nota: tutti i parametri sono copiati nelle call temporaries e tutti vengono prelevati dalle return temporaries



ENTER Main


call A

x_in := sum y_in := i

call Inc

y := z_outx := a_out

call Add

ENTER A

a_in = x b_in := y y := b_out

a := a+b

ENTER Add

z_in := y

FinalUse(i)

sum := x_out i := y_out

Program Mainsum := 0i := 1while i <11 call A (sum,i)odend(sum,i)

Procedure A(x,y)call Add(x,y)call Increment (y)return

Procedure Add(a,b)a := a+breturn

Procedure Increment(a,b)call Add(z,1)return

actual_in

actual_out

formal_in

formal_out

control dep.

loop-ind.

loop-car-

def-ord


Dalla parte della procedura chiamata, insieme di vertici formal-in e formal-out Copiano i valori dalle call temporaries nei paramentri formali e dai

parametri formali alle return temporaries control dependent con entry vertex della procedura formal-in e un formal-out vertex, etichettati con r := r_in e r_out:=r,

ripettivemente



ENTER Main


call A


call Inc

y := z_out

x_out := x y_out := y

x := a_out

call Add

ENTER A

y := y_in

a_in = x b_in := y

x := x_in

y := b_out

a_out := aa := a+bb := b_in

ENTER Add

a := a_in

z_in := y

FinalUse(i)


b_out := b





actual_in

actual_out

formal_in

formal_out


La generazione del System Depencence Graph partendo da: Program Dependence Graph Procedure Dependence Graphs

si effettua in modo diretto, con l’aggiunta di tre nuovi tipi di archi:

Call edge: viene aggiunto da ogni call-site vertex al corrispondente procedure-entry vertex

Parameter-in edge: viene aggiunto da ogni actual-in vertex al corrispondente formal-in vertex nella procedura chiamata

Parameter-out vertex: viene aggiunto da ogni formal-out vertex nella procedura chiamata alla corrispondente actual-out vertex del punto di chiamata

System Dependence Graph - CostruzioneSystem Dependence Graph - Costruzione


ENTER Main


call A


call Inc

y := z_out


x := a_out

call Add

ENTER A

y := y_in

a_in = x b_in := y

x := x_in

y := b_out


ENTER Add

a := a_in

z_in := y

FinalUse(i)


b_out := b





z := a_out

ENTER Inc

b_in := 1

z_out := zcall Add z := z_in

a_in := z

call

parameter-in

parameter-out


Lo slicing interprocedurale può essere pensato come un problema di raggiungibilità, come visto per lo slice di tipo intraprocedurale

Fornisce lo stesso risultato dell’ algoritmo interprocedurale fornito da Weiser, cioè, una slice non precisa perché fallisce nel tenere in considerazione il

calling context di una procedura chiamata

Interprocedural Slicing - LimiteInterprocedural Slicing - Limite


ENTER Main


call A


z := a_out

call Inc

y := z_out


x := a_out

call Add

ENTER A

y := y_in

a_in = x b_in := y

x := x_in

y := b_out

ENTER Inc

a_in := z


ENTER Add

a := a_in

b_in := 1


z_in := y

FinalUse(i)


b_out := b

Il valore di i dopo la chiamata alla procedura A è dipendente dal valore di sum prima della

chiamata


ENTER Main


call A


z := a_out

call Inc

y := z_out


x := a_out

call Add

ENTER A

y := y_in

a_in = x b_in := y

x := x_in

y := b_out

ENTER Inc

a_in := z


ENTER Add

a := a_in

b_in := 1


z_in := y

FinalUse(i)


b_out := b

Il cammino corrisponde alla chiamata della procedura Add da

A, ma viene ritornata la procedura Increment


ENTER Main


call A


z := a_out

call Inc

y := z_out


x := a_out

call Add

ENTER A

y := y_in

a_in = x b_in := y

x := x_in

y := b_out

ENTER Inc

a_in := z


ENTER Add

a := a_in

b_in := 1


z_in := y

FinalUse(i)


b_out := b

Non tutti i cammini corrispondono ad un possibile

cammino di esecuzione


Si devono considerare solamente i Realizable paths: cammini che riflettono il fatto che, quando una chiamata a

procedura termina, l’esecuzione ritorna al più punto di chiamata più recente per quella procedura

Il processo per determinare se un cammino è same-level realizable path è il seguente:1) Assegna ad ogni call vertex in SDG un numero unico da 1 a k2) Per ogni punto di chiamata ci, etichetta:

a) L’arco parameter-in uscente con il simbolo “(i”b) L’arco parameter-out entrante con il simbolo “)i”c) Il call edge con “(i”

3) Un cammino in G viene definito same-level realizable path sse la sequenza dei simboli che identificano gli archi parameter-in, parameter-out e call nel cammino è una stringa del linguaggio delle “parentesi bilanciate” generato dalle seguente grammatica:

matched → matched (i matched )i | ε per 1 ≤ i ≤ k

Realizable PathRealizable Path


ENTER Main


call A


z := a_out

call Inc

y := z_out


x := a_out

call Add

ENTER A

y := y_in

a_in = x b_in := y

x := x_in

y := b_out

ENTER Inc

a_in := z


ENTER Add

a := a_in

b_in := 1


z_in := y

FinalUse(i)


b_out := b

Il linguaggio generato è:

(1 (2 )4 )3 )1

1

2 3

4


ENTER Main


call A


z := a_out

call Inc

y := z_out


x := a_out

call Add

ENTER A

y := y_in

a_in = x b_in := y

x := x_in

y := b_out

ENTER Inc

a_in := z


ENTER Add

a := a_in

b_in := 1


z_in := y

FinalUse(i)


b_out := b

Il linguaggio generato è:

(1 (2 )2 )1

1

2 3

4


Per fare in modo che l’algoritmo per lo slicing interprocedurale si basi solo sui same-level realizable path si deve introdurre una nuova tipologia di archi:

Summary edge Inserito dal actual-in v (valore del parametro attuale x prima della

chiamata) al actual-out w (valore del parametro attuale y dopo la chiamata) rappresenta il fatto che il valore di y dopo la chiamata dipende dal valore di x prima della chiamata

permette di superare il problema del “calling context”: le operazioni per determinare lo slice possono muoversi “attraverso” una chiamata senza dover descendere dentro essa

Summary EdgeSummary Edge


Idea: Trovare per ogni procedura P, tutti i same-realizable path che partono da un formal-in vertex della procedura P e che terminano in un formal-out vertex della procedura stessa

path edge

nuovo summary edge

parameter-in o parameter-out edge

actual-in actual-out

qualsisi tipoformal-out

v ≠ formal-in(possibile nuovo) path edge

formal-in formal-out

Speeding Up Slicing – Reps, Hortwitz, Sogiv e RosaySpeeding Up Slicing – Reps, Hortwitz, Sogiv e Rosay

x y

v

w

x

w

v


ENTER Main


call A


z := a_out

call Inc

y := z_out


x := a_out

call Add

ENTER A

y := y_in

a_in = x b_in := y

x := x_in

y := b_out

ENTER Inc

a_in := z


ENTER Add

a := a_in

b_in := 1


z_in := y

FinalUse(i)


b_out := bb_out := bb := b_in a_out := ab := b_ina := a_in


ENTER Main


call A


z := a_out

call Inc

y := z_out


x := a_out

call Add

ENTER A

y := y_in

a_in = x b_in := y

x := x_in

y := b_out

ENTER Inc

a_in := z


ENTER Add

a := a_in

b_in := 1


z_in := y

FinalUse(i)


b_out := b


La computazione dello slice del SDG G che rispetta l’insieme di vertici S nella procedura P viene eseguito in due fasi:

PRIMA FASE

Seguiti flow edges, control edges, call edges, e parameter-in edges Identifica i vertici che possono raggiungere S, e che sono sia in P o in una

procedura che chiama P (o direttamente o transitivamente) Summary edges permettono di conoscere i vertici che possono raggiungere

S solamente attraverso una chiamata a procedura, senza discendere nelle procedure chiamate da P

Interprocedural Slicing - AlgoritmoInterprocedural Slicing - Algoritmo


ENTER Main


call A


z := a_out

call Inc

y := z_out


x := a_out

call Add

ENTER A

y := y_in

a_in = x b_in := y

x := x_in

y := b_out

ENTER Inc

a_in := z


ENTER Add

a := a_in

b_in := 1


z_in := y

FinalUse(i)


b_out := b


ENTER Main


call A


call Inc

y := z_out


x := a_out

call Add

ENTER A

y := y_in

a_in = x b_in := y

x := x_in

y := b_out

ENTER Inc

a_in := z


ENTER Add

a := a_in

b_in := 1


z_in := y

FinalUse(i)


b_out := b

z := a_out


SECONDA FASE

Seguiti flow edges, control edges,e parameter-out edges Identifica i vertici che possono raggiungere S da procedure

(transitivamente) chiamate da P o da procedure chiamate da procedure che (transitivamente) chiamano P

Summary edges rendono non necessaria la “salita” nelle procedure chiamate

Interprocedural Slicing - AlgoritmoInterprocedural Slicing - Algoritmo


ENTER Main


call A


call Inc

y := z_out


x := a_out

call Add

ENTER A

y := y_in

a_in = x b_in := y

x := x_in

y := b_out

ENTER Inc

a_in := z


ENTER Add

a := a_in

b_in := 1


z_in := y

FinalUse(i)


b_out := b

z := a_out


Interprocedural slice

Consiste nell’insieme di vertici identificati dalla fase 1 e dalla fase 2 e nell’insieme di archi inclusi da questo insieme di vertici

Program Mainsum := 0i := 1while i <11 call A(sum,i) odend(sum,i)



Program Maini := 1while i <11 call A (i)odend





Interprocedural Slicing - LimiteInterprocedural Slicing - Limite


Includere tutti gli actual-in e gli actual-out vertex per ogni ogni argomento in una chiamata a procedura porta ad ottenere un interprocedural che potrebbe non essere il più preciso possibile

MiglioramentoMiglioramento


ENTER Main


call A


call Inc

y := z_out


x := a_out

call Add

ENTER A

y := y_in

a_in = x b_in := y

x := x_in

y := b_out

ENTER Inc

a_in := z


ENTER Add

a := a_in

b_in := 1


z_in := y

FinalUse(i)


b_out := b

z := a_out

Lo slice include il call vertex che rappresenta la chiamata a Add da A, anche se la chiamata non modifica il

valore di z in Increment


ENTER Main


call A


call Inc

y := z_out


x := a_out

call Add

ENTER A

y := y_in

a_in = x b_in := y

x := x_in

y := b_out

ENTER Inc

a_in := z


ENTER Add

a := a_in

b_in := 1


z_in := y

FinalUse(i)


b_out := b

z := a_out

Il problema è che un actual-out vertex per l’argomento y nella chiamata ad

Add da A è incluso nel pdg, anche se Add non cambia il valore di y


Per ogni procedura P, vengono definiti i seguenti insiemi di variabili:

GMOD(P): L’insieme delle variabili che vengono modificate da P o da una procedura (transitivamente) chiamata da P

GREF(P): L’insieme delle variabili che vengono riferite da P o da una procedura (transitivamente) chiamata da P

Ogni procedura P include: Un formal-in e un actual-in vertex per ogni variabile in GMOD(P) GREF(P) Un formal-out e un actual-out vertex per ogni variabile in GMOD(P)

MiglioramentoMiglioramento


ENTER Main


call A


z := a_out

call Inc

y := z_out


x := a_out

call Add

ENTER A

y := y_in

a_in = x b_in := y

x := x_in

y := b_out

ENTER Inc

a_in := z


ENTER Add

a := a_in

b_in := 1


z_in := y

FinalUse(i)


b_out := b

i := 1 while i < 11

call A

Procedura GMOD GREF

A x, y x, y

Add a a, b

Inc z z


ENTER Main


call A


z := a_out

call Inc

y := z_out


x := a_out

call Add

ENTER A

y := y_in

a_in = x b_in := y

x := x_in

ENTER Inc

a_in := z


ENTER Add

a := a_in

b_in := 1


z_in := y

FinalUse(i)



Interprocedural slice

Consiste da l’insieme di vertici identificati dalla fase 1 e dalla fase 2 e dall’insieme di archi inclusi da questo insieme di vertici




Program Maini := 1while i <11 call A (i)odend

Procedure A(x,y)call Increment (y)return




Interprocedural Slicing - FinaleInterprocedural Slicing - Finale


• F. Tip. A survey of program slicing techniques.Journal of programming languages, 3:121–189, 1995.

• M. Weiser. Program slicing. IEEE Transactions on Software Engineering, 10:352-357, July 1984

• T. Reps, S. Horwitz, M. Sagiv, and G. Rosay. Speeding up slicing. In Proceedings of the Second ACM SIGSOFT Symposium on Foudations of Software Engineering, pages 11-20,1994. Published in ACM SIGSOFT Notes v19 n4

• S. Horwitz, T. Reps, and D. Binkley. Interprocedural slicing using dependence graphs. In Proceedings of the ACM SIGPLAN 88 Conference on Programming Language Design and Implementation, Atlanta, Georgia, June 1988.

• H. Agrawal and J. Horgan. Dynamic program slicing. In Proceedings of the ACM SIGPLAN '90 Conference, 1990.

• D.Binkley , K.Gallagher. Progam slicing. Advances in Computers, 43,1996

RiferimentiRiferimenti

program slicing techniques

Documents