machine designers have long recognized this dilemma. In 1972, Newey, Poole, and Waite [Newe79] observed that `Most problems will suggest a number of specialized operations which could possibly be implemented quite efficiently on certain hardware. The designer must balance the convenience and utility of these operations against the increased difficulty of implementing an abstract machine with a rich and varied instruction set.' Fortunately, applying all code improvements to the LIL removes efficiency considerations as HIL design issue. The abstract machine need only contain a set of features roughly equivalent to the intersection of the operations included in typical target machines. The result is a small, simple abstract machine. Such abstract machines are termed `intersection' machines. The analogy between union/intersection abstract machines and CISC/RISC architectures is obvious. void daxpy(n, da, dx, incx, dy, incy) int n, incx, incy; double da, dx[], dy[]; { if (n <= 0) return; i...

The generation of efficient code for Prolog programs requires sophisticated code transformation and op-timization systems. Much of the recent work in this area has focussed on high level transformations, typi-cally at the source level. Unfortunately, such high level transformations suffer from the deficiency of be-ing unable to address low level implementational details. This paper presents a simple code improvement scheme that can be used for a variety of low level optimizations. Applications of this scheme are illustrat-ed using low level optimizations that reduce tag manipulation, dereferencing, trail testing, environment al-location, and redundant bounds checks. The transformation scheme serves as a unified framework for rea-soning about a variety of low level optimizations that have, to date, been dealt with in a more or less ad hoc manner.

Most implementations of logic programming languages treat input and output arguments to procedures in a fundamentally asymmetric way: input values are passed in registers, but output values are returned in memory. In some cases, placing the outputs in memory is useful to preserve the opportunity for tail call optimization. In other cases, this asymmetry can lead to a large number of unnecessary memory references and adversely affect performance. When input/output modes for arguments are known it is often possible to avoid much of this unnecessary memory traffic via a form of interprocedural register allocation. In this paper we discuss how this problem may be addressed by returning output values in registers where it seems profitable to do so. The techniques described have been implemented in the jc system, but are also applicable to other moded logic programming languages, such as Parlog, as well as languages like Prolog when input/output modes have been determined via dataflow analy...

: While decision tree compilation is a promising way to carry out guard tests efficiently, the methods given in the literature do not take into account either the execution characteristics of the program or the machine-level tradeoffs between different ways to implement branches. These methods therefore offer little or no guidance for the implementor with regard to how decision trees are to be realized on a particular machine. In this paper, we describe an approach that takes execution frequencies of different program branches, as well as the costs of alternative branch realizations, to generate decision trees. Experiments indicate that the performance of our approach is uniformly better than that of plausible alternative schemes. 1 Introduction There has been a great deal of research, in recent years, on the design and implementation of concurrent logic and constraint programming languages (see, for example, [12, 13, 14, 15, 17]). Much of the implementation effort in this context ha...

Nearly all algorithms for code optimization use a control flow graph. In this thesis, I will show that with very minor restrictions on program structure, an abstract syntax tree can be used instead, leading to algorithms that are often much simpler than their graphbased counterparts. The conclusion is that abstract syntax trees, not control flow graphs, should be the fundamental data structure in code optimization. 1 Introduction Most optimizing compilers consist of a front-end that does syntactic and semantic analysis, and a back-end that does optimization and machine code generation [ASU86]. The main data structure in the front-end is an abstract syntax tree (AST), while in the back-end it is a control flow graph (CFG), which consists of nodes representing computations and edges representing control flow. Thus, code optimization operates on a data structure---the CFG---in which the program has essentially been "flattened" into a tangle of GOTOs (edges). Unlike an AST, a CFG c...

this document is intended to help determine the state of the art of optimization in production C compilers. I hope that the document itself will be useful to compiler writers, industrial and academic, and to programmers who are interested in learning what they can expect from a compiler. This program should not be used to compare compilers. When comparison shopping for compilers, the following factors should be considered:

Abstract not found