[PATCH] D35109: [Analyzer] SValBuilder Comparison Rearrangement

Balogh, Ádám via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Jan 5 05:42:32 PST 2018

baloghadamsoftware added a comment.

In https://reviews.llvm.org/D35109#956075, @NoQ wrote:

> I'm totally fine with assuming the MAX/4 constraint on checker side - extension math would still be better than the MAX/4 pattern-matching in core because extension math should be more useful on its own. Otherwise, i'm also fine with MAX/4 `>`/`<` under an off-by-default flag, if this is indeed blocking future reviews. I'm just really uncomfortable with huge manual checker-side symbolic computations, essentially declaring that checkers should make their own solvers. Analyzer progress is already slowed down dramatically by technical debt in a lot of places - we rarely have time to address it, but at least we shouldn't introduce much more. This doesn't, in my opinion, reduce the fascination of that whole thing you've constructed. It is wonderful.

The problem with the type extension approach is that it is mathematically "more correct than it should be". I mean it fixes all overflow cases, even intentional ones which we probably do not want to do. I am not speaking about intentional overflow cases in the checkers or in the core infrastructure which could be fixed but intentional overlfow cases in the code we analyze.

So probably the MAX/4 approach is the correct one. But how to add a flag for this? Is it a flag enabled by the user or is it automatically enabled if the checker is enabled?


More information about the cfe-commits mailing list