This is part of the implementation of the dataflow analysis framework.
See "[RFC] A dataflow analysis framework for Clang AST" on cfe-dev.
The solver will be used in a follow-up patch to check validity of flow
conditions.
Differential D120289
[clang][dataflow] Add SAT solver interface and implementation sgatev on Feb 21 2022, 3:52 PM. Authored by
Details This is part of the implementation of the dataflow analysis framework. The solver will be used in a follow-up patch to check validity of flow
Diff Detail
Event TimelineComment Actions Address reviewers' comments.
Comment Actions Hi! Just a quick high level question. Did you look into reusing existing SAT solvers like miniSAT? What was the main reason for rolling our own instead of picking something up off the selves? Also, LLVM already has a SMT API (https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/Support/SMTAPI.h). I wonder if it would make sense to have a SAT base class for the SMT API and reuse that here? Specifically, because solvers could be useful for all of the frontends and also optimizations in the backends, it would be great to make sure everyone can benefit from these features. What do you think? Comment Actions Note that, there are already precedents for Clang using solver tech from LLVM. E.g., the clang static analyzer's Z3-based refutation support is using the SMT API in LLVM, and there are experiments integrating yet another solver with the SA: https://reviews.llvm.org/D110125 Comment Actions
Mainly to provide a lightweight out-of-the-box alternative. The solver interface is simple so one should be able to roll out an implementation for their favorite solver with little effort. One concrete use case that I have in mind for this solver implementation is unit tests, but we've also used it successfully to analyze a large codebase.
I think that on a high level we can either 1) integrate the SMT API types deeply into the dataflow framework and use that solver interface directly or 2) have a layer that translates from the dataflow BoolValue types to the SMT API types. At this point I'm not convinced that we should go for 1). For 2) we can simply provide an adapter that implements the dataflow solver API using the SMT API. This way the dataflow framework can be used with SMT API-compatible solvers. What do you think? Comment Actions Could you elaborate on what would be the main disadvantage of using 1)? (The advantage would be that we could very easily switch to Z3 any time.) Comment Actions Let me clarify 1) because I see two options there as well: 1.a) We replace the BoolValue hierarchy in the dataflow framework with SMTExprRef. 1.b) We add an SMTExprRef member to each boolean value (atom, conjunction, disjunction, and negation) in the dataflow framework. I find 2) least committal as it keeps the dataflow framework and the solver separate. For a simple integration with Z3 I can provide an implementation of clang::dataflow::Solver using the SMT API. That should boil down to translating dataflow types to SMT types. What do you think about this? Any other options we should consider? Comment Actions As far as I understand, there were downstream patches that used the same API with other SMT solvers. The authors did not upstream it because they did not see any major improvement on Z3 for any of the use cases.
After reading your analysis, I'm fine with the current approach. Comment Actions Overall, looks good to me. Some nits inline. Are there plans to get a model/assignment of the variables from the solver? That could be helpful for generating warning messages in the future :)
Comment Actions
Absolutely! That was only discussed briefly so far. One challenge would be distilling this model to present only relevant information to the user. That could also be best effort, of course. It's certainly something I think we should provide at some point.
|
= default? To make this trivially destructible.