Summary:
The SLEdge internal first-order theory solver targets the "word
problem", where a query has the form `C ⊢ L` where `C` is a
conjunction of literals and `L` is a single literal. This can be
abused to implement a naive SMT solver using an expansion to
disjunctive-normal form and checking `C ⊢ false` for each branch `C`
of the DNF. This is not useful as an SMT solver, but can be used for
testing.
Reviewed By: ngorogiannis
Differential Revision: D23459524
fbshipit-source-id: 5483e5a84
Summary:
Multiplication by a constant is primitive in the linear arithmetic
solver, while general multiplication is not, so for clarity and
predictability, use constants where possible.
Reviewed By: jvillard
Differential Revision: D21721020
fbshipit-source-id: 3497d06c9
Summary:
Instead of relying on Exp.nondet to encode the semantics of LLVM's
undef, translate each to a per-function unique register, with a nondet
assignment to it prior to each use. This avoids the need for
Exp.nondet, which is ill-formed in the sense that expressions denote
values, not sets of values (with particular constraints on what ways
in which the choice must be angelic vs demonic). This change
essentially allows the backend to be sane, and makes it the frontend's
problem to deal with LLVM's undef.
This treatment, like the treatment based on Exp.nondet, is expected to
result in LLAIR code with different semantics of undef compared to the
semantics of LLVM described in the
[LangRef](https://llvm.org/docs/LangRef.html#undefined-values). In
particular, the LLVM LangRef states
> An ‘undef’ “variable” can arbitrarily change its value over its
> “live range”. This is true because the variable doesn’t actually
> have a live range. Instead, the value is logically read from
> arbitrary registers that happen to be around when needed, so the
> value is not necessarily consistent over time.
To model this ability of undef to arbitrarily change its value over
its live range, it is likely that additional nondet assignments would
need to be added. Exactly where it not currently known.
Reviewed By: jvillard
Differential Revision: D21720976
fbshipit-source-id: 90c2a0d26
Summary:
Refactor frontend translation of LLVM values, opcodes, etc. to support
emitting not only a LLAIR expression, but also a sequence of
instructions to be prefixed onto the uses of the resulting expression.
This is currently unused, as all prefixes are empty. Later, it will be
used to translate e.g. `undef` to `r := nondet(); r`.
Reviewed By: jvillard
Differential Revision: D21720972
fbshipit-source-id: b89bb57de
Summary:
Refer to Llair modules using `Llair.` qualifier, except for in
`Frontend`, which makes so much use of `Llair` that it is now opened
(`Llair` only contains types and modules, so `open` is safe).
Reviewed By: jvillard
Differential Revision: D21720979
fbshipit-source-id: dd42075d9
Summary:
It is now possible to not spew dune files all over the repo, and opam
files aren't needed either.
Reviewed By: jvillard
Differential Revision: D21720978
fbshipit-source-id: 553e1d154
Summary:
Rather than compute the size of the llair type of the llair
initializer expression, compute the size of the llvm initializer
directly.
Reviewed By: ngorogiannis
Differential Revision: D21720982
fbshipit-source-id: 4364baf38
Summary:
Rather than translate an llvm type to a llair one and then compute the
size of the llair type, obtain the size of the llvm type directly.
Reviewed By: ngorogiannis
Differential Revision: D21720968
fbshipit-source-id: ad98112a7
Summary:
In LLVM it is possible for struct constant values to be directly
recursive, with no pointer dereference to close the cycle. These
appear for example as the values of vtables from C++ code.
Currently such recursive records in the Exp and Term languages are
represented as genuinely cyclic values. Compared to a standard term
representation, the presence of cyclic values is a significant
complication everywhere. Since the backend solver does not do anything
such as induction over these, they have to be treated as essentially
atomic.
This patch changes the representation to a standard non-recursive tree
term structure. Instead of cyclic references, an explicit constructor
is added for the "non-tree edges", which simply indicates which
ancestor record value to which the recursive reference points.
There is a potential issue with this representation, since for
mutually recursive records, the representation is not canonical: it
chooses one of the records in the cycle to start from and expresses
the cycles relative to that. Currently the choice of representation is
dictated by the frontend. For the case of vtables, the frontend
translates globals in the same order they appear in the LLVM IR, so
the representation choice is fixed.
It may turn out that other potential uses require more reasoning
support in the backend solver, which would involve a theory of
equality of record values induced by equating the representations
resulting from different rotations of the cycle of records.
Reviewed By: jvillard
Differential Revision: D21441533
fbshipit-source-id: 0c5a11378
Summary:
Having `val size_of : Typ.t -> t` in the signature of `Term` and `val
size_of : t -> t` in the signature of `Exp` gives the impression that
`Term` and `Exp` know something about `Typ`. But they don't, those
functions are only trivial convenience wrappers, and only have a few
uses, so just inline them to clarify that it is `Typ` that knows about
the sizes of types.
Reviewed By: jvillard
Differential Revision: D21441535
fbshipit-source-id: 09b135a8c
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:
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
Summary:
Work on the containers revealed that 1b8746d21 was premature, and this
diff is in part a revert of that. The objectives for the global
namespace are:
- self-consistent as much as possible
- rich data type operations
- does not require maintaining lots of tedious library wrapping code
- has Marshalable containers
- has containers with functorial interfaces
For these aims, it's best to stick with Core. Base isn't enough to
define functorial interfaces for collections (without a lot of tedious
wrapping code to keep in sync manually), and since a few modules not
in Core_kernel are needed anyhow.
Reviewed By: ngorogiannis
Differential Revision: D20583756
fbshipit-source-id: d939be7d0
Summary:
This diff defines Set as a functorover the underlying implementation
of Core.Set. This results in set values that are just trees, with no
comparison function closures, and with the same interface (almost) and
underlying data structure implementation as Core.Set.
Reviewed By: ngorogiannis
Differential Revision: D20583754
fbshipit-source-id: 79aa7477a
Summary:
The term "vector" evokes expectations of being automatically growable,
and these are just immutable arrays.
Reviewed By: ngorogiannis
Differential Revision: D20482762
fbshipit-source-id: 0cd2c9c23
Summary:
The base containers have inconvenient interfaces due to lacking
support for functors, which also leads to the representation of values
of containers including closures for the comparison functions. This
causes problems when `Marshal`ing these values.
This diff is one step toward not using the base containers.
Reviewed By: ngorogiannis
Differential Revision: D20482756
fbshipit-source-id: 0312c422d
Summary:
The base containers have inconvenient interfaces due to lacking
support for functors, which also leads to the representation of values
of containers including closures for the comparison functions. This
causes problems when `Marshal`ing these values.
This diff is one step toward not using the base containers.
Reviewed By: ngorogiannis
Differential Revision: D20482763
fbshipit-source-id: f55f91bf2
Summary:
Define a `ppx_sledge` ppx rewriter that composes all the ppx rewriters
used, so that the list needs to be specified only once.
Reviewed By: jvillard
Differential Revision: D20322874
fbshipit-source-id: f15540b7f
Summary:
Move files, adjust build system, etc.
This also separates out the ppx_trace conditional compilation debug
tracing machinery into an independent package and library.
Reviewed By: jvillard
Differential Revision: D20322876
fbshipit-source-id: a50522462
Summary:
The convenience symlinks from sledge/bin to the built binaries of
various build modes under sledge/_build/_install conflict with
upcoming code rearrangements, so remove them.
Reviewed By: jvillard
Differential Revision: D20322872
fbshipit-source-id: 1a7c99ae0
Summary:
Replace custom version reporting support using a shell script with
code using dune's Build_info API.
Note that after this diff, the executables under _build/<context> are
not version-stamped, but those under _build/_install are. The symlinks
in bin point to the latter, stamped, exes.
Reviewed By: bennostein
Differential Revision: D16985446
fbshipit-source-id: 7afac87be
Summary:
This adds an optimized debug build mode, which is compiled with
optimizations, and without assertions, but still has tracing enabled.
Reviewed By: kren1
Differential Revision: D16069452
fbshipit-source-id: 445cfa329
Josh Berdine