NULL, not the store, to determine if a lookup succeeded. The store
can be null if it contained no bindings. This fixes a false positive
reported to me by a user of the analyzer.
llvm-svn: 95679
RegionStoreManager::InvalidateRegions() by adjusting the worklist to
iterate over BindingKeys instead of MemRegions. We also only need to
do the actual invalidation work on base regions, and for non-base
regions just blow away their bindings.
llvm-svn: 95200
not build a subregion map and instead do a single scan of the store.
This is done by building "region clusters" that represent the
collection of regions that have the same base region. Invalidating
any region in a cluster means that they all should get invalidated.
This change brought out a point that Zhongxing mentioned to me
offline: the flattened memory binding has issues distinguishing
between direct and default bindings. For example, setting the default
value for an entire struct is the same as binding to the first
element. To address this problem, I moved the binding "tag" (Direct
or Default) from BindingVal to BdingKey (and removed BindingVal
entirely). This requires us to do double lookups in some cases; and
there is still much more cleanup that can be done.
This change produced a noticeable speedup when analyzing sqlite3 (a
reduction of 4% in running time).
llvm-svn: 95193
(1) libAnalysis is a generic analysis library that can be used by
Sema. It defines the CFG, basic dataflow analysis primitives, and
inexpensive flow-sensitive analyses (e.g. LiveVariables).
(2) libChecker contains the guts of the static analyzer, incuding the
path-sensitive analysis engine and domain-specific checks.
Now any clients that want to use the frontend to build their own tools
don't need to link in the entire static analyzer.
This change exposes various obvious cleanups that can be made to the
layout of files and headers in libChecker. More changes pending. :)
This change also exposed a layering violation between AnalysisContext
and MemRegion. BlockInvocationContext shouldn't explicitly know about
BlockDataRegions. For now I've removed the BlockDataRegion* from
BlockInvocationContext (removing context-sensitivity; although this
wasn't used yet). We need to have a better way to extend
BlockInvocationContext (and any LocationContext) to add
context-sensitivty.
llvm-svn: 94406
Ted Kremenek