Solving the TTC 2011 Compiler Optimization Case with GReTL

The standard GReTL operations are currently targeted at out-place transformation which create the target metamodel and the target graph simultaneously, but this case requires changing the graph in-place. Luckily, GReTL is designed as an extensible language. Adding custom operations requires only specializing one framework class, overriding one method that implements the operation’s behavior, and implementing another factory method that is responsible for creating an instance of the new operation initialized with the given parameters. Consequently, some in-place operations have been added to the language. There is one operation MatchReplace which is similar to a rule in graph replacement systems. There is an operation Delete for deleting elements, an operation MergeVertices for merging a set of duplicate vertices into one canonical representative, and a higher-order operation Iteratively which receives another operation and applies it as long as possible. The implementation of the most complex one, MatchReplace, is about 380 lines of Java code including comments and empty lines, the other three operations are at most 80 lines or less. Thus, this case was solved using a mixed bottom-up and top-down approach: the language was extended with three new operations, and then these operations were used to write the transformations.

In this section, the two transformation tasks are discussed in sequence. The solutions can be run on the SHARE image [4].

The GReTL solution for the constant folding task does a bit more than what was required. It contains operation calls that realize the following optimizations: In the following, the optimizations (1), (3), and (4) are discussed, starting with the evaluation of binary operations depending only on constants. A helper function is defined that receives some Binary operation bin and the values of its left and right operand (lval, rval) and returns the evaluation result.

e v a l u a t e B i n a r y ( ) := u s i n g b i n , l v a l , r v a l : Depending on the type of the given Binary bin, the correct operation is dispatched using a sequence of conditional expressions1 and applied to the operand values. The division has to be handled specially: in GReQL, a division results in a double value, but here an integer division is intended. To match these semantics, either the floor or the ceiling of the result d is taken.

The next listing shows the replacement of all Binary vertices that have two Const arguments with a new Const with value set to the result of evaluating the binary operation. The MatchReplace operation has semantics similar but not identical to rules in graph replacement systems. Its first parameter is a template graph that describes the structure of the subgraph to be created or changed (similar to the RHS in rules in graph replacement systems), and following the arrow symbol, there is a GReQL query that reports a set of matches. The query is comparable to the LHS in graph transformations, except that it calculates all matches instead of one match at a time. For all matches, the template graph is applied, thereby skipping matches containing previously modified elements.

In the template graph, the dollar ($) is a variable that holds the current match. Vertices are represented using paretheses and edges with arrows and curly braces:

(Type ‘greql’ | attr1 = ‘greql2’, attr2 = ‘greql3’) –>{Type ‘greql’ | attr1 = ‘greql2’, attr2 = ‘greql3’} The semantics for vertices, but likewise for edges, are as follows. The optional Type is a vertex type name. If no Type is specified and greql evaluates to a vertex in the current match or any other vertex in the graph, it is bound to the template vertex and preserved. If Type is given and greql evaluates to a vertex in the current match, then that vertex is replaced with a new vertex of the specified type, all edges incident to the replaced vertex are relinked to the new one, and the new vertex is bound to the template vertex. If Type is given but no greql query, then a new vertex of the given type is created and bound to that template vertex. The attributes of the bound elements are set to the result of the queries in the attribute list. All vertices and edges in the match that are not bound to any template graph element are deleted. The deletion of some vertex implies deletion of all incident edges. The higher-order operation Iteratively applies the MatchReplace operation as long as some match could be replaced. The query given to MatchReplace reports a set of matches where each match is a record of a binary operation (op), the evaluation result gathered by the evaluateBinary() helper (value), and the set of edges starting at the binary