[PATCH] D79232: [analyzer] Refactor range inference for symbolic expressions

Gábor Horváth via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon May 4 10:09:39 PDT 2020


xazax.hun added inline comments.


================
Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:340-345
+    // TODO #2: We didn't go into the nested expressions before, so it
+    // might cause us spending much more time doing the inference.
+    // This can be a problem for deeply nested expressions that are
+    // involved in conditions and get tested continuously.  We definitely
+    // need to address this issue and introduce some sort of caching
+    // in here.
----------------
NoQ wrote:
> vsavchenko wrote:
> > NoQ wrote:
> > > I think this is a must-have, at least in some form. We've been exploding like this before on real-world code, well, probably not with bitwise ops but i'm still worried.
> > It will be pretty easy to introduce a limit on how deep we go into a tree of the given symbolic expression. That can also be a solution.
> I mean, doing something super trivial, like defining a map from symexprs to ranges in `SymbolicRangeInferrer` itself and find-or-inserting into it, will probably not be harder than counting depth(?)
I am a bit ignorant of this topic, but I wonder what a good caching mechanism would look like.
A simple `symexpr -> range` mapping does not feel right as the same symexpr might have a different range in a different program state (e.g., we might learn new ranges for our symbols). But having a separate map for each state state might do relatively little caching?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79232/new/

https://reviews.llvm.org/D79232





More information about the cfe-commits mailing list