maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Analysis/analyzer-config.cpp

46 lines
1.5 KiB
C++
Raw Normal View History

Reland 4: [analyzer] NFC: Update test infrastructure to support multiple constraint managers Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952. Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits Differential Revision: https://reviews.llvm.org/D30373 llvm-svn: 296895
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
Change AnalyzerOptions::mayInlineCXXMemberFunction to default populate the config string table. Also setup a test for dumping the analyzer configuration for C++. llvm-svn: 165040
2012-10-03 04:31:52 +08:00
// RUN: FileCheck --input-file=%t %s
void bar() {}
[analyzer] Add -analyzer-config option for function size the inliner considers as large Add an option (-analyzer-config min-blocks-for-inline-large=14) to control the function size the inliner considers as large, in relation to "max-times-inline-large". The option defaults to the original hard coded behaviour, which I believe should be adjustable with the other inlining settings. The analyzer-config test has been modified so that the analyzer will reach the getMinBlocksForInlineLarge() method and store the result in the ConfigTable, to ensure it is dumped by the debug checker. A patch by Sean Eveson! Differential Revision: http://reviews.llvm.org/D12406 llvm-svn: 247463
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();
}
}
Change AnalyzerOptions::mayInlineCXXMemberFunction to default populate the config string table. Also setup a test for dumping the analyzer configuration for C++. llvm-svn: 165040
2012-10-03 04:31:52 +08:00
class Foo {
public:
void bar() {}
void foo() { bar(); }
};
// CHECK: [config]
[analyzer] For now, don't inline [cd]tors of C++ containers. This is a heuristic to make up for the fact that the analyzer doesn't model C++ containers very well. One example is modeling that 'std::distance(I, E) == 0' implies 'I == E'. In the future, it would be nice to model this explicitly, but for now it just results in a lot of false positives. The actual heuristic checks if the base type has a member named 'begin' or 'iterator'. If so, we treat the constructors and destructors of that type as opaque, rather than inlining them. This is intended to drastically reduce the number of false positives reported with experimental destructor support turned on. We can tweak the heuristic in the future, but we'd rather err on the side of false negatives for now. <rdar://problem/13497258> llvm-svn: 178516
2013-04-02 08:26:35 +08:00
// CHECK-NEXT: c++-container-inlining = false
[analyzer] Enable destructor inlining by default (c++-inlining=destructors). This turns on not only destructor inlining, but inlining of constructors for types with non-trivial destructors. Per r178516, we will still not inline the constructor or destructor of anything that looks like a container unless the analyzer-config option 'c++-container-inlining' is set to 'true'. In addition to the more precise path-sensitive model, this allows us to catch simple smart pointer issues: #include <memory> void test() { std::auto_ptr<int> releaser(new int[4]); } // memory allocated with 'new[]' should not be deleted with 'delete' <rdar://problem/12295363> llvm-svn: 178805
2013-04-05 07:10:29 +08:00
// CHECK-NEXT: c++-inlining = destructors
[analyzer] Don't inline ~shared_ptr. The analyzer can't see the reference count for shared_ptr, so it doesn't know whether a given destruction is going to delete the referenced object. This leads to spurious leak and use-after-free warnings. For now, just ban destructors named '~shared_ptr', which catches std::shared_ptr, std::tr1::shared_ptr, and boost::shared_ptr. PR15987 llvm-svn: 182071
2013-05-17 10:16:49 +08:00
// CHECK-NEXT: c++-shared_ptr-inlining = false
Change AnalyzerOptions::mayInlineCXXMemberFunction to default populate the config string table. Also setup a test for dumping the analyzer configuration for C++. llvm-svn: 165040
2012-10-03 04:31:52 +08:00
// CHECK-NEXT: c++-stdlib-inlining = true
// CHECK-NEXT: c++-template-inlining = true
Add static analyzer support for conditionally executing static initializers. llvm-svn: 178318
2013-03-29 08:09:28 +08:00
// CHECK-NEXT: cfg-conditional-static-initializers = true
CFG: Add CFGElement for automatic variables that leave the scope Summary: This mimics the implementation for the implicit destructors. The generation of this scope leaving elements is hidden behind a flag to the CFGBuilder, thus it should not affect existing code. Currently, I'm missing a test (it's implicitly tested by the clang-tidy lifetime checker that I'm proposing). I though about a test using debug.DumpCFG, but then I would have to add an option to StaticAnalyzer/Core/AnalyzerOptions to enable the scope leaving CFGElement, which would only be useful to that particular test. Any other ideas how I could make a test for this feature? Reviewers: krememek, jordan_rose Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D15031 llvm-svn: 307759
2017-07-12 15:04:19 +08:00
// CHECK-NEXT: cfg-implicit-dtors = true
// CHECK-NEXT: cfg-lifetime = false
[CFG] Add LoopExit information to CFG This patch introduces a new CFG element CFGLoopExit that indicate when a loop ends. It does not deal with returnStmts yet (left it as a TODO). It hidden behind a new analyzer-config flag called cfg-loopexit (false by default). Test cases added. The main purpose of this patch right know is to make loop unrolling and loop widening easier and more efficient. However, this information can be useful for future improvements in the StaticAnalyzer core too. Differential Revision: https://reviews.llvm.org/D35668 llvm-svn: 311235
2017-08-19 19:19:16 +08:00
// CHECK-NEXT: cfg-loopexit = false
Revert "[analyzer] Add very limited support for temporary destructors" The analyzer doesn't currently expect CFG blocks with terminators to be empty, but this can happen when generating conditional destructors for a complex logical expression, such as (a && (b || Temp{})). Moreover, the branch conditions for these expressions are not persisted in the state. Even for handling noreturn destructors this needs more work. This reverts r186498. llvm-svn: 186925
2013-07-23 10:15:11 +08:00
// CHECK-NEXT: cfg-temporary-dtors = false
Change AnalyzerOptions::mayInlineCXXMemberFunction to default populate the config string table. Also setup a test for dumping the analyzer configuration for C++. llvm-svn: 165040
2012-10-03 04:31:52 +08:00
// CHECK-NEXT: faux-bodies = true
[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. llvm-svn: 166528
2012-10-24 07:59:05 +08:00
// CHECK-NEXT: graph-trim-interval = 1000
[analyzer] Add -analyzer-config option for function size the inliner considers as large Add an option (-analyzer-config min-blocks-for-inline-large=14) to control the function size the inliner considers as large, in relation to "max-times-inline-large". The option defaults to the original hard coded behaviour, which I believe should be adjustable with the other inlining settings. The analyzer-config test has been modified so that the analyzer will reach the getMinBlocksForInlineLarge() method and store the result in the ConfigTable, to ensure it is dumped by the debug checker. A patch by Sean Eveson! Differential Revision: http://reviews.llvm.org/D12406 llvm-svn: 247463
2015-09-12 04:14:05 +08:00
// CHECK-NEXT: inline-lambdas = true
[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. llvm-svn: 173385
2013-01-25 07:15:30 +08:00
// CHECK-NEXT: ipa = dynamic-bifurcate
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. llvm-svn: 165041
2012-10-03 04:31:56 +08:00
// CHECK-NEXT: ipa-always-inline-size = 3
[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. llvm-svn: 179634
2013-04-17 05:44:22 +08:00
// CHECK-NEXT: leak-diagnostics-reference-allocation = false
[analyzer] Bump a few default performance thresholds. This makes the analyzer around 10% slower by default, allowing it to find deeper bugs. Default values for the following -analyzer-config change: max-nodes: 150000 -> 225000; max-inlinable-size: 50 -> 100. rdar://problem/32539666 Differential Revision: https://reviews.llvm.org/D34277 llvm-svn: 305900
2017-06-21 19:29:35 +08:00
// CHECK-NEXT: max-inlinable-size = 100
// CHECK-NEXT: max-nodes = 225000
[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. llvm-svn: 170361
2012-12-18 04:08:51 +08:00
// CHECK-NEXT: max-times-inline-large = 32
[analyzer] Add -analyzer-config option for function size the inliner considers as large Add an option (-analyzer-config min-blocks-for-inline-large=14) to control the function size the inliner considers as large, in relation to "max-times-inline-large". The option defaults to the original hard coded behaviour, which I believe should be adjustable with the other inlining settings. The analyzer-config test has been modified so that the analyzer will reach the getMinBlocksForInlineLarge() method and store the result in the ConfigTable, to ensure it is dumped by the debug checker. A patch by Sean Eveson! Differential Revision: http://reviews.llvm.org/D12406 llvm-svn: 247463
2015-09-12 04:14:05 +08:00
// CHECK-NEXT: min-cfg-size-treat-functions-as-large = 14
[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. llvm-svn: 173386
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
[StaticAnalyzer] Completely unrolling specific loops with known bound option This feature allows the analyzer to consider loops to completely unroll. New requirements/rules (for unrolling) can be added easily via ASTMatchers. Right now it is hidden behind a flag, the aim is to find the correct heuristic and create a solution which results higher coverage % and more precise analysis, thus can be enabled by default. Right now the blocks which belong to an unrolled loop are marked by the LoopVisitor which adds them to the ProgramState. Then whenever we encounter a CFGBlock in the processCFGBlockEntrance which is marked then we skip its investigating. That means, it won't be considered to be visited more than the maximal bound for visiting since it won't be checked. llvm-svn: 309006
2017-07-26 03:23:23 +08:00
// CHECK-NEXT: unroll-loops = false
Reapply r251621 "[Analyzer] Widening loops which do not exit" It was not the cause of the build bot failure. llvm-svn: 251702
2015-10-30 23:23:57 +08:00
// CHECK-NEXT: widen-loops = false
Change AnalyzerOptions::mayInlineCXXMemberFunction to default populate the config string table. Also setup a test for dumping the analyzer configuration for C++. llvm-svn: 165040
2012-10-03 04:31:52 +08:00
// CHECK-NEXT: [stats]
[CFG] Add LoopExit information to CFG This patch introduces a new CFG element CFGLoopExit that indicate when a loop ends. It does not deal with returnStmts yet (left it as a TODO). It hidden behind a new analyzer-config flag called cfg-loopexit (false by default). Test cases added. The main purpose of this patch right know is to make loop unrolling and loop widening easier and more efficient. However, this information can be useful for future improvements in the StaticAnalyzer core too. Differential Revision: https://reviews.llvm.org/D35668 llvm-svn: 311235
2017-08-19 19:19:16 +08:00
// CHECK-NEXT: num-entries = 24