Skip to main content

Uday Khedker

Followers

29

Following

2

Public Views

Interests

Uploads

Papers by Uday Khedker

Computing maximum fixed point solutions over feasible paths in data flow analyses

Science of Computer Programming

The control flow graph (CFG) representation of a procedure used by virtually all flow-sensitive p... more The control flow graph (CFG) representation of a procedure used by virtually all flow-sensitive program analyses, admits a large number of infeasible control flow paths i.e., these paths do not occur in any execution of the program. Hence the information reaching along infeasible paths in an analysis is spurious. This affects the precision of the conventional maximum fixed point (MFP) solution of the data flow analysis, because it includes the information reaching along all control flow paths. The existing approaches for removing this imprecision are either specific to a data flow problem with no straightforward generalization or involve control flow graph restructuring which may exponentially blow up the size of the CFG. We lift the notion of MFP solution to define the notion of feasible path MFP (FPMFP) solutions that exclude the data flowing along known infeasible paths. The notion of FPMFP is generic and does not involve CFG restructuring. Instead, it takes externally supplied information about infeasible paths and lifts any data flow analysis to an analysis that maintains the distinctions between different paths where these distinctions are beneficial, and ignores them where they are not. Thus it gets the benefit of a path-sensitive analysis where it is useful without performing a conventional path-sensitive analysis. Hence, an FPMFP solution is more precise than the corresponding MFP solution in most cases; it is guaranteed to be sound in each case. We implemented the proposed computation of feasible path MFP solutions for reaching definitions analysis and potentially uninitialized variable analysis. We evaluated the precision improvement in these two analyses by analyzing 30 benchmark applications selected from open source, industry, and SPEC CPU 2006. The evaluation results indicate that the precision improvement in these two analyses respectively reduce the number def-use pairs by up to 13.6% (average 2.87%, geometric mean 1.75%), and reduce the potentially uninitialized variable alarms by up to 100% (average 18.5%, geo. mean 3%). We found that the FPMFP computation time was 2.9× of the MFP computation time on average.

Computing Maximum Fixed Point Solutions over Feasible Paths in Data Flow Analyses

arXiv (Cornell University), Aug 26, 2022

The control flow graph (CFG) representation of a procedure used by virtually all flow-sensitive p... more The control flow graph (CFG) representation of a procedure used by virtually all flow-sensitive program analyses, admits a large number of infeasible control flow paths i.e., these paths do not occur in any execution of the program. Hence the information reaching along infeasible paths in an analysis is spurious. This affects the precision of the conventional maximum fixed point (MFP) solution of the data flow analysis, because it includes the information reaching along all control flow paths. The existing approaches for removing this imprecision are either specific to a data flow problem with no straightforward generalization or involve control flow graph restructuring which may exponentially blow up the size of the CFG. We lift the notion of MFP solution to define the notion of feasible path MFP (FPMFP) solutions that exclude the data flowing along known infeasible paths. The notion of FPMFP is generic and does not involve CFG restructuring. Instead, it takes externally supplied information about infeasible paths and lifts any data flow analysis to an analysis that maintains the distinctions between different paths where these distinctions are beneficial, and ignores them where they are not. Thus it gets the benefit of a path-sensitive analysis where it is useful without performing a conventional path-sensitive analysis. Hence, an FPMFP solution is more precise than the corresponding MFP solution in most cases; it is guaranteed to be sound in each case. We implemented the proposed computation of feasible path MFP solutions for reaching definitions analysis and potentially uninitialized variable analysis. We evaluated the precision improvement in these two analyses by analyzing 30 benchmark applications selected from open source, industry, and SPEC CPU 2006. The evaluation results indicate that the precision improvement in these two analyses respectively reduce the number def-use pairs by up to 13.6% (average 2.87%, geometric mean 1.75%), and reduce the potentially uninitialized variable alarms by up to 100% (average 18.5%, geo. mean 3%). We found that the FPMFP computation time was 2.9× of the MFP computation time on average.

Demand-driven Alias Analysis : Formalizing Bidirectional Analyses for Soundness and Precision

arXiv (Cornell University), Feb 3, 2018

