Skip to content

Conversation

@sim642
Copy link
Member

@sim642 sim642 commented Nov 12, 2025

This is on top of #1871.

This should be faster, because it doesn't require box domain analysis in parallel.
The domain is converted to box and back only during invariant generation.

It's also more precise in some sense because it can exclude box-like constraints, which cannot be inferred by box alone.
But maybe that's also a downside because it can exclude constraints, which still need the more precise domain.

So it's not clear to me what is the right thing. We could keep both, both that's one more configurable option which is unlikely to be useful.

This should be faster, because it doesn't require box domain analysis in parallel.
The domain is converted to box and back only during invariant generation.

It's also more precise in some sense because it can exclude box-like constraints, which cannot be inferred by box alone.
But maybe that's also a downside because it can exclude constraints, which still need the more precise domain.
@sim642 sim642 added cleanup Refactoring, clean-up sv-comp SV-COMP (analyses, results), witnesses performance Analysis time, memory usage pr-dependency Depends or builds on another PR, which should be merged before labels Nov 12, 2025
Base automatically changed from apron-octagon-invariant-simplify to master November 14, 2025 10:58
@sim642 sim642 removed the pr-dependency Depends or builds on another PR, which should be merged before label Nov 14, 2025
@sim642 sim642 added this to the SV-COMP 2026 milestone Nov 18, 2025
@sim642
Copy link
Member Author

sim642 commented Nov 18, 2025

I did some sv-benchmarks 60s 1GB 1 core level01 verify-validate runs with:

  1. No diff-box
  2. Previous diff-box
  3. This diff-box

here: https://goblint.cs.ut.ee/results/297-all-validate-diff-box-direct-level01/table-generator-cmp.table.html#/.

Already using the old diff-box made a huge self-validation difference: 5075 → 5719. And that's even without noticeable slowdown: the extra box analysis cost is made up by less witness generation effort.
But the invariant count decrease is massive:
image

This makes less of a difference: 5719 → 5822, but it's a much nicer and cheaper implementation (although in the grand scheme of SV-COMP this doesn't show).
There's still some invariant count decrease:
image

@sim642 sim642 merged commit e082d52 into master Nov 18, 2025
19 checks passed
@sim642 sim642 deleted the apron-invariant-diff-box-direct branch November 18, 2025 16:04
sim642 added a commit to sim642/opam-repository that referenced this pull request Nov 27, 2025
CHANGES:

Functionally equivalent to Goblint in SV-COMP 2026.

* Add sequential portfolio for SV-COMP (goblint/analyzer#1845, goblint/analyzer#1867, goblint/analyzer#1877).
* Add struct bitfield support (goblint/analyzer#1739, goblint/analyzer#1823).
* Improve bitwise operations for integer domains (goblint/analyzer#1739).
* Reimplement HTML output in OCaml (goblint/analyzer#1752).
* Remove YAML witness version 0.1 support (goblint/analyzer#1812, goblint/analyzer#1817, goblint/analyzer#1852, goblint/analyzer#1853, goblint/analyzer#1855).
* Fix incorrect invariants in witnesses (goblint/analyzer#1818, goblint/analyzer#1876).
* Simplify relational invariants in witnesses (goblint/analyzer#1826, goblint/analyzer#1871, goblint/analyzer#1873).
* Fix argument types in Goblint stubs (goblint/analyzer#1684, goblint/analyzer#1814, goblint/analyzer#1779, goblint/analyzer#1820).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cleanup Refactoring, clean-up performance Analysis time, memory usage sv-comp SV-COMP (analyses, results), witnesses

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants