A safe approximate algorithm for interprocedural pointer aliasing

Abstract

HISTORYTrying to look back over a ten-plus year period and to remember what influenced us at the time, is difficult and error prone. Thus, it is probable that these reflections are incomplete. Nevertheless, it is important to our field to trace the historical influences on new ideas.Our interest in aliasing was a natural continuation of work done at Rutgers in incremental dataflow analysis in the 1980's. 1 Much of this work focused on FORTRAN, but as time went on C became a very important language and its analysis was essential for compiler optimization and the development of software tools. The most significant difference between C and FORTRAN from a static analysis perspective was the ubiquity of pointer aliasing in C. Because of this ubiquity, having a viable solution to the Pointer May-alias problem was fundamental to any whole-program static analysis for general C programs. At the time, there was no work yielding precise program point specific aliases for entire C programs, so the problem was unsolved, challenging and necessary.We started, perhaps surprisingly, from computability theory. It was obvious that a precise computation would not be possible. However, we thought that it was important to understand which aspects of the problem could be solved precisely and which had to be approximated. By "could be solved" we meant there exists a polynomial algorithm. We felt this approach would give us an appreciation of a complex problem that could be the basis for its viable solution. This resulted in our paper Pointer-induced Aliasing: A Problem Classification [22] in which we demonstrated a precise polynomial algorithm for the aliases of single-level pointers.Our subsequent approach was to design an algorithm that was precise for single-level pointers, but approximate in the general case. In retrospect, this decision still seems appropriate. While the worst case time complexities of our algorithms were polynomial, the order of the polynomial was large enough that their scalability to very large programs was questionable. However, it was clear that this worst case behavior was not likely to be encountered in practice. Trying to perform any sort of average case analysis was not possible, because the concept of an average program was ill-defined. Thus, we decided it was important to validate our approach through empirical performance measurements. This approach, while not invented by us, has since our paper become a 1 http://prolangs.rutgers.edu 20 .$5.00. requirement for subsequent analyses. Our original theoretical slant also caused us to look into sources of imprecision in our algorithm, still an important theme on our program analysis work.Finally, we built upon a large body of work in dataflow analysis and abstract interpretation; some of the most influential were [2, 3, 6, 21, 30, 28, 38]. SINCE PLDI 1992In our group (PROLANGS). Our PLDI 1992 paper [23] explored the concepts of flow and context sensitivity, two important dimensions in static analysis algorithm design. Intuitively, flow sensitivity refers to w...

Observational determinism for concurrent program security

“…More generally, pointer or shape analysis can be used to approximate Ö ´ µ and ÛÖ Ø ´ µ [21,9,10,33]. Because È Ê Ë 's sequential core is essentially an imperative language with ÓØÓ, we expect that these existing alias analyses can be adapted to this setting.…”

Precise Interprocedural Analysis in the Presence of Pointers to the Stack

“…Precise, but expensive, pointer analyses have also been proposed. For example, Landi and Ryder [21] tackles the may-alias problem and they merge into an algorithm the semantic work we did in Section 3 and an abstraction (less precise than the one we present in Section 4 and 6) This fusion of two distinct aspects of the analysis prevent the reuse of the algorithm with different abstraction schemes. Wilson and Lam [31] presents a lot of similarities with our work.…”

Source Code Analysis: A Road Map

“…The algorithm is summary-based following in the line of Liang and Harrold, and others [75,36,73]. To obtain context sensitivity, a meta-level description of the aliasing impact of each function is maintained.…”