Optimistic Loop Optimization

Optimistic Loop Optimization

ifact rt * * Comple A t te n * A te s W i E * s e n l C l o D C O o * * c u e G m s E u e C e n R t v e o d t * y * s E a a l d u e a Optimistic Loop Optimization t Johannes Doerfert Tobias Grosser Sebastian Hack Saarland University Department of Computer Science Saarland University Saarland Informatics Campus ETH Zurich, Switzerland Saarland Informatics Campus Saarbrucken,¨ Germany [email protected] Saarbrucken,¨ Germany [email protected] [email protected] Abstract diate representations (IRs) such as ORC/WRaP-IT [23], Compilers use static analyses to justify program optimiza- gcc/graphite [40], and LLVM/Polly [24]. Especially the tions. As every optimization must preserve the semantics of semantics of IRs are often too low-level to fulfill all of the original program, static analysis typically fall-back to the polyhedral model’s requirements upfront. For exam- conservative approximations. Consequently, the set of states ple, LLVM-IR has no proper multidimensional arrays in the for which the optimization is invalid is overapproximated sense of Fortran, loop counter arithmetic might (depending and potential optimization opportunities are missed. Instead on the input program and language) use modulo arithmetic, of justifying the optimization statically, a compiler can also and aliasing rules are different due to the flat memory model. synthesize preconditions that imply the correctness of the Some of these peculiarities can be worked around but usually optimizations and are checked at the runtime of the program. this comes at an expense. Either significant increase in com- In this paper, we present a framework to collect, gener- pile time, because the polyhedral representation becomes alize, and simplify assumptions based on Presburger arith- more complex, or less optimization potential, because of metic. We introduce different assumptions necessary to en- overapproximations on the program behavior [26], or both. able a variety of complex loop transformations and derive a declare rhs[JMAX][IMAX][5]; (close to) minimal set of preconditions to validate them at for (j = 0; j < grid[0] + 1; j++) runtime. Our evaluation shows that the runtime verification for (i = 0; i < grid[1] + 1; i++) introduces negligible overhead and that the assumptions we for (m = 0; m < 5; m++) P: rhs[j][i][m] = / ... /; propose almost always hold true. On a large benchmark set * * including SPEC and NPB our technique increases the num- Figure 1. Simplified excerpt of the compute rhs func- ber of modeled non-trivial loop nests by a factor of 3:9×. tion in the BT benchmark as provided in the C implementa- Categories and Subject Descriptors D.3.4 [Programming tion of the NAS Parallel Benchmarks (NPB) [39]. Languages]: Compiler, Optimization The program in Figure 1 shows a simplified excerpt of the Keywords Static Analysis; Presburger Precondition; Pro- BT benchmark in the NAS parallel benchmark suite [39]. gram Versioning; Polyhedral Model Several issues prevent the straightforward application of 1. Introduction polyhedral techniques although existing work [32] has shown that it profits from such loop optimizations. To be The polyhedral model has proven to be a very powerful vehi- polyhedrally representable it must satisfy three conditions. cle for loop optimizations such as tiling, parallelization, and grid vectorization [2, 7, 8, 35, 36, 44]. It represents programs by 1. The references to in the loop bounds must be loop convex polyhedra and leverages parametric integer program- invariant, i.e. these array cells must not be modified in the ming techniques to analyze and transform them [18–20]. loop nest. This involves proving that this array does not To be faithfully represented in the polyhedral model, a alias with other arrays that are modified in the loop nest. loop nest has to fulfill several strong requirements [19]. 2. The loop bounds must not overflow since the polyhedral Amongst others, there must be no aliasing, all array sub- model is based on arithmetic in Z not machine arithmetic. scripts must be affine, loop bounds must be loop invariant, 3. The accesses must stay in-bounds with regards to the and so on. Some of these constraints also impact the seman- array allocation, i.e., i < grid[1] + 1 <= IMAX. tics of the programming language: loop counter arithmetic All these properties are notoriously hard to verify statically, and subscript evaluation happens in Z not in machine arith- if possible at all. However, we can hardly imagine a program metic. Arrays are for example truly multidimensional, thus run in which one of these requirements is violated. Hence, no two different index vectors can access the same cell. we are in the unsatisfactory situation that we know that these There is a trend to also use the polyhedral model on requirements are fulfilled for every program run of interest low-level languages such as C [11] and compiler interme- but we are unable to prove it. In this paper we solve this 978-1-5090-4931-8/17$15.00 c 2017 IEEE 292 CGO 2017, Austin, USA declare rhs[JMAX][IMAX][5]; declare rhs[JMAX][IMAX][5]; assume grid[0] != MAX_VALUE; assume grid[0] != MAX_VALUE && grid[1] != MAX_VALUE && for (j = 0; j < grid[0] + 1; j++) { grid[0] + 1 <= JMAX && grid[1] + 1 <= IMAX && assume grid[1] != MAX_VALUE: (&rhs[0][0][0] >= &grid[2] || for (i = 0; i < grid[1] + 1; i++) { &rhs[grid[0]][grid[1]][5] <= &grid[0]); for (m = 0; m < 5; m++) { assume j < JMAX && i < IMAX; for (j = 0; j < grid[0] + 1; j++) { assume &rhs[j][i][m] >= &grid[2] || for (i = 0; i < grid[1] + 1; i++) { &rhs[j][i][m + 1] <= &grid[0]; for (m = 0; m < 5; m++) { rhs[j][i][m] = /* ... */; rhs[j][i][m] = /* ... */; (a) Figure 1 with explicit assumptions about the program behaviour. (b) Figure 2a after generalizing the assumptions to the whole region. Figure 2. The first two assumptions prevent integer overflow (Section 4.2) in the loop bounds, the third one out-of-bounds accesses (Section 4.5), and the last one ensures the absence of overlapping arrays (Section 4.6) and static control (Section 4.1). problem by an optimistic extension to polyhedral optimiza- tional high performance language and LLVM-IR a compiler tion. First we identify the properties of programs and low- IR which efficiently represents a variety of languages. level languages that hinder the straightforward application In Figure 3 we list five situations with important seman- of polyhedral approaches. Based on the program and these tic differences. In the polyhedral model there is no need to properties, we derive assumptions under which the polyhe- choose a type and a size for variables and arrays. The latter dral program description is faithful. These assumptions are can span infinitely in each dimension and arithmetic opera- checked at program runtime and if they are met the opti- tions can be performed in Z. Consequently, the concept of mistically applied polyhedral optimization is proven valid. out-of-bounds accesses or integer overflows does not apply. Reconsider Figure 1. The assumptions needed for the Additionally, each array can be placed in a disjunct part of straightforward application of polyhedral techniques are the infinite memory, thus they are completely disjoint. This shown in Figure 2a. Because the assumptions we derive elides the possibility of aliasing, an integral part of low-level are Presburger formulas, they are part of the polyhedral de- languages like C or LLVM-IR. Additionally, control flow has scription of the program and profit from standard polyhedral to be described statically and often needs to be bounded, thus transformations. Most important, by projection onto the pa- dynamic control and (partially) infinite loops are prohibited. rameter space, they can be hoisted out of the loop nest as These semantic mismatches can cause miscompilations, illustrated in Figure 2b. This generalization allows for a sin- in case they are ignored. Nevertheless, it is common practice gle runtime check that can be verified efficiently. for a polyhedral optimizer to require (and sometimes doc- In summary, we make the following contributions: ument) that the input code is never called in situations that 1. We identify several properties of programs and low-level result in semantic mismatches. This requirement is not only languages that hinder the straightforward applicability of hard to validate for programmers, but also hinders the auto- the polyhedral model (Section 2). matic optimization of unvalidated source code. 2. Based on these properties, we show how to derive as- C LLVM-IR PM sumptions under which the polyhedral description of the Referentially Transparent Expressions (RT) program is correct (Section 4). not-given not-given required 3. We show how these assumptions can be simplified to Expression Evaluation Semantics (EE) speed up their evaluation at runtime (Section 5). type- computation- evaluation in 4. We present an algorithm to generate a correct runtime dependent dependent Z check that verifies all preconditions (Section 6). Always Bounded Loops (BL) 5. Finally, we evaluate an implementation of our approach no no preferable in LLVM/Polly on a large set of benchmarks (includ- Always In-bound Accesses (IB) ing SPEC and NPB). The number of modeled non-trivial sometimes1 no yes loops nests increases by a factor of 3:9×, including sig- nificantly optimized benchmarks (Section 7). Aliasing Arrays (AA) possible possible impossible 2. Overview Figure 3. Semantics of C, LLVM-IR and the polyhedral model (PM) in different situations. We now discuss semantic differences across common pro- gram representations and describe the high-level design of a 2.2 Architecture new assumption framework to overcome these differences. Our approach allows to model programs that do not com- 2.1 Loop Program Semantics Across Languages pletely match the semantics of the polyhedral model by us- We analyze the semantics of loop programs in C as well 1 Out-of-Bound accesses to constant sized multi-dimensional arrays are as the LLVM intermediate representation (LLVM-IR) and undefined [1, Section 6.5.6].

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    13 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us