A demand-driven approach to program analysis computes only the information that is needed to serv... more A demand-driven approach to program analysis computes only the information that is needed to serve a target demand. In contrast, an exhaustive approach computes all information in anticipation of it being used later. Demand-driven methods have primarily been viewed as efficient algorithms as they compute only the information that is required to meet a given set of demands. However, for a given set of demands, they are believed to compute the same information that would be computed by the corresponding exhaustive methods. We investigate the precision and bidirectional nature of demand-driven methods and show that: (a) demanddriven methods can be formalized inherently as bidirectional data flow analysis, and (b) for some analyses, demand-driven method can compute more precise information than the corresponding exhaustive method. The formalization as a bidirectional analysis follows because the demands are propagated against the control flow and the information to satisfy the demands is propagated along the control flow. We extend the formalization of the Meet Over Paths solution to bidirectional flows, by introducing the concept of qualified control flow paths to explicate the forward and backward flows. This formalization helps us to prove the soundness and precision of our analysis. The approximation caused by data abstraction used for heap locations (e.g. allocation-site-based abstraction or type-based abstraction) is a source of imprecision in pointer analysis. Since a demand-driven method computes information for a smaller set of demands, it has to deal with less imprecision caused by the data abstractions. This could lead to more precise results than an exhaustive method. We show that while this is indeed the case for Java, for C/C++, the precision critically hinges on how indirect assignments are handled. We use this insight and propose a demand-driven alias analysis that is more precise than an exhaustive analysis for C/C++ too. We have chosen static resolution of virtual function calls as an application to demonstrate the precision gain of our demand-driven alias analysis for C++. Our measurements show that our method is more precise and more efficient (for both allocation-site-based and type-based abstractions) than both, the existing demand-driven method, as well as the corresponding exhaustive method. This precision is measured in terms of the number of monomorphic call-sites, the number of virtual call edges, and the number of class types discovered by the methods.

Heap Reference Analysis for Functional Programs

arXiv (Cornell University), Oct 8, 2007

Current garbage collectors leave a lot of garbage uncollected because they conservatively approxi... more Current garbage collectors leave a lot of garbage uncollected because they conservatively approximate liveness by reachability from program variables. In this paper, we describe a sequence of static analyses that takes as input a program written in a first-order, eager functional programming language, and finds at each program point the references to objects that are guaranteed not to be used in the future. Such references are made null by a transformation pass. If this makes the object unreachable, it can be collected by the garbage collector. This causes more garbage to be collected, resulting in fewer collections. Additionally, for those garbage collectors which scavenge live objects, it makes each collection faster. The interesting aspects of our method are both in the identification of the analyses required to solve the problem and the way they are carried out. We identify three different analysesliveness, sharing and accessibility. In liveness and sharing analyses, the function definitions are analyzed independently of the calling context. This is achieved by using a variable to represent the unknown context of the function being analyzed and setting up constraints expressing the effect of the function with respect to the variable. The solution of the constraints is a summary of the function that is parameterized with respect to a calling context and is used to analyze function calls. As a result we achieve context sensitivity at call sites without analyzing the function multiple number of times.

Sliced Slices: Separating Data and Control Influences

arXiv (Cornell University), Jul 18, 2014

Backward slicing has been used extensively in program understanding, debugging and scaling up of ... more Backward slicing has been used extensively in program understanding, debugging and scaling up of program analysis. For large programs, the size of the conventional backward slice is about 25% of the program size. This may be too large to be useful. Our investigations reveal that in general, the size of a slice is influenced more by computations governing the control flow reaching the slicing criterion than by the computations governing the values relevant to the slicing criterion. We distinguish between the two by defining data slices and control slices both of which are smaller than the conventional slices which can be obtained by combining the two. This is useful because for many applications, the individual data or control slices are sufficient. Our experiments show that for more than 50% of cases, the data slice is smaller than 10% of the program in size. Besides, the time to compute data or control slice is comparable to that for computing the conventional slice.

Efficiency, Precision, Simplicity, and Generality in Interprocedural Data Flow Analysis: Resurrecting the Classical Call Strings Method

Springer eBooks, Apr 1, 2008

