A value of type t corresponds to an "approximation" of the result of a computation in the program being compiled. That is to say, it represents what knowledge we have about such a result at compile time. The simplification pass exploits this information to partially evaluate computations.
At a high level, an approximation for a value v has three parts:
- the "description" (for example, "the constant integer 42");
- an optional variable;
- an optional symbol or symbol field. If the variable (resp. symbol) is present then that variable (resp. symbol) may be used to obtain the value
v.
The exact semantics of the variable and symbol fields follows.
Approximations are deduced at particular points in an expression tree, but may subsequently be propagated to other locations.
At the point at which an approximation is built for some value v, we can construct a set of variables (call the set S) that are known to alias the same value v. Each member of S will have the same or a more precise descr field in its approximation relative to the approximation for v. (An increase in precision may currently be introduced for pattern matches.) If S is non-empty then it is guaranteed that there is a unique member of S that was declared in a scope further out ("earlier") than all other members of S. If such a member exists then it is recorded in the var field. Otherwise var is None.
Analogous to the construction of the set S, we can construct a set T consisting of all symbols that are known to alias the value whose approximation is being constructed. If T is non-empty then the symbol field is set to some member of T; it does not matter which one. (There is no notion of scope for symbols.)
Note about mutable blocks:
Mutable blocks are always represented by Value_unknown or Value_bottom. Any other approximation could leave the door open to a miscompilation. Such bad scenarios are most likely a user using Obj.magic or Obj.set_field in an inappropriate situation. Such a situation might be: let x = (1, 1) in
Obj.set_field (Obj.repr x) 0 (Obj.repr 2);
assert(fst x = 2) The user would probably expect the assertion to be true, but the compiler could in fact propagate the value of x across the Obj.set_field.
Insisting that mutable blocks have Value_unknown or Value_bottom approximations certainly won't always prevent this kind of error, but should help catch many of them.
It is possible that there may be some false positives, with correct but unreachable code causing this check to fail. However the likelihood of this seems sufficiently low, especially compared to the advantages gained by performing the check, that we include it.
An example of a pattern that might trigger a false positive is: type a = { a : int }
type b = { mutable b : int }
type _ t =
| A : a t
| B : b t
let f (type x) (v:x t) (r:x) =
match v with
| A -> r.a
| B -> r.b <- 2; 3
let v =
let r =
ref A in
r := A; (* Some pattern that the compiler can't understand *)
f !r { a = 1 } When inlining f, the B branch is unreachable, yet the compiler cannot prove it and must therefore keep it.