Download Control Flow Super Graph - Advanced Compiler - Lecture Slides and more Slides Computer Science in PDF only on Docsity!
A simple approach
• Given call graph and CFGs of procedures, create a
single CFG (control flow super-graph) by:
– connecting call sites to entry nodes of callees (entries
become merges)
– connecting return nodes of callees back to calls
(returns become splits)
• Cons:
– speed?
– separate compilation?
– imprecision due to “unrealizable paths”
Another approach: summaries
• Compute summary info for each procedure
• Callee summary: summarizes effect/results of
callee procedures for callers
– used to implement the flow function for a call
node
• Caller summaries: summarizes context of all
callers for callee procedure
– used to start analysis of a procedure
Issues with summaries
• Level of “context” sensitivity:
– For example, one summary that summarizes the
entire procedure for all call sites
– Or, one summary for each call site (getting close to the
precision of inlining)
– Or ...
• Various levels of captured information
– as small as a single bit
– as large as the whole source code for callee/callers
• How does separate compilation work?
How to compute summaries
• Using iterative analysis
• Keep the current solution in a map from procs
to summaries
• Keep a worklist of procedures to process
• Pick a proc from the worklist, compute its
summary using intraprocedural analysis and
the current summaries for all other nodes
• If summary has changed, add callers/callees to
the worklist for callee/caller summaries
Examples
• Let’s see how this works on some examples
• We’ll use an analysis for program verification
as a running example
Protocol checking
Interface usage rules in
documentation
- Order of operations, data access
- Resource management
- Incomplete, wordy, not checked
Violated rules ) crashes
- Failed runtime checks
- Unreliable software
FSM protocols
• Alphabet of FSM are actions that affect the
state of the FSM
• Often leave error state implicit
• These FSMs can get pretty big for realistic
kernel protocols
FSM protocol checking
• Goal: make sure that FSM does not enter error
state
• Lattice:
Lock protocol example
g() { lock; }
h() { unlock; }
f() { h(); if (...) { main(); } }
main() { g(); f(); lock; unlock; }
main f g h
Lock protocol example
g() { lock; }
h() { unlock; }
f() { h(); if (...) { main(); } }
main() { g(); f(); lock; unlock; }
main f g h
u ; ; ; ; ; ; ; ” ” ” ” (^) u ” ” ” ” (^) ” ” ” l ” (^) ” ” ” l ” ”^ ” ” ”
” ” ” ” ”^ ” ”
” ” ” ” ”^ ” ”
l
” ” ” ”^ ” ” ”
” ” ” ”^ ” ” ”
” ” ” ”^ ” ” ”
u u u u
Another lock protocol example
g() { if(isLocked()) { unlock; } else { lock; } }
main f g
u ; ; ; ; ; ” ” ” ” ” ” ” ” ” ” ” ” ” ” ”
u l l
f() { g(); if (...) { main(); } }
main() { g(); f(); lock; unlock; }
Another lock protocol example
g() { if(isLocked()) { unlock; } else { lock; } }
main f g
u ; ; ; ; ; ” ” ” ” ” ” ” ” ” ” ” ” ” ” ” ” ” ” ” ”
u l l
{u,l}
f() { g(); if (...) { main(); } }
main() { g(); f(); lock; unlock; }
{u,l}
{u,l} {u,l} {u,l} {u,e}
What went wrong?
• We merged info from two call sites of g()
• Solution: summaries that keep different
contexts separate
• What is a context?
Approach #1 to context-sensitivity
• Keep information for different call sites
separate
• In this case: context is the call site from which
the procedure is called
