Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure that definitions have the same ordering with dolmen #771

Merged
merged 1 commit into from
Jul 28, 2023

Conversation

bclement-ocp
Copy link
Collaborator

The dolmen frontend is adding declarations to the end of the command queue instead of to the front, causing the final command list to be all shuffled. This is the cause of at least some of the regressions with the dolmen frontend, since the solver now processes things in a different order.

This patch ensures that the definitions are added with the correct ordering, so that the command queue should be the same with both frontends, barring additional bugs. This was tested with -d commands on a few benchmarks locally, where it produced the exact same output with both frontends.

The patch also refactors slightly the [handle_smtt] method in the solving loop: as part of the debugging for this, I realized that we can never end up with Hyp constructors with local/global hypotheses names there, because one difference between the Dolmen and legacy frontend is that the legacy frontend extracts the hypotheses from the goal during typechecking (so prior to cnf-conversion) while the Dolmen frontend extracts the hypotheses from the goal during cnf-conversion (i.e. when we encounter a Solve).

The dolmen frontend is adding declarations to the end of the command
queue instead of to the front, causing the final command list to be all
shuffled. This is the cause of at least some of the regressions with the
dolmen frontend, since the solver now processes things in a different
order.

This patch ensures that the definitions are added with the correct
ordering, so that the command queue should be the same with both
frontends, barring additional bugs. This was tested with `-d commands`
on a few benchmarks locally, where it produced the exact same output
with both frontends.

The patch also refactors slightly the [handle_smtt] method in the
solving loop: as part of the debugging for this, I realized that we can
never end up with `Hyp` constructors with local/global hypotheses names
there, because one difference between the Dolmen and legacy frontend is
that the legacy frontend extracts the hypotheses from the goal during
typechecking (so prior to cnf-conversion) while the Dolmen frontend
extracts the hypotheses from the goal during cnf-conversion (i.e. when
we encounter a `Solve`).
@bclement-ocp
Copy link
Collaborator Author

Probably worth having this for the first release of Dolmen in 2.5.0 @Halbaroth

We will need to rerun benches but we probably will need to do that anyways due to the perf regressions

@bclement-ocp
Copy link
Collaborator Author

(This fixes the two dolmen regressions on AE-format-fpa)

@Halbaroth Halbaroth merged commit 613e828 into OCamlPro:next Jul 28, 2023
Halbaroth pushed a commit to Halbaroth/alt-ergo that referenced this pull request Jul 28, 2023
)

The dolmen frontend is adding declarations to the end of the command
queue instead of to the front, causing the final command list to be all
shuffled. This is the cause of at least some of the regressions with the
dolmen frontend, since the solver now processes things in a different
order.

This patch ensures that the definitions are added with the correct
ordering, so that the command queue should be the same with both
frontends, barring additional bugs. This was tested with `-d commands`
on a few benchmarks locally, where it produced the exact same output
with both frontends.

The patch also refactors slightly the [handle_smtt] method in the
solving loop: as part of the debugging for this, I realized that we can
never end up with `Hyp` constructors with local/global hypotheses names
there, because one difference between the Dolmen and legacy frontend is
that the legacy frontend extracts the hypotheses from the goal during
typechecking (so prior to cnf-conversion) while the Dolmen frontend
extracts the hypotheses from the goal during cnf-conversion (i.e. when
we encounter a `Solve`).
@Halbaroth Halbaroth mentioned this pull request Jul 28, 2023
@Halbaroth Halbaroth mentioned this pull request Aug 23, 2023
@bclement-ocp bclement-ocp deleted the bclement/dcompat branch January 3, 2024 14:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants