Loop optimization

<h2 id="representation-of-computation-and-transformations">Representation of computation and transformations</h2>
Since instructions inside loops can be executed repeatedly, it is frequently not possible to give a bound on the number of instruction executions that will be impacted by a loop optimization. This presents challenges when reasoning about the correctness and benefits of a loop optimization, specifically the representations of the computation being optimized and the optimization(s) being performed.<a class="footnote-ref" id="fnref:1" href="#fn:1">1</a>

<h2 id="optimization-via-a-sequence-of-loop-transformations">Optimization via a sequence of loop transformations</h2>
Loop optimization can be viewed as the application of a sequence of specific loop transformations (listed below or in Compiler transformations for high-performance computing<a class="footnote-ref" id="fnref:2" href="#fn:2">2</a>) to the source code or <a href="/facts/Intermediate_representation/s0qRrbfh">intermediate representation</a>, with each <a href="/facts/Program_transformation/lfNb25cd">transformation</a> having an associated test for legality. A transformation (or sequence of transformations) generally must preserve the temporal sequence of all <a href="/facts/Data_dependency/pkzwvqCf">dependencies</a> if it is to preserve the result of the program (i.e., be a legal transformation). Evaluating the benefit of a transformation or sequence of transformations can be quite difficult within this approach, as the application of one beneficial transformation may require the prior use of one or more other transformations that, by themselves, would result in reduced performance.
Common loop transformations include:

