Summary:
Show that the SSA restrictions imply that the blocks can be
topologically sorted so that any use of a variable follows its
definition in the list of blocks. This showed a slight flaw in my
definition of SSA form. It used to treat program counters up to
equality. However, PCs that point to a block header contain the location
that control came from (so that the Phi instructions can be executed),
but the SSA restrictions shouldn't pay attention to that, so now the
definition of SSA introduces a equivalence on PCs that ignores that
additional information.
Reviewed By: jberdine
Differential Revision: D21066873
fbshipit-source-id: 735575a1f
Summary:
Introduce an explicit assumption that all of the instructions are ones
that are implemented in the translation so far, rather than just
cheating proof cases.
Reviewed By: jberdine
Differential Revision: D20891352
fbshipit-source-id: 37598bd8f
Summary:
Separate into separate files the theorems that are just about the
translation (mostly about the structure of the variable->expression
mapping that the translation builds) from theorems about the translation
and the semantics.
Also move the stuff about dominator_ordered into the SSA Theory, since
it only makes sense for SSA programs, but doesn't have anything to do
with the translation.
Reviewed By: jberdine
Differential Revision: D20673124
fbshipit-source-id: 9d8b08164
Summary:
The LLVM->LLAIR translation keeps a mapping of variables to expressions.
Previously, the invariants related to that mapping were kept in the
state relation, and so the proof needed show that they were preserved
along execution traces. This wasn't obvious as the state changes in
non-SSA ways during evaluation, but the correctness of the mappings is
heavily based on the program being in SSA form. This change separates
out the invariants, and the proof uses the final mapping that the
compiler builds, which contains all of the relevant bindings that might
be needed during execution.
Reviewed By: jberdine
Differential Revision: D20625109
fbshipit-source-id: d4c2dfe19
Summary:
Treat the remainder of dividing a rational by an integer as if the
rational was an integer division.
Reviewed By: jvillard
Differential Revision: D21042515
fbshipit-source-id: b5d42ddec
Summary:
The partial treatment of Mul and Div terms can simplify some cases,
but since it is only a partial treatment that is not producing a
normal form, in other cases the "simplification" results in large and
non-canonical terms. It is safer to leave them uninterpreted.
Reviewed By: jvillard
Differential Revision: D21042521
fbshipit-source-id: 04fc37f1a
Summary:
The heights of And and Or terms can grow high. This interacts poorly
with some unoptimized Equality operations such as normalization that
do some processing at every subterm.
Reviewed By: jvillard
Differential Revision: D21042518
fbshipit-source-id: 55e6acbb1
Summary:
These are map and folding map that perform a cycle-preserving
pre-order transformation.
Reviewed By: jvillard
Differential Revision: D20877974
fbshipit-source-id: 251288228
Summary:
The current notion of "simplified" function symbols, which are treated
as a hybrid between interpreted and uninterpreted, has no logical
basis. Normalization is now strong enough, due to stronger handling of
the changing carrier set, that the "simplified" classification can be
removed.
Reviewed By: jvillard
Differential Revision: D20726961
fbshipit-source-id: 9962ea323
Summary:
It is possible for the canonical form of a term in (the carrier set
of) a relation to be a term that is not in the relation. It is also
possible for this term to be equal to a term in the relation. It is
the job of the lookup subroutine of normalization to find these
equations.
The current implementation of entails_eq is incomplete in this case,
in particular, when an uninterpreted term has an interpreted subterm,
which itself has a subterm that is not a representative.
This diff strengthens normalization (and hence it's callers such as
entails_eq) to handle such cases. This makes lookup work slightly
harder. An alternative would be to extend the carrier with new terms
from normalization to the carrier and closing the relation, and then
re-normalizing. That would lead to much inflated representation sizes,
and is inefficient.
Reviewed By: jvillard
Differential Revision: D20612565
fbshipit-source-id: 3b7534a62
Summary:
This diff adds enough interpretation of Mul and Div terms to be able
to exclude them from the domain of solution substitutions. While
non-linear arithmetic is still treated very incompletely, this change
increases the propagation power of the equality constraints that are
deduced. Mainly, this appears to be enough to avoid operations that
are semantically equivalence-preserving such as solve_for_vars from
producing equalities that are unprovable from their inputs.
Reviewed By: jvillard
Differential Revision: D20863528
fbshipit-source-id: fca74cba3
Summary:
For non-linear polynomial equations, the solver can currently choose
to solve for a variable that occurs in a non-linear subterm, leading
to a non-idepotent solution substitution. For example, `x - y + (x ×
z) = 0` could be solved for `x`, leading to `x ↦ y - (x × z)` where
`x` is solved in terms of itself. This diff refines Term.solve_zero_eq
to avoid such cyclic solutions.
Reviewed By: jvillard
Differential Revision: D20637482
fbshipit-source-id: 6d7df85c3
Summary:
Strengthen the canonizer for division and rational constant terms. It
is important to avoid constructing `Q.t` values with 0 denominators,
as they do not represent real numbers, and the algebraic manipulation
done by the rest of the solver is incorrect in that case.
Additionally strengthen the Term representation invariants to check
that all coefficients and exponents are valid real rational numbers.
Also normalize division by an integer or rational to multiplication by
a rational.
Reviewed By: jvillard
Differential Revision: D20663964
fbshipit-source-id: 210962fe0
Summary:
Equations of the form `a = b` where `a` is a proper subterm of `b` are
possible when uninterpreted functions are involved. Internally,
Equality does not eagerly substitute `b` for `a`, but external clients
can repeatedly `Equality.normalize` terms and thereby incrementally
blow up the sizes of terms.
This diff uses the heights of uninterpreted terms to choose equality
class representatives to avoid such blow-ups, by orienting equations
so that tall terms are represented by short terms, so that repeated
normalization cannot increase term height indefinitely.
Reviewed By: jvillard
Differential Revision: D20785632
fbshipit-source-id: ff4c5bacd
Summary:
The types are constants and need not be re-checked for equality during
normalization, etc.
Reviewed By: jvillard
Differential Revision: D20863526
fbshipit-source-id: 1adde5ee0
Summary:
Ensure all entry points check the representation invariant before
returning, and strengthen it to check the constraints on preference
between representative terms, and to check that the relation is
closed.
Reviewed By: jvillard
Differential Revision: D20612566
fbshipit-source-id: b345397c4
Summary:
Change the implementation of `Equality.Subst.compose` to preserve
physical equality if the result is `Subst.equal` to the first
argument.
Reviewed By: jvillard
Differential Revision: D20752671
fbshipit-source-id: 4641a298a
Summary:
Currently there is an implicit assumption in Sh.simplify that
variables do not occur free in an equality relation which makes no
constraint on their values. This diff adds a step to formula
simplification that explicitly removes eliminated existentials from
equality relations.
Reviewed By: jvillard
Differential Revision: D20726960
fbshipit-source-id: 7109aa479
Summary:
Fix the crash in
```
(And_eq () (Var (id 10) (name v))
(Mul (((Var (id 8) (name v)) 1) ((Var (id 9) (name v)) 1)))
((xs ()) (sat true) (rep ())))
```
The solver for interpreted functions relies on the solution
substitutions containing mappings from variables to interpreted
applications, and never in the reverse. When solving equations
involving polynomials, this constraint is specifically
established. But for equalities involving only monomials, it could
happen that e.g. `x` was chosen as the representative of `a × b`,
which violates this constraint.
Reviewed By: jvillard
Differential Revision: D20596422
fbshipit-source-id: 69b026f03
Summary: Term.compare already ignores Var names, make Term.equal do so as well.
Reviewed By: jvillard
Differential Revision: D20663961
fbshipit-source-id: 59e7aa880
Summary:
Generate output on stderr containing lines such as:
```
solve_for_vars time: 0.105 ms 0.871 ms 79 calls
```
which indicates that the current maximal time of a single
`solve_for_vars` query is `0.105 ms` and so far the total time spent in
`solve_for_vars` over `79` queries is `0.871 ms`.
At program exit, there is also a line for each timer indicating the
max query time and final accumulated duration and number of queries:
```
solve_for_vars time: 0.173 ms 17.242 ms 1108 calls
```
Additionally, replay sexp are dumped interactively. A query exceeding
1 sec is dumped, then one exceeding 2 sec, then 4 sec, etc.
Reviewed By: jvillard
Differential Revision: D20852160
fbshipit-source-id: 0a316891e
Summary:
Rename and clarify documentation to indicate that the stronger
specification wrt physical equality is due to requiring the mapped
function to be an endofunction.
Reviewed By: jvillard
Differential Revision: D20863524
fbshipit-source-id: 74dabeb5c
Summary:
Otherwise there is an alias `'a t` for `'a option` polluting the
global namespace, which causes e.g. merlin to produce confusing types.
Reviewed By: jvillard
Differential Revision: D20831349
fbshipit-source-id: dff7b4f15
Summary:
Many Equality functions accept and return a set of variables, document
their function.
Reviewed By: ngorogiannis
Differential Revision: D20596492
fbshipit-source-id: b91ae7197
Summary:
Passing info that affects the build through environment variables is
bad since it is not very visible, e.g. in log files. Also, those
settings are not recorded in .merlin files, leading to merlin using
the default configuration.
This diff changes ppx_trace to use a 'cookie' instead of an
environment variable, and configures dune to set this cookie based on
the selected profile. This has the benefit of using command line
arguments such as `--cookie 'ppx_trace_enabled="1"'` which appear in
build logs and .merlin files.
Reviewed By: jvillard
Differential Revision: D20590515
fbshipit-source-id: d2daceaa3
Summary:
Previously building would spew:
```
Warning 58: no cmx file was found in path for module Build_info__Build_info_data, and its interface was not compiled with -opaque
```
This is from compilation of the generated `build_info_data.ml-gen`. It
does not have an interface, so I don't how to resolve this other than
disabling the warning.
See also https://github.com/ocaml/dune/issues/3277 .
Reviewed By: jvillard
Differential Revision: D20589879
fbshipit-source-id: fcd86fb3b
Summary:
Now that the containers use functorial interfaces with representations
that do not include closures for the comparison functions, it is not
necessary to enable closure support when Marshaling the IR between the
frontend and backend. This should be slightly faster, but more
importantly, it means that the serialized form is stable across
changes to the analyzer that do not change the representation of the
IR types, and in particular, the dbg and opt binaries can use the same
serialized form.
Reviewed By: jvillard
Differential Revision: D20589880
fbshipit-source-id: 63f07335e
Summary:
If both the library and binary are named `sledge`, then compilation
works fine and resolves the names correctly, but merlin gets confused
and cannot find the sledge library modules used in the bin sources. So
the binary and library need different names. The name of the library
gets exposed to clients, while the name of the binary only determines
the name of some files in the _build directory, which can be renamed
as desired. Therefore, use the `sledge` name for the library module,
and rename the binary module to `sledge_cli`, but still have dune
install it as `sledge.exe`.
Reviewed By: jvillard
Differential Revision: D20589431
fbshipit-source-id: 14b65907d