[cfe-dev] [analyzer] Summary IPA thoughts

Artem Dergachev via cfe-dev cfe-dev at lists.llvm.org
Fri Oct 23 07:31:13 PDT 2015


Artem Dergachev via cfe-dev cfe-dev at lists.llvm.org wrote:
 > Unfortunately, we did not yet handle symbolic offsets in the store
 > properly.

Artem Dergachev via cfe-dev cfe-dev at lists.llvm.org wrote:
 > Well, the real problem arises when we have a concrete offset in the
 > summary, but the actualized base has symbolic offset.

Hmm, probably, this problem can be solved by always storing the region 
through which the binding happened, even for concrete offsets. This 
assumes storing an extra pointer for every binding.


There's one more thing we don't yet handle in during summary-apply in 
the store, namely, the case when two different base regions actualize 
into the same region, eg:

   int a;
   void foo(int *x, int *y) {
     *x = 0;
     *y = 1;
   }
   void bar() {
     foo(&a, &a);
     clang_analyzer_eval(a); // expected-warning{{TRUE}}
   }

- in this case, with summary IPA, we are not yet sure if 'a' going to be 
0 or 1.

This problem can also be solved by making the bindings heavier, eg. by 
introducing a timestamp for every binding, and sorting by timestamps 
before applying the summary.


Therefore, the most sensible way i see to solve these two issues is to 
make the bindings 2x heavier (now we have two pointers, we'd add a 
pointer and an integer; probably we can change the concrete offset to 
32-bit and let the timestamp be 32-bit as well, and it'd be 1.5x heavier 
then, on 64-bit systems).

Not sure how easy it is to solve this without actually forking the whole 
RegionStore (we do not want this because current RegionStore has a lot 
of fancy stuff, such as constructing bindings which are not yet stored 
in the binding map, which would be great to re-use; hmm, why are they in 
the store manager anyway?).



More information about the cfe-dev mailing list