Solving the TTC 2011 Compiler Optimization Case with QVTR-XSLT

In this short paper we present our solution for the Compiler Optimization case study of the Transformation Tool Contest (TTC) 2011 using the QVTR-XSLT tool. The tool supports editing and execution of the graphical notation of QVT Relations language

💡 Research Summary

The paper presents a complete solution to the Compiler Optimization case of the Transformation Tool Contest (TTC) 2011 using the QVTR‑XSLT tool. The authors first describe the tool’s architecture: a graphical editor built on top of MagicDraw for defining metamodels, QVT Relations, and OCL constraints, and a code generator that translates the XML representation of a transformation into pure XSLT stylesheets. The generated XSLT can be executed by any standard XSLT processor (the authors use Saxon 9) and supports parameters, rule overriding, and multiple input/output models.

The transformation work begins with a simple metamodel for the intermediate representation (IR) of a Firm model. A FirmModel contains Graphs; each Graph consists of Nodes (operations) and Edges (data‑flow or control‑flow). Nodes are typed by an xlink:href attribute (e.g., #Add, #Mul, #Cmp, #Jmp, #Phi, #Const). OCL invariants are defined to guarantee well‑formedness, such as ensuring an Attribute has exactly two properties and that IDs are unique within a default graph.

Two separate transformation pipelines are built on this metamodel. The first pipeline implements local optimizations as an in‑place transformation. The top‑level relation FirmModelTrans invokes FoldOper and FoldNode. FoldOper detects binary arithmetic or comparison nodes whose two operands are both constants; it then calls DoFoldOper. DoFoldOper splits into DoFoldMath (constant folding of arithmetic) and DoFoldCmp (constant folding of comparisons). In DoFoldMath the arithmetic result is computed, the original operation node is replaced by a Const node holding the result, and the outgoing edges are removed. In DoFoldCmp the comparison result is evaluated via a user‑defined function CalcuLogic; the corresponding conditional node is removed, its true/false edges are rewired, and the comparison node becomes a Jmp node. The FoldNode group cleans up the graph by eliminating dead Phi nodes, blocks that contain only a Jmp, blocks without outgoing control flow, and isolated Const nodes. Queries such as GetToData and GetInEdge are used to retrieve operand and edge information, while functions encapsulate the limited arithmetic and logical operations supported by OCL.

The second pipeline addresses instruction selection and is a source‑to‑target model transformation, although source and target share the same metamodel. The transformation copies most of the model unchanged (relations like CopyAtt, CopyNode, EdgeToEdge) and focuses on converting each operation node into a target‑specific instruction. BinaryOp selects all binary operations, changes their type name by prefixing “Target”, and invokes MakeBinaryI. MakeBinaryI creates a new operation node (e.g., TargetAddI), duplicates the original edges, and, if the operation is non‑commutative, generates a new constant operand via MakeNewConst. UniqueOp handles operations marked with an asterisk in the case specification (e.g., Load, Store) and calls MakeLoadStoreI to create specialized LoadI/StoreI nodes with a “global” symbol attribute. Helper functions GetTargetName and GetNewId compute the new type names and generate fresh identifiers. As with the first pipeline, queries retrieve adjacency information, and the transformation proceeds until no further changes occur.

The authors evaluated their solution on the seven GXL examples supplied with the case (excluding zero.gxl, which requires bit‑wise and shift operations not supported by their OCL‑based functions). Experiments were run on an Intel M330 2.13 GHz laptop with 3 GB RAM under Windows 7. Execution times ranged from 15 ms to 850 ms, all well below one second, and the generated XSLT files were modest in size (≈480 lines for local optimization, ≈330 lines for instruction selection, plus ≈280 lines for validation). The authors note that performance and memory consumption depend heavily on the underlying XSLT processor; they observed no built‑in parallelism in standard processors, though an Intel research prototype does exploit it.

In conclusion, the paper demonstrates that QVTR‑XSLT can be used to model, validate, and execute non‑trivial compiler optimizations entirely through declarative, graph‑based specifications. The approach offers clear visualisation of transformation rules, automatic generation of portable XSLT code, and a lightweight runtime that requires no hand‑crafted scripts beyond the iterative runner that repeats the transformation until a fixed point is reached. This work thus contributes both a concrete solution to the TTC 2011 case and evidence that graphical QVT Relations combined with XSLT execution constitute a viable, platform‑independent transformation technology.