Results 1 -
6 of
6
Global Flow Analysis as a Practical Compilation Tool
- Journal of Logic Programming
, 1992
"... This paper addresses the issue of the practicality of global flow analysis in logic program compilation, in terms of speed of the analysis, precision, and usefulness of the information obtained. To this end, design and implementation aspects are discussed for two practical abstract interpretation- ..."
Abstract
-
Cited by 73 (20 self)
- Add to MetaCart
This paper addresses the issue of the practicality of global flow analysis in logic program compilation, in terms of speed of the analysis, precision, and usefulness of the information obtained. To this end, design and implementation aspects are discussed for two practical abstract interpretation-based flow analysis systems: MA 3 , the MCC And-parallel Analyzer and Annotator; and Ms, an experimental mode inference system developed for SB-Prolog. The paper also provides performance data obtained from these implementations and, as an example of an application, a study of the usefulness of the mode information obtained in reducing run-time checks in independent and-parallelism. Based on the results obtained, it is concluded that the overhead of global flow analysis is not prohibitive, while the results of analysis can be quite precise and useful. 1 Introduction The extensive use of advanced compilation techniques [8, 22, 30, 32, 33, 34], coupled with parallel execution [5, 10,...
Automatic Mode Inference for Logic Programs
- Journal of Logic Programming
, 1988
"... In general, logic programs are undirected, i.e. there is no concept of "input" and "output" arguments to a procedure. An argument may be used either as an input or as an output argument, and programs may be executed either in a "forward" direction or in a "backward" direction. However, it is often t ..."
Abstract
-
Cited by 69 (7 self)
- Add to MetaCart
In general, logic programs are undirected, i.e. there is no concept of "input" and "output" arguments to a procedure. An argument may be used either as an input or as an output argument, and programs may be executed either in a "forward" direction or in a "backward" direction. However, it is often the case that in a given program, a predicate is used with some of its arguments used consistently as input arguments and others as output arguments. Such mode information can be used by a compiler to effect various optimizations. This paper considers the problem of automatically inferring the modes of the predicates in a program. The dataflow analysis we use is more powerful than approaches relying on syntactic characteristics of programs, e.g. [18]. Our work differs from that of Mellish [14, 15] in that (i) we give a sound and efficient treatment of variable aliasing in mode inference; (ii) by propagating instantiation information using state transformations rather than through dependen...
Functional computations in logic programs
- ACM Transactions on Programming Languages and Systems
, 1989
"... Abstract: While the ability to simulate nondeterminism and compute multiple solutions for a single query is a powerful and attractive feature of logic programming languages, it is expensive in both time and space. Since programs in such languages are very often functional, i.e. do not produce more t ..."
Abstract
-
Cited by 51 (11 self)
- Add to MetaCart
Abstract: While the ability to simulate nondeterminism and compute multiple solutions for a single query is a powerful and attractive feature of logic programming languages, it is expensive in both time and space. Since programs in such languages are very often functional, i.e. do not produce more than one distinct solution for a single input, this overhead is especially undesirable. This paper describes how pro-grams may be analyzed statically to determine which literals and predicates are functional, and how the program may then be optimized using this information. Our notion of ‘‘functionality’ ’ subsumes the notion of ‘‘determinacy’ ’ that has been considered by various researchers. Our algorithm is less reliant on language features such as the cut, and thus extends more easily to parallel execution strategies, than others that have been proposed.
Flow analysis of dynamic logic programs
- Journal of Logic Programming
, 1989
"... Abstract: Research on flow analysis and optimization of logic programs typically assumes that the pro-grams being analyzed are static, i.e. any code that can be executed at runtime is available for analysis at compile time. This assumption may not hold for ‘‘real’ ’ programs, which can contain dynam ..."
Abstract
-
Cited by 9 (3 self)
- Add to MetaCart
Abstract: Research on flow analysis and optimization of logic programs typically assumes that the pro-grams being analyzed are static, i.e. any code that can be executed at runtime is available for analysis at compile time. This assumption may not hold for ‘‘real’ ’ programs, which can contain dynamic goals of the form call(X), where X is a variable at compile time, or where predicates may be modified via features like assert and retract. In such contexts, a compiler must be able to take the effects of such dynamic con-structs into account in order to perform nontrivial flow analyses that can be guaranteed to be sound. This paper outlines how this may be done for certain kinds of dynamic programs. Our techniques allow analysis and optimization techniques that have been developed for static programs to be extended to a large class of ‘‘well-behaved’ ’ dynamic programs. Address for correspondence and proofs:
Profiling prolog programs
- Software Practice and Experience
, 1983
"... Abstract: Profilers play an important role in the development of efficient programs. Profiling techniques developed for traditional languages are inadequate for logic programming languages, for a number of rea-sons: first, the flow of control in logic programming languages, involving backtracking an ..."
Abstract
-
Cited by 8 (0 self)
- Add to MetaCart
Abstract: Profilers play an important role in the development of efficient programs. Profiling techniques developed for traditional languages are inadequate for logic programming languages, for a number of rea-sons: first, the flow of control in logic programming languages, involving backtracking and failure, is significantly more complex than in traditional languages; second, the time taken by a unification opera-tion, the principal primitive operation of such languages, cannot be predicted statically because it depends on the size of the input; and finally, programs may change at runtime because clauses may be added or deleted using primitives like assert and retract. In this paper we describe a simple profiler for Prolog. The ideas outlined here may either be used to implement a simple interactive profiler, or be integrated into Prolog compilers. 1.
Towards banishing the cut from Prolog
- IEEE Trans. on Software Engineering
, 1990
"... Abstract: There has been a great deal of interest in logic programming languages in recent years. This is due, in great part, to the advantages offered by these languages: declarative readings of programs and separation of program logic from control. However, logic programs can often be dismayingly ..."
Abstract
-
Cited by 7 (1 self)
- Add to MetaCart
Abstract: There has been a great deal of interest in logic programming languages in recent years. This is due, in great part, to the advantages offered by these languages: declarative readings of programs and separation of program logic from control. However, logic programs can often be dismayingly inefficient. The usual solution to this problem has been to return some control to the user in the form of impure language features like cut. Unfortunately, this often results in the loss of precisely those features that made logic programming attractive in the first place. We argue that it is not necessary to resort to such impure features for efficiency. This point is illus-trated by considering how most of the common uses of cut can be eliminated from Prolog source pro-grams, relying on static analysis to generate them at compile time. Three common situations where the cut is used are considered. Static analysis techniques are given to detect such situations, and applicable program transformations are described. We also suggest two language constructs, firstof and oneof, for situations involving ‘‘don’t-care’ ’ nondeterminism. These constructs have better declarative readings than the cut, and extend better to parallel evaluation strategies. Together, these proposals result in a sys-tem where users need rely much less on cuts for efficiency, thereby promoting a purer programming style without sacrificing efficiency.

