Solving the TTC 2011 Compiler Optimization Case with GROOVE

This report presents a partial solution to the Compiler Optimization case study using GROOVE. We explain how the input graphs provided with the case study were adapted into a GROOVE representation and we describe an initial solution for Task 1. This solution allows us to automatically reproduce the steps of the constant folding example given in the case description. We did not solve Task 2.

💡 Research Summary

The paper reports a partial solution to the TTC 2011 Compiler Optimization case study using the graph transformation tool GROOVE. The authors first introduce GROOVE, emphasizing its use of simple labelled directed graphs where edges have no identity or attributes, and describe how transformation rules are visualised with coloured and shaped elements representing readers, erasers, creators, and embargoes (negative application conditions).

The case study provides input programs in GXL format adhering to the FIRM representation, which includes edge attributes and typed edges—features not directly supported by GROOVE. To bridge this gap, the authors construct a custom type graph in GROOVE. Every FIRM edge is modelled as a node of a sub‑type of “Edge” with a “position” attribute, and the original source‑target relationship is expressed via “in” and “out” edges connecting operation nodes to these Edge nodes. Abstract types are indicated with bold‑italic labels, and inheritance is shown with open‑triangle arrows. This conversion enables static typing in GROOVE, eliminating runtime type‑checking overhead.

For the constant‑folding example (Task 1), the authors manually created the start graph after inspecting the supplied GXL file. They then implemented a suite of graph‑transformation rules. Seven rules perform folding for each arithmetic or logical operation (Add, Sub, Mul, Div, etc.), each matching a specific operation node together with constant operand nodes, deleting the operation node, and creating a new constant node that holds the computed result. The add-fold-int rule is described in detail: it matches an Add node with two constant operands, removes the Add node and its associated Dataflow edges, creates a new Const node with the sum of the operand values, and redirects all incoming Dataflow edges to the new constant. A universal quantifier node (labelled ∀ > 0) is used to handle an arbitrary number of incoming edges in a single rule application. Three additional cleanup rules delete dangling edges and constants that become unreferenced after folding.

To ensure the transformed graphs remain well‑formed, the authors encode the sanity checks from the case description as negative application condition rules. For instance, rule consts fires when a constant appears outside the StartBlock, while other rules (single-start, single-end, containment, phi-check, pos-check) detect violations such as multiple start blocks, missing end blocks, incorrect block containment, malformed Phi nodes, and incorrect operand positions. These checks are implemented in the same GROOVE grammar, allowing immediate detection of invalid configurations during transformation.

The authors acknowledge several limitations. Only the operations present in the example were covered; other operations defined in the case study were not implemented due to time constraints. Automatic loading of the original GXL files was not realised, requiring manual adaptation of the input graphs. Consequently, the solution cannot be applied to the full test suite, and performance metrics are not reported. Nonetheless, the approach demonstrates that GROOVE can express compiler optimizations purely as graph transformations without auxiliary code, and the rule‑per‑operation style yields a concise and maintainable grammar.

In conclusion, the paper presents a clear methodology for adapting a typed, attribute‑rich intermediate representation to GROOVE’s simple graph model, defines a set of transformation and validation rules that successfully reproduce the constant‑folding steps of the example program, and outlines future work needed to achieve full coverage of Task 2 and to automate the graph import process. The work serves as a practical case study for researchers interested in applying graph‑based transformation tools to compiler optimizations.