2017-03-04 02:02:02 +08:00
|
|
|
// RUN: %clang_analyze_cc1 -triple x86_64-apple-darwin10 %s -o /dev/null -analyzer-checker=core,osx.cocoa,debug.ConfigDumper -analyzer-max-loop 34 > %t 2>&1
|
2018-02-27 09:31:56 +08:00
|
|
|
// RUN: FileCheck --input-file=%t %s --match-full-lines
|
2012-10-02 02:28:19 +08:00
|
|
|
|
|
|
|
|
void bar() {}
|
2015-09-12 04:14:05 +08:00
|
|
|
void foo() {
|
|
|
|
|
// Call bar 33 times so max-times-inline-large is met and
|
|
|
|
|
// min-blocks-for-inline-large is checked
|
|
|
|
|
for (int i = 0; i < 34; ++i) {
|
|
|
|
|
bar();
|
|
|
|
|
}
|
|
|
|
|
}
|
2012-10-02 02:28:19 +08:00
|
|
|
|
|
|
|
|
// CHECK: [config]
|
2013-03-29 08:09:28 +08:00
|
|
|
// CHECK-NEXT: cfg-conditional-static-initializers = true
|
2017-07-12 15:04:19 +08:00
|
|
|
// CHECK-NEXT: cfg-implicit-dtors = true
|
|
|
|
|
// CHECK-NEXT: cfg-lifetime = false
|
2017-08-19 19:19:16 +08:00
|
|
|
// CHECK-NEXT: cfg-loopexit = false
|
[CFG] Add extra context to C++ constructor statement elements.
This patch adds a new CFGStmt sub-class, CFGConstructor, which replaces
the regular CFGStmt with CXXConstructExpr in it whenever the CFG has additional
information to provide regarding what sort of object is being constructed.
It is useful for figuring out what memory is initialized in client of the
CFG such as the Static Analyzer, which do not operate by recursive AST
traversal, but instead rely on the CFG to provide all the information when they
need it. Otherwise, the statement that triggers the construction and defines
what memory is being initialized would normally occur after the
construct-expression, and the client would need to peek to the next CFG element
or use statement parent map to understand the necessary facts about
the construct-expression.
As a proof of concept, CFGConstructors are added for new-expressions
and the respective test cases are provided to demonstrate how it works.
For now, the only additional data contained in the CFGConstructor element is
the "trigger statement", such as new-expression, which is the parent of the
constructor. It will be significantly expanded in later commits. The additional
data is organized as an auxiliary structure - the "construction context",
which is allocated separately from the CFGElement.
Differential Revision: https://reviews.llvm.org/D42672
llvm-svn: 324668
2018-02-09 06:58:15 +08:00
|
|
|
// CHECK-NEXT: cfg-rich-constructors = true
|
2018-03-12 20:26:15 +08:00
|
|
|
// CHECK-NEXT: cfg-scopes = false
|
2018-03-02 02:53:13 +08:00
|
|
|
// CHECK-NEXT: cfg-temporary-dtors = true
|
2018-02-27 09:31:56 +08:00
|
|
|
// CHECK-NEXT: exploration_strategy = unexplored_first_queue
|
2012-10-02 02:28:19 +08:00
|
|
|
// CHECK-NEXT: faux-bodies = true
|
2012-10-24 07:59:05 +08:00
|
|
|
// CHECK-NEXT: graph-trim-interval = 1000
|
2015-09-12 04:14:05 +08:00
|
|
|
// CHECK-NEXT: inline-lambdas = true
|
2013-01-25 07:15:30 +08:00
|
|
|
// CHECK-NEXT: ipa = dynamic-bifurcate
|
2012-10-03 04:31:56 +08:00
|
|
|
// CHECK-NEXT: ipa-always-inline-size = 3
|
2013-04-17 05:44:22 +08:00
|
|
|
// CHECK-NEXT: leak-diagnostics-reference-allocation = false
|
2017-06-21 19:29:35 +08:00
|
|
|
// CHECK-NEXT: max-inlinable-size = 100
|
|
|
|
|
// CHECK-NEXT: max-nodes = 225000
|
2012-12-18 04:08:51 +08:00
|
|
|
// CHECK-NEXT: max-times-inline-large = 32
|
2015-09-12 04:14:05 +08:00
|
|
|
// CHECK-NEXT: min-cfg-size-treat-functions-as-large = 14
|
2013-01-25 07:15:34 +08:00
|
|
|
// CHECK-NEXT: mode = deep
|
[analyzer] "Force" LazyCompoundVals on bind when they are simple enough.
The analyzer uses LazyCompoundVals to represent rvalues of aggregate types,
most importantly structs and arrays. This allows us to efficiently copy
around an entire struct, rather than doing a memberwise load every time a
struct rvalue is encountered. This can also keep memory usage down by
allowing several structs to "share" the same snapshotted bindings.
However, /lookup/ through LazyCompoundVals can be expensive, especially
since they can end up chaining back to the original value. While we try
to reuse LazyCompoundVals whenever it's safe, and cache information about
this transitivity, the fact is it's sometimes just not a good idea to
perpetuate LazyCompoundVals -- the tradeoffs just aren't worth it.
This commit changes RegionStore so that binding a LazyCompoundVal to struct
will do a memberwise copy if the struct is simple enough. Today's definition
of "simple enough" is "up to N scalar members" (see below), but that could
easily be changed in the future. This is enough to bring the test case in
PR15697 back down to a manageable analysis time (within 20% of its original
time, in an unfair test where the new analyzer is not compiled with LTO).
The actual value of "N" is controlled by a new -analyzer-config option,
'region-store-small-struct-limit'. It defaults to "2", meaning structs with
zero, one, or two scalar members will be considered "simple enough" for
this code path.
It's worth noting that a more straightforward implementation would do this
on load, not on bind, and make use of the structure we already have for this:
CompoundVal. A long time ago, this was actually how RegionStore modeled
aggregate-to-aggregate copies, but today it's only used for compound literals.
Unfortunately, it seems that we've special-cased LazyCompoundVal in certain
places (such as liveness checks) but failed to similarly special-case
CompoundVal in all of them. Until we're confident that CompoundVal is
handled properly everywhere, this solution is safer, since the entire
optimization is just an implementation detail of RegionStore.
<rdar://problem/13599304>
llvm-svn: 179767
2013-04-19 00:33:46 +08:00
|
|
|
// CHECK-NEXT: region-store-small-struct-limit = 2
|
2018-02-10 09:49:20 +08:00
|
|
|
// CHECK-NEXT: serialize-stats = false
|
2017-07-26 03:23:23 +08:00
|
|
|
// CHECK-NEXT: unroll-loops = false
|
2015-10-30 23:23:57 +08:00
|
|
|
// CHECK-NEXT: widen-loops = false
|
2012-10-02 02:28:19 +08:00
|
|
|
// CHECK-NEXT: [stats]
|
2018-03-12 20:26:15 +08:00
|
|
|
// CHECK-NEXT: num-entries = 23
|