CallExprs as those edges help cause a n^2 explosion in the number of
destructor calls. Other consumers, such as static analysis, that
would like to have more a more complete CFG can select the inclusion
of those edges as CFG build time.
This also fixes up the two compilation users of CFGs to be tolerant of
having or not having those edges. All catch code is assumed be to
live if we didn't generate the exceptional edges for CallExprs.
llvm-svn: 94074
- Refactor the MemRegion hierarchy to distinguish between different StackSpaceRegions for locals and parameters.
- VarRegions for "captured" variables now have the BlockDataRegion as their super region (except those passed by reference)
- Add transfer function support to GRExprEngine for BlockDeclRefExprs.
This change also supports analyzing blocks as an analysis entry point
(top-of-the-stack), which required pushing more context-sensitivity
around in the MemRegion hierarchy via the use of LocationContext
objects. Functionally almost everything is the same, except we track
LocationContexts in a few more areas and StackSpaceRegions now refer
to a StackFrameContext object. In the future we will need to modify
MemRegionManager to allow multiple StackSpaceRegions in flight at once
(for the analysis of multiple stack frames).
llvm-svn: 90809
This required two changes:
1) Added 'getReferencedgetReferencedBlockVars()' to AnalysisContext so
that clients can iterate over the "captured" variables in a block.
2) Modified LiveVariables to take an AnalysisContext& in its
constructor and to call getReferencedgetReferencedBlockVars() when it
processes a BlockExpr*.
llvm-svn: 89924
AnalysisManager periodically cleanup its AnalysisContextManager and LocationContextManager objects,
as they don't need to forever retain all the CFGs ever created when analyzing a file.
llvm-svn: 84684
SelfRegion represented the object bound to 'self' (when analyzing Objective-C
methods) upon entry to a method. Having this region stored on the side ignores
the current stack frame that we might be analyzing (among other things), and is
a problem for interprocedural analysis.
For RegionStoreManager, the value for SelfRegion is just lazily created.
For BasicStoreManager, the value for SelfRegion is bound eagerly to 'self', but
no explicit tracking of SelfRegion on the side is made.
As part of this change, remove the restriction in BasicStoreManager that we only
track ivars for 'self'. This shouldn't actually change anything in terms of
precision, and simplifies the logic.
llvm-svn: 79694
Mike Stump