[cfe-dev] [analyzer][z3] Limit Z3 without timeouts
Nuno Lopes via cfe-dev
cfe-dev at lists.llvm.org
Wed Aug 19 10:26:29 PDT 2020
There's a caveat to Z3's resource limit option: it counts operations done across very different algorithms, so an rlimit may be not super correlated with running time for some inputs.
For example, on some input, the rlimit may be triggered during preprocessing, ending the solver early. With another input, it reaches the SAT solver so it has a different meaning and run-time characteristics. I don't know if clang is using quantifiers, but in that case it's even worse (though you can use 'smt.mbqi.max_iterations' instead).
So while it's true that rlimit gives a deterministic running time, it offers poor behavior across queries. A first query may timeout after 10 seconds, and the second only after 1 minute.
BTW, using Z3's memory limit is a no-no. Z3 can't recover from the state where memory limit is hit. The alternative is to use a "soft" limit (deterministic though): memory_high_watermark. This soft limit also helps taming the running time.
Nuno
From: Balázs Benics
Sent: 19 August 2020 18:10
To: cfe-dev <cfe-dev at lists.llvm.org>
Subject: [cfe-dev] [analyzer][z3] Limit Z3 without timeouts
SMT solvers are actively used not only for bugreport refutation but also for substituting the range based constraint manager.
IMO it would be valuable to limit the solver to prevent it from spending too much time on evaluating the given constraint set.
Using timeouts are not really deterministic, so its a no-go.
Using a counter-like limit would be the best approach.
Fortunately, Z3 has an `rlimit` option, which does exactly this.
This `rlimit` option is not really well documented, but here is the information that I have:
- https://github.com/Z3Prover/z3/blob/73d73e6c953dd0d63d76c1dca7f88bc04ccf4565/src/opt/opt_params.pyg#L11
- https://stackoverflow.com/a/45458651
Other solvers might not have such parameter, so we have to make a decision here how to integrate into our SMTAPI in a nonintrusive way.
Regards,
Balazs
More information about the cfe-dev
mailing list