replica
/
hanchenye-llvm-project
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
hanchenye-llvm-project/clang/test/Analysis/analyzer-config.cpp

33 lines
1.0 KiB
C++
Raw Normal View History

Make test portable. llvm-svn: 179635
2013-04-17 05:59:21 +08:00
// RUN: %clang -target x86_64-apple-darwin10 --analyze %s -o /dev/null -Xclang -analyzer-checker=debug.ConfigDumper > %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() {}
void foo() { bar(); }
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
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] 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] Use analyzer config for max-inlinable-size option. llvm-svn: 173957
2013-01-31 03:12:36 +08:00
// CHECK-NEXT: max-inlinable-size = 50
[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. llvm-svn: 173958
2013-01-31 03:12:39 +08:00
// CHECK-NEXT: max-nodes = 150000
[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 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
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]
[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: num-entries = 17