<ul><li><a href="/facts/Loop_fission/1KLcCE94">Fission</a> or distribution – loop fission attempts to break a loop into multiple loops over the same index range, but each new loop takes only part of the original loop's body. This can improve <a href="/facts/Locality_of_reference/fYFKDv5q">locality of reference</a>, both of the data being accessed in the loop and the code in the loop's body.</li>
<li><a href="/facts/Loop_fusion/1KLcCE94">Fusion</a> or combining – this combines the bodies of two adjacent loops that would iterate the same number of times (whether or not that number is known at compile time), as long as they make no reference to each other's data.</li>
<li><a href="/facts/Loop_interchange/7E3zEFnb">Interchange</a> or permutation – these optimizations exchange inner loops with outer loops. When the loop variables index into an array, such a transformation can improve locality of reference, depending on the array's layout.</li>
<li><a href="/facts/Loop_inversion/QAK1Pb4z">Inversion</a> – this technique changes a standard while loop into a do/while (a.k.a. repeat/until ) loop wrapped in an if conditional, reducing the number of jumps by two for cases where the loop is executed. Doing so duplicates the condition check (increasing the size of the code) but is more efficient because jumps usually cause a <a href="/facts/Pipeline_stall/e3Ee0yJg">pipeline stall</a>. Additionally, if the initial condition is known at compile-time and is known to be <a href="/facts/Side-effect_(computer_science)/AU3GlLzG">side-effect</a>-free, the initial if-guard can be skipped.</li>
<li><a href="/facts/Loop-invariant_code_motion/9jBNoTdm">Loop-invariant code motion</a> – this can vastly improve efficiency by moving a computation from inside the loop to outside of it, computing a value just once before the loop begins, if the resultant quantity of the calculation will be the same for every loop iteration (i.e., a loop-invariant quantity). This is particularly important with address-calculation expressions generated by loops over arrays. For correct implementation, this technique must be used with inversion, because not all code is safe to be moved outside the loop.</li>
<li><a href="/facts/Loop-level_parallelism/b1yxdsJp">Parallelization</a> – this is a special case of <a href="/facts/Automatic_parallelization/t40BDoWG">automatic parallelization</a> focusing on loops, restructuring them to run efficiently on multiprocessor systems. It can be done automatically by compilers (<a href="/facts/Automatic_parallelization/t40BDoWG">automatic parallelization</a>) or manually (inserting parallel directives like <a href="/facts/OpenMP/69IpI80o">OpenMP</a>).</li>
<li>Reversal – a subtle optimization that reverses the order in which values are assigned to the index variable. This can help eliminate <a href="/facts/Dependence_analysis/4d0geS3g">dependencies</a> and thus enable other optimizations. Certain architectures utilize looping constructs at <a href="/facts/Assembly_language/7XuV0cla">assembly</a> level that count in a single direction only (e.g., decrement-jump-if-not-zero [DJNZ]<a class="footnote-ref" id="fnref:3" href="#fn:3">3</a>).</li>
<li><a href="/facts/Loop_scheduling/RNXhxFKc">Scheduling</a> – this divides a loop into multiple parts that may be run concurrently on multiple processors.</li>
<li><a href="/facts/Loop_skewing/FXMVblEf">Skewing</a> – this technique is applied to a nested loop iterating over a multidimensional array, where each iteration of the <a href="/facts/Inner_loop/Hj8hAgj8">inner loop</a> depends on previous iterations, and rearranges its array accesses so that the only dependencies are between iterations of the outer loop.</li>
<li><a href="/facts/Software_pipelining/CgCc5e7c">Software pipelining</a> – a type of <a href="/facts/Out-of-order_execution/bM0dQM8m">out-of-order execution</a> of loop iterations to hide the latencies of processor function units.</li>
<li><a href="/facts/Loop_splitting/um2pJKcA">Splitting</a> or peeling – this attempts to simplify a loop or eliminate <a href="/facts/Dependence_analysis/4d0geS3g">dependencies</a> by breaking it into multiple loops which have the same bodies but iterate over different portions of the index range. A special case is loop peeling, which can simplify a loop with a problematic first iteration by performing that iteration separately before entering the loop.</li>
<li><a href="/facts/Loop_tiling/18lFS1CI">Tiling</a> or blocking – reorganizes a loop to iterate over blocks of data sized to fit in the cache.</li>
<li><a href="/facts/Automatic_vectorization/YzD5uHsX">Vectorization</a> – attempts to run as many of the loop iterations as possible at the same time on a <a href="/facts/SIMD/gQHWQSpo">SIMD</a> system.</li>
<li><a href="/facts/Loop_unrolling/uasvbJWE">Unrolling</a> – duplicates the body of the loop multiple times, in order to decrease the number of times the loop condition is tested and the number of jumps, which may degrade performance by impairing the instruction pipeline. Completely unrolling a loop eliminates all overhead (except multiple instruction fetches and increased program load time), but requires that the number of iterations be known at compile time (except in the case of <a href="/facts/Just-in-time_compilation/rEYDsd8l">Just-in-time compilation</a>). Care must also be taken to ensure that multiple re-calculation of indexed variables is not a greater overhead than advancing pointers within the original loop.</li>
<li><a href="/facts/Loop_unswitching/GsJQcDow">Unswitching</a> – moves a conditional from inside a loop to outside of it by duplicating the loop's body, and placing a version of it inside each of the if and else clauses of the conditional.</li>
<li><a href="/facts/Loop_sectioning/fvcjIqaK">Sectioning</a> or strip-mining – introduced for <a href="/facts/Vector_processor/nYAsIKT0">vector processors</a>, loop-sectioning is a loop-transformation technique for enabling <a href="/facts/SIMD/gQHWQSpo">SIMD</a> (single instruction, multiple data)-encodings of loops and improving memory performance. This involves each vector operation being done for a size less-than or equal-to the maximum vector length on a given vector machine.<a class="footnote-ref" id="fnref:4" href="#fn:4">4</a><a class="footnote-ref" id="fnref:5" href="#fn:5">5</a></li></ul>
<h3>The unimodular transformation framework</h3>
The unimodular transformation approach<a class="footnote-ref" id="fnref:6" href="#fn:6">6</a> uses a single <a href="/facts/Unimodular_matrix/J6bRTkN4">unimodular matrix</a> to describe the combined result of a sequence of many of the above transformations. Central to this approach is the view of the set of all executions of a statement within n loops as a set of integer points in an n-dimensional space, with the points being executed in <a href="/facts/Lexicographical_order/xQANy8Br">lexicographical order</a>. For example, the executions of a statement nested inside an outer loop with index i and an inner loop with index j can be associated with the pairs of integers ⁠
 
 
 
 (
 i
 ,
 j
 )
 
 
 {\displaystyle (i,j)}
 
⁠. The application of a unimodular transformation corresponds to the multiplication of the points within this space by the matrix. For example, the interchange of two loops corresponds to the matrix 
 
 
 
 
 
 [
 
 
 
 0
 
 
 1
 
 
 
 
 1
 
 
 0
 
 
 
 ]
 
 
 
 
 {\displaystyle {\begin{bmatrix}0&1\\1&0\end{bmatrix}}}
 
.
A unimodular transformation is legal if it preserves the temporal sequence of all <a href="/facts/Data_dependency/pkzwvqCf">dependencies</a>; measuring the performance impact of a unimodular transformation is more difficult. Imperfectly nested loops and some transformations (such as tiling) do not fit easily into this framework.

