History log of /external/clang/test/Analysis/analyzer-config.c
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
258277d5a922e06ef523f7805900689b680ddc7d 18-Apr-2013 Jordan Rose <jordan_rose@apple.com> [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>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179767 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/analyzer-config.c
11983018670eb6c1e02dd497f5df37117cfa28fb 16-Apr-2013 Ted Kremenek <kremenek@apple.com> Make test portable.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179635 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/analyzer-config.c
08a838d16825159f7d0ae20d171aa5b3ebab3939 16-Apr-2013 Ted Kremenek <kremenek@apple.com> [analyzer] Add experimental option "leak-diagnostics-reference-allocation".

This is an opt-in tweak for leak diagnostics to reference the allocation
site if the diagnostic consumer only wants a pithy amount of information,
and not the entire path.

This is a strawman enhancement that I expect to see some experimentation
with over the next week, and can go away if we don't want it.

Currently it is only used by RetainCountChecker, but could be used
by MallocChecker if and when we decide this should stay in.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179634 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/analyzer-config.c
0f5c5c60e9806d13f0907cd99d7204ffab0e08f7 29-Mar-2013 Ted Kremenek <kremenek@apple.com> Add static analyzer support for conditionally executing static initializers.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178318 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/analyzer-config.c
ac3a3e7a402cd349dd2b7d70cd92c5fe702ae831 30-Jan-2013 Anna Zaks <ganna@apple.com> [analyzer] Make shallow mode more shallow.

Redefine the shallow mode to inline all functions for which we have a
definite definition (ipa=inlining). However, only inline functions that
are up to 4 basic blocks large and cut the max exploded nodes generated
per top level function in half.

This makes shallow faster and allows us to keep inlining small
functions. For example, we would keep inlining wrapper functions and
constructors/destructors.

With the new shallow, it takes 104s to analyze sqlite3, whereas
the deep mode is 658s and previous shallow is 209s.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173958 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/analyzer-config.c
6bbe1442a5f3f5f761582a9005e9edf1d49c4da2 30-Jan-2013 Anna Zaks <ganna@apple.com> [analyzer] Use analyzer config for max-inlinable-size option.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173957 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/analyzer-config.c
d130140cb7bce73b4350c5d50495443abe38418a 25-Jan-2013 Anna Zaks <ganna@apple.com> [analyzer] Add "-analyzer-config mode=[deep|shallow] ".

The idea is to introduce a higher level "user mode" option for
different use scenarios. For example, if one wants to run the analyzer
for a small project each time the code is built, they would use
the "shallow" mode.

The user mode option will influence the default settings for the
lower-level analyzer options. For now, this just influences the ipa
modes, but we plan to find more optimal settings for them.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173386 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/analyzer-config.c
bfa9ab8183e2fdc74f8633d758cb0c6201314320 25-Jan-2013 Anna Zaks <ganna@apple.com> [analyzer] Replace "-analyzer-ipa" with "-analyzer-config ipa".

The idea is to eventually place all analyzer options under
"analyzer-config". In addition, this lays the ground for introduction of
a high-level analyzer mode option, which will influence the
default setting for IPAMode.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173385 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/analyzer-config.c
7959671d456c916706a5f61af609d8f1fc95decf 17-Dec-2012 Anna Zaks <ganna@apple.com> [analyzer] Implement "do not inline large functions many times"
performance heuristic

After inlining a function with more than 13 basic blocks 32 times, we
are not going to inline it anymore. The idea is that inlining large
functions leads to drastic performance implications. Since the function
has already been inlined, we know that we've analyzed it in many
contexts.

The following metrics are used:
- Large function is a function with more than 13 basic blocks (we
should switch to another metric, like cyclomatic complexity)
- We consider that we've inlined a function many times if it's been
inlined 32 times. This number is configurable with -analyzer-config
max-times-inline-large=xx

This heuristic addresses a performance regression introduced with
inlining on one benchmark. The analyzer on this benchmark became 60
times slower with inlining turned on. The heuristic allows us to analyze
it in 24% of the time. The performance improvements on the other
benchmarks I've tested with are much lower - under 10%, which is
expected.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170361 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/analyzer-config.c
4d9e497a2b1eab3b1214848216050c64fc3acfd6 24-Oct-2012 Jordan Rose <jordan_rose@apple.com> [analyzer] Replace -analyzer-no-eagerly-trim-egraph with graph-trim-interval.

After every 1000 CFGElements processed, the ExplodedGraph trims out nodes
that satisfy a number of criteria for being "boring" (single predecessor,
single successor, and more). Rather than controlling this with a cc1 option,
which can only disable this behavior, we now have an analyzer-config option,
'graph-trim-interval', which can change this interval from 1000 to something
else. Setting the value to 0 disables reclamation.

The next commit relies on this behavior to actually test anything.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166528 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/analyzer-config.c
94bb74cef72a33d77c5d6739abfc0840c781eb8e 02-Oct-2012 Ted Kremenek <kremenek@apple.com> Tweak AnalyzerOptions::getOptionAsInteger() to populate the string
table, making it printable with the ConfigDump checker. Along the
way, fix a really serious bug where the value was getting parsed
from the string in code that was in an assert() call. This means
in a Release-Asserts build this code wouldn't work as expected.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165041 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/analyzer-config.c
622b6fb0a1d280c16e135c7e427b79cafffbde1f 01-Oct-2012 Ted Kremenek <kremenek@apple.com> Have AnalyzerOptions::getBooleanOption() stick the matching config
string in the config table so that it can be dumped as part of the
config dumper. Add a test to show that these options are sticking
and can be cross-checked using FileCheck.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164954 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/analyzer-config.c