Table of Contents
Fetching ...

Backwards Data-Flow Analysis using Prophecy Variable in the BuildIt System

Ajay Brahmakshatriya, Saman Amarasinghe, Martin Rinard

TL;DR

This work tackles the challenge of obtaining information about a program’s future execution to enable optimizations in domain-specific languages. It replaces traditional backwards dataflow analyses with prophecy variables that predict future behavior, using repeated forward program executions to validate and refine these predictions within BuildIt’s two-stage, forward-execution framework. The paper formalizes prophecy variables in a core language, presents extended semantics and a prophecy-analysis via reexecution, and demonstrates practical benefits through tensor data movement for GPUs and neural-network fusion, along with performance and engineering-effort results. The proposed approach preserves BuildIt’s lightweight DSL implementation while enabling optimizations that rely on future execution information, offering a scalable path to future-aware DSL optimizations without heavy IRs or backward analyses.

Abstract

Many program transformations and optimizations require information about the future behavior of the program. A standard way to obtain this information is to build an intermediate program representation, then use a backwards program analysis to propagate relevant information against the flow of control back to the transformation/optimization site. We instead propose to use prophecy variables, which predict information about the future execution of the program, to enable such transformations and optimizations. We implement prophecy variables in BuildIt, a lightweight domain specific language implementation system. BuildIt uses staged compilation to implement high performance domain specific languages embedded within a standard general purpose programming language (C++). The BuildIt first phase uses standard C++ program execution to generate optimized C, C++, and CUDA second phase code. This approach enables BuildIt to eliminate programming language implementation components such as parsers and intermediate representations, delivering a dramatic decrease in the engineering effort required to implement domain specific languages. The combination of prophecy variables and repeated forward program execution enables BuildIt to extend this approach to include transformations and optimizations that require information about the future execution of the program without backwards analyses and without the engineering overhead associated with implementing these analyses. We formalize the use of prophecy variables for this purpose, discuss the implementation of prophecy variables and repeated execution in BuildIt, and present experimental results for BuildIt computations that benefit from optimizations enabled by the information that prophecy variables provide.

Backwards Data-Flow Analysis using Prophecy Variable in the BuildIt System

TL;DR

This work tackles the challenge of obtaining information about a program’s future execution to enable optimizations in domain-specific languages. It replaces traditional backwards dataflow analyses with prophecy variables that predict future behavior, using repeated forward program executions to validate and refine these predictions within BuildIt’s two-stage, forward-execution framework. The paper formalizes prophecy variables in a core language, presents extended semantics and a prophecy-analysis via reexecution, and demonstrates practical benefits through tensor data movement for GPUs and neural-network fusion, along with performance and engineering-effort results. The proposed approach preserves BuildIt’s lightweight DSL implementation while enabling optimizations that rely on future execution information, offering a scalable path to future-aware DSL optimizations without heavy IRs or backward analyses.

Abstract

Many program transformations and optimizations require information about the future behavior of the program. A standard way to obtain this information is to build an intermediate program representation, then use a backwards program analysis to propagate relevant information against the flow of control back to the transformation/optimization site. We instead propose to use prophecy variables, which predict information about the future execution of the program, to enable such transformations and optimizations. We implement prophecy variables in BuildIt, a lightweight domain specific language implementation system. BuildIt uses staged compilation to implement high performance domain specific languages embedded within a standard general purpose programming language (C++). The BuildIt first phase uses standard C++ program execution to generate optimized C, C++, and CUDA second phase code. This approach enables BuildIt to eliminate programming language implementation components such as parsers and intermediate representations, delivering a dramatic decrease in the engineering effort required to implement domain specific languages. The combination of prophecy variables and repeated forward program execution enables BuildIt to extend this approach to include transformations and optimizations that require information about the future execution of the program without backwards analyses and without the engineering overhead associated with implementing these analyses. We formalize the use of prophecy variables for this purpose, discuss the implementation of prophecy variables and repeated execution in BuildIt, and present experimental results for BuildIt computations that benefit from optimizations enabled by the information that prophecy variables provide.
Paper Structure (28 sections, 8 equations, 16 figures, 1 table, 4 algorithms)

This paper contains 28 sections, 8 equations, 16 figures, 1 table, 4 algorithms.

Figures (16)

  • Figure 1: Prophecy Variables Predict Tensors Accessed by GPU Computations.
  • Figure 2: A simple power function written in BuildIt with repeated squaring. The base is a second stage parameter and exponent is a first stage parameter.
  • Figure 3: Generated code for the program in Figure \ref{['lst:powerex']}.
  • Figure 4: Implementation of constant-propagation optimization for Tensor types by packing dyn_var<T> and static_var<T> together in the Tensor library.
  • Figure 5: Implementation of device type type-checking to ensure that the tensor is active on the correct device.
  • ...and 11 more figures

Theorems & Definitions (4)

  • definition 1
  • definition 2
  • definition 3
  • definition 4