<h3>The polyhedral or constraint-based framework</h3>
The <a href="/facts/Polytope_model/FXMVblEf">polyhedral model</a><a class="footnote-ref" id="fnref:7" href="#fn:7">7</a> handles a wider class of programs and transformations than the unimodular framework. The set of executions of a set of statements within a possibly imperfectly nested set of loops is seen as the union of a set of polytopes representing the executions of the statements. <a href="/facts/Affine_transformation/BD7yDr10">Affine transformations</a> are applied to these polytopes, producing a description of a new execution order. The boundaries of the polytopes, the data dependencies, and the transformations are often described using systems of constraints, and this approach is often referred to as a constraint-based approach to loop optimization. For example, a single statement within an outer loop 'for i := 0 to n' and an inner loop 'for j := 0 to i+2' is executed once for each (i, j) pair such that 0 <= i <= n and 0 <= j <= i+2.
Once again, a transformation is legal if it preserves the temporal sequence of all <a href="/facts/Data_dependency/pkzwvqCf">dependencies</a>. Estimating the benefits of a transformation, or finding the best transformation for a given code on a given computer, remain the subject of ongoing research as of the time of this writing (2010).

<h2 id="see-also">See also</h2>
<ul><li><a href="/facts/Loop_nest_optimization/18lFS1CI">Loop nest optimization</a></li>
<li><a href="/facts/Polytope_model/FXMVblEf">Polytope model</a></li>
<li><a href="/facts/Scalable_parallelism/qL93FVoN">Scalable parallelism</a></li>
<li><a href="/facts/Scalable_locality/FIN7tWDH">Scalable locality</a></li></ul>

<h2 id="references">References</h2>

<ol>
<li id="fn:1">In the book Reasoning About Program Transformations, Jean-Francois Collard discusses in depth the general question of representing executions of programs rather than program text in the context of static optimization. <a href="https://books.google.com/books?id=8FbTZc4pa-cC&q=%22loop+optimization%22" target="_blank">https://books.google.com/books?id=8FbTZc4pa-cC&q=%22loop+optimization%22</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></li>
<li id="fn:2">David F. Bacon, Susan L. Graham, and Oliver J. Sharp. Compiler transformations for high-performance computing. Report No. UCB/CSD 93/781, Computer Science Division-EECS, University of California, Berkeley, Berkeley, California 94720, November 1993 (available at CiteSeer [1]). Introduces compiler analysis such as data dependence analysis and interprocedural analysis, as well as a very complete list of loop transformations <a href="/wiki/Susan_L._Graham" target="_blank">/wiki/Susan_L._Graham</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></li>
<li id="fn:3">"8051 Instruction Set". www.win.tue.nl. Retrieved 2019-12-09. <a href="https://www.win.tue.nl/~aeb/comp/8051/set8051.html-orig#51djnz" target="_blank">https://www.win.tue.nl/~aeb/comp/8051/set8051.html-orig#51djnz</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></li>
<li id="fn:4">"Intel Developer Zone". <a href="http://software.intel.com/en-us/articles/strip-mining-to-optimize-memory-use-on-32-bit-intel-architecture/" target="_blank">http://software.intel.com/en-us/articles/strip-mining-to-optimize-memory-use-on-32-bit-intel-architecture/</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></li>
<li id="fn:5">"7.6.3.1 Strip-Mining (Sun Studio 12: Fortran Programming Guide)". <a href="http://download.oracle.com/docs/cd/E19205-01/819-5262/aeugr/index.html" target="_blank">http://download.oracle.com/docs/cd/E19205-01/819-5262/aeugr/index.html</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></li>
<li id="fn:6">Steven S. Muchnick, Advanced Compiler Design and Implementation, 1997 Morgan Kaufmann. Section 20.4.2 discusses loop optimization. <a href="https://books.google.com/books?id=Pq7pHwG1_OkC&q=%22unimodular+transformation%22" target="_blank">https://books.google.com/books?id=Pq7pHwG1_OkC&q=%22unimodular+transformation%22</a> <a href="#fnref:6" class="footnote-back-ref">↩</a></li>
<li id="fn:7">R. Allen and K. Kennedy. Optimizing Compilers for Modern Architectures. Morgan Kaufmann, 2002. <a href="#fnref:7" class="footnote-back-ref">↩</a></li>
</ol>

Loop optimization open-in-new

Loop optimization