Compiler Optimization: A Case for the Transformation Tool Contest

Van Gorp, Mazanek and Rose (Eds.): Fifth Transformation Tool Contest (TTC 2011) EPTCS 74, 2011, pp. 6–16, doi:10.4204/EPTCS.74.2 Compiler Optimization: A Case for the Transformation Tool Contest Sebastian Buchwald Edgar Jakumeit Karlsruhe Institute of Technology (KIT) buchwald@kit.edu 1 Introduction An optimizing compiler consists of a front end parsing a textual programming language into an inter- mediate representation (IR), a middle end performing optimizations on the IR, and a back end lowering the IR to a target representation (TR) built of operations supported by the target hardware. In mod- ern compiler construction graph-based IRs are employed. Optimization and lowering tasks can then be implemented with graph transformation rules. The participating tools are required to solve the following challenges: Local optimizations replace an IR pattern of limited size and only local graph context by another se- mantically equivalent IR pattern which is cheaper to execute or which enables further optimiza- tions. For instance, given the associativity of the ’+’-operator, the transformation (x + 1) + 2 ⇒ x+(1+2) ⇒x+3 can be performed by local optimizations. Instruction selection transforms the intermediate representation into the target representation. While both representations are similar in structure, the TR operations are often equivalent to a small pattern of IR operations, i.e. one TR operation covers an IR pattern (it may be equivalent to several different IR patterns). Thus instruction selection can be approached by applying rules rewriting IR patterns to TR nodes, until the whole IR graph was covered and transformed to a least cost TR graph. The primary purpose of these challenges is to evaluate the participating tools regarding performance. The ability to apply rules in parallel should be beneficial for the instruction selection task due to the locality of the rules and a high degree of independence in between the rules. It could be advantageous for the optimization task, too, but intelligent traversal strategies might have a higher impact there. Secondary aims are fostering tool interoperability regarding the GXL standard format and testing the ability to visualize medium sized real world graphs. We provide the following resources on the case website [1]: • This case description. • Input graphs of various sizes in GXL format. • The needed meta models are contained in the GXL files. Sebastian Buchwald and Edgar Jakumeit 7 2 A Graph-Based Intermediate Representation The intermediate representation to be used is a simplified version of the graph-based intermediate repre- sentation FIRM1. Within FIRM, nodes represent basic operations, e.g. loading a value from an address or adding two values. Edges indicate dependencies between nodes, e.g. an Add depends on its two operands. Each operation is located within a Block2. For the represented program all nodes within the same Block are executed together, i.e. if one node within a Block is executed then all nodes within the Block must be executed. Figure 1 shows the program graph of our reference solution [3] for the following C-function: i n t MinPlus ( i n t x , i n t y ) { i n t min ; i f ( x < y ) { min = x ; } e l s e { min = y ; } r e t u r n min + 1; } The program execution starts at Start, which also produces the initial memory state and the given Argu- ments. Start and the Arguments belong to the special StartBlock. The Cmp compares the arguments and Cond represents a conditional jump depending on the result of the comparison. After executing the Jmp of the then- or else-Block the program execution continues at Block $0. The Phi originates form the static single assignment form [4] which is required for a concise graph-based IR. It chooses one of its operands depending on the previously executed block. For instance, the Phi selects Argument 2 if the Cond was evaluated to False and Argument 1 if the Cond was evaluated to True. The Return returns the value selected by the Phi. The end of the program execution is represented by the special EndBlock which by convention contains exactly one End. Each node has ordered outgoing edges, which is indicated by the position attribute of the edges. Edges representing the containment to a Block have position −1; the operands start at position 0. There are several edge types: Dataflow Models the flow of data from an operation to another one. Memory Memory edges are used to ensure an order for memory operations. Controlflow Models possible execution paths through the program. True Control flow if a condition jump is evaluated to true. False Control flow if a condition jump is evaluated to false. Keep Needed to model infinite loops, see description of End. 1www.libfirm.org 2also known as basic block 8 Compiler Optimization Case Figure 1: Program graph of a minimum plus one function, with block containment visualized as contain- ment left, and the plain graph right. Sebastian Buchwald and Edgar Jakumeit 9 The direction of the e

This content is AI-processed based on open access ArXiv data.