The full call strings method is the most general, simplest, and most precise method of performing... more The full call strings method is the most general, simplest, and most precise method of performing context sensitive interprocedural data flow analysis. It remembers contexts using call strings. For full precision, all call strings up to a prescribed length must be constructed. Two limitations of this method are (a) it cannot be used for frameworks with infinite lattices, and (b) the prescribed length is quadratic in the size of the lattice resulting in an impractically large number of call strings. These limitations have resulted in a proliferation of ad hoc methods which compromise on generality, precision, or simplicity. We propose a variant of the classical full call strings method which reduces the number of call strings, and hence the analysis time, by orders of magnitude as corroborated by our empirical measurements. It reduces the worst case call string length from quadratic in the size of the lattice to linear. Further, unlike the classical method, this worst case length need not be reached. Our approach retains the precision, generality, and simplicity of call strings method without imposing any additional constraints. It can accommodate demand-driven approximations and hence can be used for frameworks with infinite lattices. 6 Out S p c 1 , {x {y}, y / 0, z {x}} ... 7 Out C 3 c 1 c 3 , {x {y}, y {z}, z {x}} ... 8 In S q c 1 c 3 , {x {y}, y {z}, z {x}} ... 9 Out C 4 c 1 c 3 c 4 , {x {y}, y {z}, z {x}} ... 10 In S q c 1 c 3 , {x {y}, y {z}, z {x}} , c 1 c 3 c 4 , {x {y}, y {z}, z {x}} Point i New information at i 11 Out S q c 1 c 3 , {x {y}, y {z}, z {x}} ...

Scaling Bounded Model Checking By Transforming Programs With Arrays

arXiv (Cornell University), Aug 17, 2016

Bounded Model Checking is one the most successful techniques for finding bugs in program. However... more Bounded Model Checking is one the most successful techniques for finding bugs in program. However, for programs with loops iterating over largesized arrays, bounded model checkers often exceed the limit of resources available to them. We present a transformation that enables bounded model checkers to verify a certain class of array properties. Our technique transforms an array-manipulating program in ANSI-C to an array-free and loop-free program. The transformed program can efficiently be verified by an off-the-shelf bounded model checker. Though the transformed program is, in general, an abstraction of the original program, we formally characterize the properties for which the transformation is precise. We demonstrate the applicability and usefulness of our technique on both industry code as well as academic benchmarks.

Buffer Overflow Analysis for C

arXiv (Cornell University), Dec 17, 2014

Buffer overflow detection and mitigation for C programs has been an important concern for a long ... more Buffer overflow detection and mitigation for C programs has been an important concern for a long time. This paper defines a string buffer overflow analysis for C. The key ideas of our formulation are (a) separating buffers from the pointers that point to them, (b) modelling buffers in terms of sizes and sets of positions of null characters, and (c) defining stateless functions to compute the sets of null positions and mappings between buffers and pointers. This exercise has been carried out to test the feasibility of describing such an analysis in terms of lattice valued functions and relations to facilitate automatic construction of an analyser without the user having to write C/C++/Java code. This is facilitated by avoiding stateful formulations because they combine effects through side effects in states raising a natural requirement of C/C++/Java code to be written to describe them. Given the above motivation, the focus of this paper is not to build good static approximations for buffer overflow analysis but to show how given static approximations could be formalized in terms of stateless formulations so that they become amenable to automatic construction of analysers.

An Introduction to Data Flow Analysis

Data Flow Analysis, 2009

Generalized Points-to Graphs: A New Abstraction of Memory in the Presence of Pointers

ArXiv, 2018

Flow- and context-sensitive points-to analysis is difficult to scale; for top-down approaches, th... more Flow- and context-sensitive points-to analysis is difficult to scale; for top-down approaches, the problem centers on repeated analysis of the same procedure; for bottom-up approaches, the abstractions used to represent procedure summaries have not scaled while preserving precision. We propose a novel abstraction called the Generalized Points-to Graph (GPG) which views points-to relations as memory updates and generalizes them using the counts of indirection levels leaving the unknown pointees implicit. This allows us to construct GPGs as compact representations of bottom-up procedure summaries in terms of memory updates and control flow between them. Their compactness is ensured by the following optimizations: strength reduction reduces the indirection levels, redundancy elimination removes redundant memory updates and minimizes control flow (without over-approximating data dependence between memory updates), and call inlining enhances the opportunities of these optimizations. We d...

Theoretical Abstractions in Data Flow Analysis

• Tuples of the form η 1 , η 2 , . . . , η k where η i is the data flow value for i th variable U... more • Tuples of the form η 1 , η 2 , . . . , η k where η i is the data flow value for i th variable Unlike bit vector frameworks, value η i is not 0 or 1 (i.e. true or false). Instead, it is one of the following: ◮ ? indicating that not much is known about the constantness of variable v i ◮ × indicating that variable v i does not have a constant value ◮ An integer constant c 1 if the value of v i is known to be c 1 at compile time Aug 2017 IIT Bombay CS 618 DFA Theory: The Need for a More General Setting 7/126 Difference #2: Dependence of Data Flow Values Across Entities • In bit vector frameworks, data flow values of different entities are independent ◮ Liveness of variable b does not depend on that of any other variable ◮ Availability of expression a * b does not depend on that of any other expression • Given a statement a = b * c, can the constantness of a be determined independently of the constantness of b and c? No Aug 2017 IIT Bombay

Generalized Points-to Graphs

ACM Transactions on Programming Languages and Systems, 2020

Computing precise (fully flow- and context-sensitive) and exhaustive (as against demand-driven) p... more Computing precise (fully flow- and context-sensitive) and exhaustive (as against demand-driven) points-to information is known to be expensive. Top-down approaches require repeated analysis of a procedure for separate contexts. Bottom-up approaches need to model unknown pointees accessed indirectly through pointers that may be defined in the callers and hence do not scale while preserving precision. Therefore, most approaches to precise points-to analysis begin with a scalable but imprecise method and then seek to increase its precision. We take the opposite approach in that we begin with a precise method and increase its scalability. In a nutshell, we create naive but possibly non-scalable procedure summaries and then use novel optimizations to compact them while retaining their soundness and precision. For this purpose, we propose a novel abstraction called the generalized points-to graph (GPG), which views points-to relations as memory updates and generalizes them using the count...

Flow- and Context-Sensitive Points-To Analysis Using Generalized Points-To Graphs

Lecture Notes in Computer Science, 2016

Computing precise (fully flow-sensitive and context-sensitive) and exhaustive (as against demand ... more Computing precise (fully flow-sensitive and context-sensitive) and exhaustive (as against demand driven) points-to information is known to be computationally expensive. Therefore many practical tools approximate the points-to information trading precision for efficiency. This often has adverse impact on computationally intensive analyses such as model checking. Past explorations in top-down approaches of fully flow-and context-sensitive points-to analysis (FCPA) have not scaled. We explore the alternative of bottom-up interprocedural approach which constructs summary flow functions for procedures to represent the effect of their calls. This approach has been effectively used for many analyses. However, this approach seems computationally expensive for FCPA which requires modelling unknown locations accessed indirectly through pointers. Such accesses are commonly handled by using placeholders to explicate unknown locations or by using multiple call-specific summary flow functions. We generalize the concept of points-to relations by using the counts of indirection levels leaving the unknown locations implicit. This allows us to create summary flow functions in the form of generalized points-to graphs (GPGs) without the need of placeholders. By design, GPGs represent both memory (in terms of classical points-to facts) and memory transformers (in terms of generalized points-to facts). We perform FCPA by progressively reducing generalized points-to facts to classical points-to facts. GPGs distinguish between may and must pointer updates thereby facilitating strong updates within calling contexts. The size of GPG for a procedure is linearly bounded by the number of variables and is independent of the number of statements in the procedure. Empirical measurements on SPEC benchmarks show that GPGs are indeed compact in spite of large procedure sizes. This allows us to scale FCPA to 158 kLoC using GPGs (compared to 35 kLoC reported by liveness-based FCPA). At a practical level, GPGs hold a promise of efficiency and scalability for FCPA without compromising precision. At a more general level, GPGs provide a convenient abstraction of memory in presence of pointers. Static analyses that are influenced by pointers may be able to use GPGs by combining them with their original abstractions. CCS Concepts: •Theory of computation → Program analysis; •Software and its engineering → Imperative languages; Compilers; Software verification and validation; int ** x, ** y; int * z, * a, * b; int d, e, u, v, w; void f(); void g(); 01 void f() 02 { x = &a; 03 z = &w; 04 g();

Static Analysis of Programs: A Heap Centric View

Fourth IEEE International Conference on Software Engineering and Formal Methods (SEFM'06)

Data Flow Analysis

Optimizations and Machine Code Generation, 2002

The compiler needs to understand properties of a program (e.g. the set of variables "live" at a p... more The compiler needs to understand properties of a program (e.g. the set of variables "live" at a program point). This information should be computed at compile time, with incomplete information on the values the program computes, and without executing the program itself! This information is likely to be approximate: in general, at compile time, we will not know which sequence of instructions will be executed. Data-Flow Analysis is a standard way to formulate intra-procedural program analysis.

Scalable Context-Sensitive Points-to Analysis Using Multi-dimensional Bloom Filters

Lecture Notes in Computer Science, 2009

Context-sensitive points-to analysis is critical for several program optimizations. However, as t... more Context-sensitive points-to analysis is critical for several program optimizations. However, as the number of contexts grows exponentially, storage requirements for the analysis increase tremendously for large programs, making the analysis non-scalable. We propose a scalable flow-insensitive context-sensitive inclusion-based points-to analysis that uses a specially designed multi-dimensional bloom filter to store the points-to information. Two key observations motivate our proposal: (i) points-to information (between pointer-object and between pointerpointer) is sparse, and (ii) moving from an exact to an approximate representation of points-to information only leads to reduced precision without affecting correctness of the (may-points-to) analysis. By using an approximate representation a multi-dimensional bloom filter can significantly reduce the memory requirements with a probabilistic bound on loss in precision. Experimental evaluation on SPEC 2000 benchmarks and two large open source programs reveals that with an average storage requirement of 4MB, our approach achieves almost the same precision (98.6%) as the exact implementation. By increasing the average memory to 27MB, it achieves precision upto 99.7% for these benchmarks. Using Mod/Ref analysis as the client, we find that the client analysis is not affected that often even when there is some loss of precision in the points-to representation. We find that the NoModRef percentage is within 2% of the exact analysis while requiring 4MB (maximum 15MB) memory and less than 4 minutes on average for the points-to analysis. Another major advantage of our technique is that it allows to trade off precision for memory usage of the analysis.

Interprocedural Heap Analysis using Access Graphs and Value Contexts

I declare that this written submission represents my ideas in my own words and where others' idea... more I declare that this written submission represents my ideas in my own words and where others' ideas or words have been included, I have adequately cited and referenced the original sources. I also declare that I have adhered to all principles of academic honesty and integrity and have not misrepresented or fabricated or falsified any idea/data/fact/source in my submission. I understand that any violation of the above will be cause for disciplinary action by the Institute and can also evoke penal action from the sources which have thus not been properly cited or from whom proper permission has not been taken when needed.

GCC for Parallelization

Cathedral: Total Centralized Control Design, implement, test, release • Bazaar: Total Decentraliz... more Cathedral: Total Centralized Control Design, implement, test, release • Bazaar: Total Decentralization Release early, release often, make users partners in software development "Given enough eyeballs, all bugs are shallow" Code errors, logical errors, and architectural errors A combination of the two seems more sensible UPK,SB,PR GRC, IIT Bombay GCC-Par: GCC ≡ The Great Compiler Challenge 13/147 Another Example of The Generation Related Gap Locating the main function in the directory gcc-4.4.2/gcc using cscope File Line 0 collect2.c 766 main (int argc, char **argv) 1 fix-header.c 1074 main (int argc, char **argv) 2 fp-test.c 85 main (void ) 3 gcc.c 6216 main (int argc, char **argv) 4 gcov-dump.c 76 main (int argc ATTRIBUTE_UNUSED, char **argv 5 gcov-iov.c 29 main (int argc, char **argv) 6 gcov.c 355 main (int argc, char **argv) 7 gen-protos.c 130 main (int argc ATTRIBUTE_UNUSED, char **argv 8 genattr.c 89 main (int argc, char **argv) 9 genattrtab.c 4438 main (int argc, char **argv) a genautomata.c 9321 main (int argc, char **argv) b genchecksum.c 65 main (int argc, char ** argv) c gencodes.c 51 main (int argc, char **argv) d genconditions.c 209 main (int argc, char **argv) e genconfig.c 261 main (int argc, char **argv) f genconstants.c 50 main (int argc, char **argv) UPK,SB,PR GRC, IIT Bombay PPoPP'10 GCC-Par: GCC ≡ The Great Compiler Challenge 13/147 Another Example of The Generation Related Gap Locating the main function in the directory gcc-4.4.2/gcc using cscope File Line 0 collect2.c 766 main (int argc, char **argv) 1 fix-header.c 1074 main (int argc, char **argv) 2 fp-test.c 85 main (void ) 3 gcc.c 6216 main (int argc, char **argv) 4 gcov-dump.c 76 main (int argc ATTRIBUTE_UNUSED, char **argv 5 gcov-iov.c 29 main (int argc, char **argv) 6 gcov.c 355 main (int argc, char **argv) 7 gen-protos.c 130 main (int argc ATTRIBUTE_UNUSED, char **argv 8 genattr.c 89 main (int argc, char **argv) 9 genattrtab.c 4438 main (int argc, char **argv) a genautomata.c 9321 main (int argc, char **argv) b genchecksum.c 65 main (int argc, char ** argv) c gencodes.c 51 main (int argc, char **argv) d genconditions.c 209 main (int argc, char **argv) e genconfig.c 261 main (int argc, char **argv) f genconstants.c 50 main (int argc, char **argv) UPK,SB,PR GRC, IIT Bombay PPoPP'10 GCC-Par: GCC ≡ The Great Compiler Challenge 13/147 Another Example of The Generation Related Gap Locating the main function in the directory gcc-4.4.2/gcc using cscope g genemit.c 820 main (int argc, char **argv) h genextract.c 394 main (int argc, char **argv) i genflags.c 231 main (int argc, char **argv) j gengenrtl.c 350 main (int argc, char **argv) k gengtype.c 3584 main (int argc, char **argv) l genmddeps.c 45 main (int argc, char **argv) m genmodes.c 1376 main (int argc, char **argv) n genopinit.c 472 main (int argc, char **argv) o genoutput.c 1005 main (int argc, char **argv) p genpeep.c 353 main (int argc, char **argv) q genpreds.c 1399 main (int argc, char **argv) r genrecog.c 2718 main (int argc, char **argv) s main.c 33 main (int argc, char **argv) t mips-tdump.c 1393 main (int argc, char **argv) u mips-tfile.c 655 main (void ) v mips-tfile.c 4690 main (int argc, char **argv) w protoize.c 4373 main (int argc, char **const argv)

Effectiveness of garbage collection in MIT/GNU Scheme

Scheme uses garbage collection for heap memory management. Ideally, garbage collectors should be ... more Scheme uses garbage collection for heap memory management. Ideally, garbage collectors should be able to reclaim all dead objects, i.e. objects that will not be used in future. However, garbage collectors collect only those dead objects that are not reachable from any program variable. Dead objects that are reachable from program variables are not reclaimed. In this paper we describe our experiments to measure the effectiveness of garbage collection in MIT/GNU Scheme. We compute the drag time of objects, i.e. the time for which an object remains in heap memory after its last use. The number of dead objects and the drag time together indicate opportunities for improving garbage collection. Our experiments reveal that up to 26% of dead objects remain in memory. The average drag time is up to 37% of execution time. Overall, we observe memory saving potential ranging from 9% to 65%.

In defense of soundiness

Communications of the ACM, 2015

Static program analysis is a key component of many software development tools, including compiler... more Static program analysis is a key component of many software development tools, including compilers, development environments, and verification tools. Practical applications of static analysis have grown in recent years to include tools by companies such as Coverity, Fortify, GrammaTech, IBM, and others. Analyses are often expected to be sound in that their result models all possible executions of the program under analysis. Soundness implies that the analysis computes an overapproximation in order to stay tractable; the analysis result will also model behaviors that do not actually occur in any program execution. The precision of an analysis is the degree to which it avoids such spurious results. Users expect analyses to be sound as a matter of course, and desire analyses to be as precise as possible, while being able to scale to large programs.