Pointer analysis

In computer science, pointer analysis, or points-to analysis, is a static code analysis technique that establishes which pointers, or heap references, can point to which variables, or storage locations. It is often a component of more complex analyses such as escape analysis. A closely related technique is shape analysis.

This is the most common colloquial use of the term. A secondary use has ''pointer analysis'' be the collective name for both ''points-to analysis'', defined as above, and alias analysis. Points-to and alias analysis are closely related but not always equivalent problems.

Example

For the following example program, a points-to analysis would compute that the points-to set of p is .

int x;
int y;
int* p = unknown() ? &x : &y;

Introduction

As a form of static analysis, fully precise pointer analysis can be shown to be undecidable. Most approaches are sound, but range widely in performance and precision. Many design decisions impact both the precision and performance of an analysis; often (but not always) lower precision yields higher performance. These choices include:

* ''Field sensitivity'' (also known as ''structure sensitivity''): An analysis can either treat each field of a struct or object separately, or merge them.
* ''Array sensitivity'': An array-sensitive pointer analysis models each index in an array separately. Other choices include modelling just the first entry separately and the rest together, or merging all array entries.
* ''Context sensitivity'' or '' polyvariance'': Pointer analyses may qualify points-to information with a summary of the control flow leading to each program point.
* ''Flow sensitivity'': An analysis can model the impact of intraprocedural control flow on points-to facts.
* ''Heap modeling'': Run-time allocations may be abstracted by:
** their allocation sites (the statement or instruction that performs the allocation, e.g., a call to malloc or an object constructor),
** a more complex model based on a shape analysis,
** the type of the allocation, or
** one single allocation (this is called ''heap-insensitivity'').
* ''Heap cloning'': Heap- and context-sensitive analyses may further qualify each allocation site by a summary of the control flow leading to the instruction or statement performing the allocation.
* ''Subset constraints'' or ''equality constraints'': When propagating points-to facts, different program statements may induce different constraints on a variable's points-to sets. Equality constraints (like those used in Steensgaard's algorithm) can be tracked with a union-find data structure, leading to high performance at the expense of the precision of a subset-constraint based analysis (e.g., Andersen's algorithm).

Context-Insensitive, Flow-Insensitive Algorithms

Pointer analysis algorithms are used to convert collected raw pointer usages (assignments of one pointer to another or assigning a pointer to point to another one) to a useful graph of what each pointer can point to.

Steensgaard's algorithm and Andersen's algorithm are common context-insensitive, flow-insensitive algorithms for pointer analysis. They are often used in compilers, and have implementations in the LLVM codebase.

Flow-Insensitive Approaches

Many approaches to flow-insensitive pointer analysis can be understood as forms of abstract interpretation, where heap allocations are abstracted by their allocation site (i.e., a program location).

Many flow-insensitive algorithms are specified in Datalog, including those in the Soot analysis framework for Java.

Context-sensitive, flow-insensitive algorithms achieve higher precision, generally at the cost of some performance, by analyzing each procedure several times, once per ''context''. Most analyses use a "context-string" approach, where contexts consist of a list of entries (common choices of context entry include call sites, allocation sites, and types). To ensure termination (and more generally, scalability), such analyses generally use a ''k''-limiting approach, where the context has a fixed maximum size, and the least recently added elements are removed as needed. Three common variants of context-sensitive, flow-insensitive analysis are:

* Call-site sensitivity
* Object sensitivity
* Type sensitivity

Call-site sensitivity

In call-site sensitivity, the points-to set of each variable (the set of abstract heap allocations each variable could point to) is further qualified by a context consisting of a list of callsites in the program. These contexts abstract the control-flow of the program.

The following program demonstrates how call-site sensitivity can achieve higher precision than a flow-insensitive, context-insensitive analysis.

int *id(int* x)
int main()

For this program, a context-insensitive analysis would (soundly but imprecisely) conclude that can point to either the allocation holding or that of , so and may alias, and both could point to either allocation. A callsite-sensitive analysis would analyze twice, once for call-site 1 and once for call-site 2, and the points-to facts for would be qualified by the call-site, enabling the analysis to deduce that when returns, can only point to the allocation holding and can only point to the allocation holding .

Object sensitivity

In an object sensitive analysis, the points-to set of each variable is qualified by the abstract heap allocation of the receiver object of the method call. Unlike call-site sensitivity, object-sensitivity is ''non-syntactic'' or ''non-local'': the context entries are derived during the points-to analysis itself.

Type sensitivity

Type sensitivity is a variant of object sensitivity where the allocation site of the receiver object is replaced by the class/type containing the method containing the allocation site of the receiver object. This results in strictly fewer contexts than would be used in an object-sensitive analysis, which generally means better performance.

References

Bibliography

*
*
*
*
*
*

{{Compiler optimizations
Static program analysis