Content deleted Content added
m clean up- spelling "et al." using AWB |
m Task 70: Update syntaxhighlight tags - remove use of deprecated <source> tags |
||
(15 intermediate revisions by 13 users not shown) | |||
Line 1:
In [[computer science]], '''definite assignment analysis''' is a [[data-flow analysis]] used by [[compiler]]s to conservatively ensure that a variable or ___location is always assigned
==Motivation==
In [[C programming language|C]] and [[C++]] programs, a source of particularly difficult-to-diagnose errors is the nondeterministic behavior that results from reading [[uninitialized
There are two common ways to solve this problem. One is to ensure that all locations are written before they are read. [[Rice's theorem]] establishes that this problem cannot be solved in general for all programs; however, it is possible to create a conservative (imprecise) analysis that will accept only programs that satisfy this constraint, while rejecting some correct programs, and definite assignment analysis is such an analysis. The [[Java programming language|Java]]<ref>{{cite web |
The second way to solve the problem is to automatically initialize all locations to some fixed, predictable value at the point at which they are defined, but this introduces new assignments that may impede performance. In this case, definite assignment analysis enables a [[compiler optimization]] where redundant assignments — assignments followed only by other assignments with no possible intervening reads — can be eliminated. In this case, no programs are rejected, but programs for which the analysis fails to recognize definite assignment may contain redundant initialization. The [[Common Language Infrastructure]] relies on this approach.<ref>{{cite web | title = Standard ECMA-335, Common Language Infrastructure (CLI) | work = ECMA International | url = http://www.ecma-international.org/publications/standards/Ecma-335.htm | accessdate =
==Terminology==
Line 32:
|}
We supply data-flow equations that define the values of these functions on various expressions and statements, in terms of the values of the functions on their syntactic subexpressions. Assume for the moment that there are no ''goto'', ''break'', ''continue'', ''return'', or [[exception handling]] statements. Following are a few examples of these equations:
* Any expression or statement ''e'' that does not affect the set of variables definitely assigned: ''after''(''e'') = ''before''(''e'')
Line 45:
The algorithm is complicated by the introduction of control-flow jumps like ''goto'', ''break'', ''continue'', ''return'', and exception handling. Any statement that can be the target of one of these jumps must intersect its ''before'' set with the set of definitely assigned variables at the jump source. When these are introduced, the resulting data flow may have multiple fixed points, as in this example:
<syntaxhighlight lang="c" line>
</syntaxhighlight>
Since the label L can be reached from two locations, the control-flow equation for goto dictates that ''before''(2) = ''after''(1) intersect ''before''(3). But ''before''(3) = ''before''(2), so ''before''(2) = ''after''(1) intersect ''before''(2). This has two fixed-points for ''before''(2), {i} and the empty set. However, it can be shown that because of the monotonic form of the data-flow equations, there is a unique maximal fixed point (fixed point of largest size) that provides the most possible information about the definitely assigned variables. Such a maximal (or maximum) fixed point may be computed by standard techniques; see [[data-flow analysis]].
An additional issue is that a control-flow jump may render certain control flows infeasible; for example, in this code fragment the variable ''i'' is definitely assigned before it is used:
<syntaxhighlight lang="c" line>
</syntaxhighlight>
The data-flow equation for ''if'' says that ''after''(2) = after('''return''') intersect after(''i'' = ''j''). To make this work out correctly, we define ''after''(''e'') = ''vars''(''e'') for all control-flow jumps; this is vacuously valid in the same sense that the equation ''false''('''true''') = ''vars''(''e'') is valid, because it is not possible for control to reach a point immediately after a control-flow jump.
Line 63:
<references />
{{DEFAULTSORT:Definite Assignment Analysis}}
[[Category:
|