If (root->getRight()->getLeft()->getValue() = 2) //Pointer may be nullĪll existing analyses also benefit from the changes. If (root->getLeft()->getRight()->getValue() = 2) //Condition is always true Tree(Tree* l, Tree* r, int val): left(l), right(r), value(val) Īuto *root = new Tree(new Tree(new Tree(1), new Tree(2), 3), new Tree(4), 5) To demonstrate the power of the new analysis in CLion, let’s look at the following example: ![]() Now, the summaries of each function keep track of which fields are input and which are output, so the heap of the program is now modeled more precisely.Īll the described changes made our analysis truly interprocedural and simultaneously more performant. The introduction of function summaries helped us make analysis faster and more precise.Īdopting this approach also allowed us to support fields in our analysis. The behavior of the function in different contexts is usually called the function summary. These contexts don’t depend on the function’s call sites and completely describe the function’s semantics. For example, the following function has two contexts, one for c.x > 10 and another one for c.x 10) If a function depends on certain input values (parameters, global variables, fields, or conditions on these input values), then it has several contexts – one for each input. These “internal” contexts are defined by the function itself rather than its callees. The current function summaries approach uses “internal” contexts rather than “external”. This led to slow analysis and high memory usage. Obviously, for any non-trivial program, there are too many call sites. If you called function A from another function B and then called function B from several call sites, their contexts were merged and that led to a loss of accuracy: Although that approach did have greater precision than the context-insensitive analysis (which doesn’t take the call site into account), it had several disadvantages.įirst, only contexts of depth 1 were handled. That means all call sites for a given function were treated differently. For each function, it formed several “external” contexts defined by the function call site. It handled function calls and the flow of data through functions’ arguments/parameters and return values. In the previous CLion release, our DFA was already interprocedural. We’ve implemented something called a function summaries approach, which allowed us to distinguish different function contexts for arbitrary nested call chains, resulting in more accurate analysis. ![]() In CLion 2023.3, which is currently in Early Preview, we’ve completely reworked CLion’s DFA to make the analysis faster and more accurate. Introducing function summaries in data flow analysis Striving For Better C++ Code, Part II: Function Summaries to Speed Up the Data Flow Analysis (this one). ![]() Striving For Better C++ Code, Part I: Data Flow Analysis Basics.This is the second blog post in the series dedicated to Data Flow Analysis (DFA) and its implementation in CLion.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |