IEGen: semi-automatic generation of inspectors and executors

Department Head: L. Darrell Whitley.Includes bibliographical references (pages 74-76).Software that simulates real-world phenomena such as heat transfer over surfaces and molecular interaction is often based on irregular computational kernels. Indirect array accesses such as A[B[i]] that are found in irregular computations often exhibit a memory access pattern that does not make efficient use of the memory hierarchy, reducing performance. Additionally, indirect array accesses hinder our ability to apply loop optimizations to improve data locality or introduce parallelism at compile time. One approach to solving this problem, an inspector/executor strategy, inspects the index arrays (B) at runtime to determine the order of accesses to the data arrays (A), reorders the data and index arrays, and executes a transformed computation that accesses the data arrays in a more efficient manner. For the most part, the application of inspector/executor strategies to irregular computations has been done manually or with limited generality. This thesis presents the Inspector/Executor Generator (IEGen). This tool accepts an irregular computation specification and sequence of run-time reordering transformations to apply to that computation as input. IEGen then generates serial inspector and executor code that implements the transformed computation. We contribute an inspector intermediate representation (IR) called an Inspector Dependence Graph (IDG), a method for code generation of inspectors based on an IDG, a method for code generation of executors, and techniques for manipulating affine constraints with uninterpreted function symbol (UFS) expressions to enable code generation. We evaluate our techniques against an existing library that supports limited UFS expressions and additionally show that generalized generation of inspectors and executors that implement composed run-time reordering transformations is possible

Splitting Polyhedra to Generate More Efficient Code: Efficient Code Generation in the Polyhedral Model is Harder Than We Thought

International audienceCode generation in the polyhedral model takes as inputa union of Z-polyhedra and produces code scanning all ofthem. Modern code generation tools are heavily relying onpolyhedral operations to perform this task. However, theseoperations are typically provided by general-purpose poly-hedral libraries that are not specifically designed to addressthe code generation problem. In particular, (unions of) poly-hedra may be represented in various mathematically equiv-alent ways which may have different properties with respectto code generation. In this paper, we investigate this prob-lem and try to find the best representation of polyhedra togenerate efficient code.We present two contributions. First we demonstrate thatthis problem has been largely under-estimated, showing sig-nificant control overhead deviations when using differentrepresentations of the same polyhedra. Second, we proposean improvement to the main algorithm of the state-of-the-artcode generation tool CLooG. It generates code with fewertests in the inner loops, and aims to reduce control overheadand to simplify vectorization for the compiler, at the cost ofa larger code size. It is based on a smart splitting of theunion of polyhedra while recursing on the dimensions. Weimplemented our algorithm in CLooG/PolyLib, and com-pared the performance and size of the generated code to theCLooG/isl version

Quiver Structure of Heterotic Moduli

We analyse the vector bundle moduli arising from generic heterotic compactifications from the point of view of quiver representations. Phenomena such as stability walls, crossing between chambers of supersymmetry, splitting of non-Abelian bundles and dynamic generation of D-terms are succinctly encoded into finite quivers. By studying the Poincar\'e polynomial of the quiver moduli space using the Reineke formula, we can learn about such useful concepts as Donaldson-Thomas invariants, instanton transitions and supersymmetry breaking.Comment: 38 pages, 5 figures, 1 tabl