diff options
Diffstat (limited to 'docs/analyzer/IPA.txt')
-rw-r--r-- | docs/analyzer/IPA.txt | 105 |
1 files changed, 68 insertions, 37 deletions
diff --git a/docs/analyzer/IPA.txt b/docs/analyzer/IPA.txt index 016cea9..01e73ce 100644 --- a/docs/analyzer/IPA.txt +++ b/docs/analyzer/IPA.txt @@ -2,36 +2,37 @@ Inlining ======== There are several options that control which calls the analyzer will consider for -inlining. The major one is -analyzer-ipa: +inlining. The major one is -analyzer-config ipa: - -analyzer-ipa=none - All inlining is disabled. This is the only mode available - in LLVM 3.1 and earlier and in Xcode 4.3 and earlier. + -analyzer-config ipa=none - All inlining is disabled. This is the only mode + available in LLVM 3.1 and earlier and in Xcode 4.3 and earlier. - -analyzer-ipa=basic-inlining - Turns on inlining for C functions, C++ static - member functions, and blocks -- essentially, the calls that behave like - simple C function calls. This is essentially the mode used in Xcode 4.4. + -analyzer-config ipa=basic-inlining - Turns on inlining for C functions, C++ + static member functions, and blocks -- essentially, the calls that behave + like simple C function calls. This is essentially the mode used in + Xcode 4.4. - -analyzer-ipa=inlining - Turns on inlining when we can confidently find the - function/method body corresponding to the call. (C functions, static + -analyzer-config ipa=inlining - Turns on inlining when we can confidently find + the function/method body corresponding to the call. (C functions, static functions, devirtualized C++ methods, Objective-C class methods, Objective-C instance methods when ExprEngine is confident about the dynamic type of the instance). - -analyzer-ipa=dynamic - Inline instance methods for which the type is + -analyzer-config ipa=dynamic - Inline instance methods for which the type is determined at runtime and we are not 100% sure that our type info is correct. For virtual calls, inline the most plausible definition. - -analyzer-ipa=dynamic-bifurcate - Same as -analyzer-ipa=dynamic, but the path - is split. We inline on one branch and do not inline on the other. This mode - does not drop the coverage in cases when the parent class has code that is - only exercised when some of its methods are overridden. + -analyzer-config ipa=dynamic-bifurcate - Same as -analyzer-config ipa=dynamic, + but the path is split. We inline on one branch and do not inline on the + other. This mode does not drop the coverage in cases when the parent class + has code that is only exercised when some of its methods are overridden. -Currently, -analyzer-ipa=dynamic-bifurcate is the default mode. +Currently, -analyzer-config ipa=dynamic-bifurcate is the default mode. -While -analyzer-ipa determines in general how aggressively the analyzer will try to -inline functions, several additional options control which types of functions can -inlined, in an all-or-nothing way. These options use the analyzer's configuration -table, so they are all specified as follows: +While -analyzer-config ipa determines in general how aggressively the analyzer +will try to inline functions, several additional options control which types of +functions can inlined, in an all-or-nothing way. These options use the +analyzer's configuration table, so they are all specified as follows: -analyzer-config OPTION=VALUE @@ -45,10 +46,14 @@ Each of these modes implies that all the previous member function kinds will be inlined as well; it doesn't make sense to inline destructors without inlining constructors, for example. -The default c++-inlining mode is 'methods', meaning only regular member -functions and overloaded operators will be inlined. Note that no C++ member -functions will be inlined under -analyzer-ipa=none or --analyzer-ipa=basic-inlining. +The default c++-inlining mode is 'destructors', meaning that all member +functions with visible definitions will be considered for inlining. In some +cases the analyzer may still choose not to inline the function. + +Note that under 'constructors', constructors for types with non-trivial +destructors will not be inlined. Additionally, no C++ member functions will be +inlined under -analyzer-config ipa=none or -analyzer-config ipa=basic-inlining, +regardless of the setting of the c++-inlining mode. ### c++-template-inlining ### @@ -71,7 +76,8 @@ considered for inlining. -analyzer-config c++-template-inlining=[true | false] -Currently, C++ standard library functions are NOT considered for inlining by default. +Currently, C++ standard library functions are considered for inlining by +default. The standard library functions and the STL in particular are used ubiquitously enough that our tolerance for false positives is even lower here. A false @@ -79,6 +85,31 @@ positive due to poor modeling of the STL leads to a poor user experience, since most users would not be comfortable adding assertions to system headers in order to silence analyzer warnings. +### c++-container-inlining ### + +This option controls whether constructors and destructors of "container" types +should be considered for inlining. + + -analyzer-config c++-container-inlining=[true | false] + +Currently, these constructors and destructors are NOT considered for inlining +by default. + +The current implementation of this setting checks whether a type has a member +named 'iterator' or a member named 'begin'; these names are idiomatic in C++, +with the latter specified in the C++11 standard. The analyzer currently does a +fairly poor job of modeling certain data structure invariants of container-like +objects. For example, these three expressions should be equivalent: + + std::distance(c.begin(), c.end()) == 0 + c.begin() == c.end() + c.empty()) + +Many of these issues are avoided if containers always have unknown, symbolic +state, which is what happens when their constructors are treated as opaque. +In the future, we may decide specific containers are "safe" to model through +inlining, or choose to model them directly using checkers instead. + Basics of Implementation ----------------------- @@ -229,31 +260,31 @@ inlined. == Inlining Dynamic Calls == -The -analyzer-ipa option has five different modes: none, basic-inlining, -inlining, dynamic, and dynamic-bifurcate. Under -analyzer-ipa=dynamic, all -dynamic calls are inlined, whether we are certain or not that this will actually -be the definition used at runtime. Under -analyzer-ipa=inlining, only -"near-perfect" devirtualized calls are inlined*, and other dynamic calls are -evaluated conservatively (as if no definition were available). +The -analyzer-config ipa option has five different modes: none, basic-inlining, +inlining, dynamic, and dynamic-bifurcate. Under -analyzer-config ipa=dynamic, +all dynamic calls are inlined, whether we are certain or not that this will +actually be the definition used at runtime. Under -analyzer-config ipa=inlining, +only "near-perfect" devirtualized calls are inlined*, and other dynamic calls +are evaluated conservatively (as if no definition were available). * Currently, no Objective-C messages are not inlined under - -analyzer-ipa=inlining, even if we are reasonably confident of the type of the - receiver. We plan to enable this once we have tested our heuristics more - thoroughly. + -analyzer-config ipa=inlining, even if we are reasonably confident of the type + of the receiver. We plan to enable this once we have tested our heuristics + more thoroughly. -The last option, -analyzer-ipa=dynamic-bifurcate, behaves similarly to +The last option, -analyzer-config ipa=dynamic-bifurcate, behaves similarly to "dynamic", but performs a conservative invalidation in the general virtual case in *addition* to inlining. The details of this are discussed below. -As stated above, -analyzer-ipa=basic-inlining does not inline any C++ member -functions or Objective-C method calls, even if they are non-virtual or can be -safely devirtualized. +As stated above, -analyzer-config ipa=basic-inlining does not inline any C++ +member functions or Objective-C method calls, even if they are non-virtual or +can be safely devirtualized. Bifurcation ----------- -ExprEngine::BifurcateCall implements the -analyzer-ipa=dynamic-bifurcate +ExprEngine::BifurcateCall implements the -analyzer-config ipa=dynamic-bifurcate mode. When a call is made on an object with imprecise dynamic type information |