Elementary transformation analysis for Array-OL

Array-OL is a high-level specification language dedicated to the definition of intensive signal processing applications. Several tools exist for implementing an Array-OL specification as a data parallel program. While Array-OL can be used directly, it is often convenient to be able to deduce part of the specification from a sequential version of the application. This paper proposes such an analysis and examines its feasibility and its limits.

💡 Research Summary

The paper addresses a practical gap in the adoption of Array‑OL, a high‑level specification language designed for intensive signal‑processing applications. While Array‑OL enables clear expression of data‑parallel constructs such as array sections, iterators, and explicit data flow, writing these specifications manually is labor‑intensive and error‑prone. The authors propose a systematic analysis that automatically extracts a substantial portion of an Array‑OL specification from an existing sequential implementation written in C or Fortran.

The methodology consists of four tightly coupled stages. First, the source code is parsed and an abstract syntax tree (AST) is built, from which control‑flow graphs (CFGs) are derived to capture nested loops, conditionals, and basic blocks. This structural information is essential for later data‑flow analysis. Second, array‑index expressions are normalized. Although many real‑world codes use linear combinations of loop variables, the authors also handle higher‑order polynomials, conditional expressions, and occasional function calls by employing a symbolic engine. When exact linearization is impossible, they resort to integer‑linear programming (ILP) approximations or Taylor‑series based heuristics, thereby preserving enough information for subsequent steps.

Third, a rigorous data‑dependency analysis is performed. The authors combine classic dependence testing (e.g., Banerjee’s inequalities) with modern SAT‑based techniques to detect read‑write conflicts across array sections. If no cyclic dependencies are found, the corresponding loops are marked as parallelizable. For cases where multiple arrays are accessed simultaneously, common sub‑scripts are identified and expressed as shared sections in the generated Array‑OL code.

The final stage is the automatic generation of the Array‑OL specification. Using a template‑driven code generator, the analysis produces iterator definitions, array‑section declarations, and explicit data‑flow statements. For example, a finite‑impulse‑response (FIR) filter is rendered as an iterator “for i in 0..N‑1” with input and coefficient sections “in