[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