Loop Quasi-Invariant Chunk Motion by peeling with statement composition

TL;DR

This paper introduces a novel dependency analysis technique using statement composition to identify quasi-invariants in loops, enabling more effective loop peeling and potential complexity reduction in compiler optimizations.

Contribution

It proposes a new ICC-inspired analysis for composed statements called Chunks, allowing detection of quasi-invariants and loop optimization opportunities in compilers.

Findings

Implemented a proof of concept on a toy C parser analyzing ASTs.

Developed a prototype analysis pass on LLVM.

Theoretical framework for dependency analysis with statement composition.

Abstract

Several techniques for analysis and transformations are used in compilers. Among them, the peeling of loops for hoisting quasi-invariants can be used to optimize generated code, or simply ease developers' lives. In this paper, we introduce a new concept of dependency analysis borrowed from the field of Implicit Computational Complexity (ICC), allowing to work with composed statements called Chunks to detect more quasi-invariants. Based on an optimization idea given on a WHILE language, we provide a transformation method - reusing ICC concepts and techniques - to compilers. This new analysis computes an invariance degree for each statement or chunks of statements by building a new kind of dependency graph, finds the maximum or worst dependency graph for loops, and recognizes if an entire block is Quasi-Invariant or not. This block could be an inner loop, and in that case the computational complexity of the overall program can be decreased. We already implemented a proof of concept on a toy C parser 1 analysing and transforming the AST representation. In this paper, we introduce the theory around this concept and present a prototype analysis pass implemented on LLVM. In a very near future, we will implement the corresponding transformation and provide benchmarks comparisons.

Equations

$$\mathrm{M}({\mathtt{C}}_{\_}{1}^{\ast })={\mathrm{limit}}_{\_}k\to \infty \underset{\_}{⨁}{i=1}^k\mathrm{M}({\mathtt{C}}_{\_}1{)}^i$$

$$[[\mathtt{while}\mathtt{E}\mathtt{do}{\mathtt{C}}_{\_}1]]\equiv [[\mathtt{if}\mathtt{E}\mathtt{then}{\mathtt{C}}_{\_}1;\mathtt{While}\mathtt{E}\mathtt{do}\mathtt{skip}]]$$

$$[[\mathtt{while}\mathtt{E}\mathtt{do}[{\mathtt{C}}_{\_}1;{\mathtt{C}}_{\_}2]]]\equiv [[\mathtt{if}\mathtt{E}\mathtt{then}{\mathtt{C}}_{\_}1;\mathtt{while}\mathtt{E}\mathtt{do}{\mathtt{C}}_{\_}2]]$$

Full text

In this paper, we introduce the theory around this concept and present a prototype analysis pass implemented on LLVM. In a very near future, we will implement the corresponding transformation and provide benchmarks comparisons.

1 Introduction

A command inside a loop is an invariant if its execution has no effect after the first iteration of the loop. Typically, an assignment x:=0 in a loop is invariant (provided x is not modified elsewhere). Loop invariants can safely be moved out of loops (hoisted) in order to make the program faster.

A command inside a loop is quasi-invariant if its execution has no effect after a finite number of iterations of the loop. Typically, if a loop contains the sequence x:=y, y:=0, then y:=0 is invariant. However, x:=y is not invariant. The first time the loop is executed, x will be assigned the old value of y, and only from the second time onward will x be assigned the value 0. Hence, this command is quasi-invariant. It can still be hoisted out of the loop, but to do so requires to peel the loop first, that is execute its body once (by copying it before the loop).

The number of times a loop must be executed before a quasi-invariant can be hoisted is called here the degree of the invariant.

An obvious way to detect quasi-invariants is to first detect invariants (that is, quasi-invariants of degree 1) and hoist them; and iterate the process to find quasi-invariant of degree 2, and so on. This is, however, not very efficient since it may require a large number of iterations to find some invariance degrees.

We provide here an analysis able to directly detect the invariance degree of any statements in the loop. Moreover, our analysis is able to assign an invariance degree non only to individual statements but also to groups of statements (called chuncks). That way it is possible, for example, to detect that a whole inner loop is invariant and hoist it, thus decreasing the asymptotic complexity of the program.

Loop optimization techniques based on quasi-invariance are well-known in the compilers community. The transformation idea is to peel loops a finite number of time and hoist invariants until there are no more quasi-invariants. As far as we know, this technique is called “peeling” and it was introduced by Song et al. [14].

The present paper offers a new point of view on this work. From an optimization on a WHILE language by Lars Kristiansen [10], we provide a redefinition of peeling and another transformation method based on techniques developed in the field of Implicit Computational Complexity.

Implicit Computational Complexity (ICC) studies computational complexity in terms of restrictions of languages and computational principles, providing results that do not depend on specific machine models. Based on static analysis, it helps predict and control resources consumed by programs, and can offer reusable and tunable ideas and techniques for compilers. ICC mainly focuses on syntactic [5, 4], type [7, 3] and Data Flow [12, 8, 9, 13] restrictions to provide bounds on programs’ complexity. The present work was mainly inspired by the way ICC community uses different concepts to perform Data Flow Analysis, e.g. “Size-change Graphs” [12] or “Resource Control Graphs”[13] which track data values’ behavior and use a matrix notation inspired by [2], or “mwp-polynomials” [9] to provide bounds on data size.

For our analysis, we focus on dependencies between variables to detect invariance. Dependency graphs [11] can have different types of arcs representing different kind of dependencies. Here we will use a kind of Dependence Graph Abstraction [6] that can be used to find local and global quasi-invariants. Based on these techniques, we developed an analysis pass and we will implement the corresponding transformation in LLVM.

We propose a tool which is notably able to give enough information to easily peel and hoist an inner loop, thus decreasing the complexity of a program from $n^{2}$ to $n$.

1.1 State of the art on Quasi-Invariant detection in loop

Invariants are basically detected using algorithm 1.

A dependency graph around variables is needed to provide relations between statements. For quasi-invariance, we need to couple dependence and dominance informations. In [14], the authors define a variable dependency graph (VDG) and detect a loop quasi-invariant variable x if, among all paths ending at x, no path contain a node included in a circular path. Then they deduce an invariant length which corresponds to the length of the longest path ending in x. In the present paper, this length is called invariance degree.

1.2 Contributions

To the authors’ knowledge, this is the first application of ICC techniques on a mainstream compiler. One interest is that our tool potentially applies to programs written in any programming language managed by LLVM. Moreover, this work should be considered as a first step of a larger project that will make ICC techniques more accessible to programmers.

On a more technical side, our tool aims at improving on currently implemented loop invariant detection and optimization techniques. The main LLVM tool for this purpose, Loop Invariant Code Motion (LICM), does not detect quasi-invariant of degree more than $3$ (and not all of those of degree $2$). More importantly, LICM will not detect quasi-invariant blocks of code (what we call chunk), such as whole loops. Our tool, on the other hand, detects quasi-invariants of arbitrary degree and is able to deal with chunks. For instance the optimization shown in Figure 9 is not performed by LLVM nor in GCC even at their maximum optimization level.

2 In theory

In this section, we redefine our own types of relations between variables to build a new dependency graph and apply a composition inspired by the graph composition of Size-Change Termination [12].

2.1 Relations and Data Flow Graph

We work with a simple imperative WHILE-language (the grammar is shown in Figure 1), with semantics similar to C.

A WHILE program is thus a sequence of statements, each statement being either an assignment, a conditional, a while loop, a function call or a skip. The use command represents any command which does not modify its variables but use them and should not be moved around carelessly (typically, a printf). Statements are abstracted into commands. A command can be a statement or a sequence of commands. We also call a sequence of commands a chunk.

We start by giving an informal but intuitive definition of the notion of Data Flow Graph (DFG). A DFG represents dependencies between variables as a bipartite graph as in Figure 2. Each different types of arrow represents different types of dependencies.

Each variable is shown twice: the occurrence on the left represents the variable before the execution of the command while the occurrence on the right represents the variable after the execution. Dependencies are then represented by two types of arrows from variables on the left to variables on the right: plain arrows for direct dependency, dashed arrows for propagation. Reinitialisation of a variable $z$ then corresponds to the absence of arrows ending on the right occurrence of $z$. Figure 2 illustrates these types of dependencies; let us stress here that the DFG would be the same if the assignment $y=y;$ were to be removed222Note that $y=y;$ does not create a direct dependence from $\mathtt{C}$ since the value of $y$ is still propagated.

More formally, a DFG of a command $\mathtt{C}$ is a triple $(V,\mathcal{R}_{\_}{\mathrm{dep}},\mathcal{R}_{\_}{\mathrm{prop}})$ with $V$ the variables involved in the command $\mathtt{C}$ and a pair of two relations on the set of variables. These two relations express how the values of the involved variables after the execution of the command depend on their values before the execution. There is a direct dependence between variables appearing in an expression and the variable on the left-hand side of the assignment. For instance $x$ directly depends on $y$ and $z$ in the statement $x=y+z;$. When variables are unchanged by the command we call it propagation. Propagation only happens when a variable is not affected by the command, not when it is copied from another variable. If the variable is set to a constant, we call this a reinitialization.

More technically, we will work with an alternative representation in terms of matrices. While less intuitive, this allows for more natural compositions, based on standard linear algebra operations. Before providing the formal definition, let us introduce the semi-ring $\{\emptyset,0,1\}$: the addition $\oplus$ and multiplication $\otimes$ are defined in Figure 3. Let us remark that, identifying $\emptyset$ as $-\infty$, this is a sub-semi-ring of the standard tropical semi-ring, with $\oplus$ and $\otimes$ interpreted as $\max$ and $+$ respectively.

Definition 1

A Data Flow Graph for a command $\mathtt{C}$ is a $n\times n$ matrix over the semi-ring $\{\emptyset,0,1\}$ where $n$ is the number of variables involved in $\mathtt{C}$.

We write $\mathrm{M}(\mathtt{C})$ the DFG of $\mathtt{C}$. At line $i$, column $j$, we have a $\emptyset$ if the output value of the $j$th variable does not depend on the input value of the $i$th; a [math] in case of propagation (unmodified variable); and a $1$ for any other kind of dependence.

Definition 2

*Let $\mathtt{C}$ be a command. We define $\mathrm{In}(\mathtt{C})$ (resp. $\mathrm{Out}(\mathtt{C})$) as the set of variables used (resp. modified) by $\mathtt{C}$. *

Note that $\mathrm{In}(\mathtt{C})$ and $\mathrm{Out}(\mathtt{C})$ are exactly the set of variables that are at either ends of the “dependence” arrows.

2.2 Constructing DFGs

We now describe how the DFG of a command can be computed by induction on the structure of the command. Base cases (skip, use and assignment) are done in the obvious way, generalising slightly the definitions of DFGs shown in Figure 2.

2.2.1 Composition and Multipath

We now turn to the definition of the DFG for a (sequential) composition of commands. This abstraction allows us to see a block of statements as one command with its own DFG.

Definition 3

Let $\mathtt{C}$ be a sequence of commands $[\mathtt{C_{\_}{1}};\mathtt{C_{\_}{2}};\dots;\mathtt{C_{\_}{n}}]$. Then $\mathrm{M}(\mathtt{C})$ is defined as the matrix product $\mathrm{M}(\mathtt{C_{\_}{1}})\mathrm{M}(\mathtt{C_{\_}{2}})\dots\mathrm{M}(\mathtt{C_{\_}{n}})$.

Following the usual product of matrices, the product of two matrices $A,B$ is defined here as the matrix $C$ with coefficients: $C_{\_}{i,j}=\bigoplus_{\_}{k=1}^{n}(A_{\_}{i,k}\otimes B_{\_}{k,j})$.

This operation of matrix multiplication corresponds to the computation of multipaths [12] in the graph representation of DFGs. We illustrate this intuitive construction on an example in Figure 4.

2.2.2 Condition

We now explain how to compute the DFG of a command $\mathtt{C}:=\mathtt{if\ E\ then\ C_{\_}{1};}$, from the DFG of the command $\mathtt{C_{\_}{1}}$.

Firstly, we notice that in $\mathtt{C}$, all modified variables in $\mathtt{C_{\_}{1}}$, i.e. in $\mathrm{Out}(\mathtt{C_{\_}{1}})$, will depend on the variables used in $\mathtt{E}$. Let us denote by $\mathrm{M}(\mathtt{C_{\_}{1}})^{[\mathtt{E}]}$ the corresponding DFG, i.e. the matrix $\mathrm{M}(\mathtt{C_{\_}{1}})\oplus(E^{t}O)$, where $E$ (resp. $O$) is the vector representing variables in333I.e. the vector with a coefficient equal to $1$ for the variables in $\mathrm{Var}(\mathtt{E})$, and $\emptyset$ for all others variables. $\mathrm{Var}(\mathtt{E})$ (resp. in $\mathrm{Out}(C_{\_}{1})$), and $(\cdot)^{t}$ denotes the transpose.

Secondly, we need to take into account that the command $\mathtt{C_{\_}{1}}$ may be skipped. In that case, the overall command $\mathtt{C}$ should act as an empty command, i.e. be represented by the identity matrix $\mathrm{Id}$ (diagonal elements are equal to [math], all other are equal to $\emptyset$).

Finally, the DFG of a conditional will be computed by summing these two possibilities, as in Figure 5.

Definition 4

Let $\mathtt{C}$ be a command of the form $\mathtt{if\ E\ then\ C_{\_}{1};}$. Then $\mathrm{M}(\mathtt{C})=\mathrm{M}(\mathtt{C_{\_}{1}})^{[\mathtt{E}]}\oplus\mathrm{Id}$.

2.2.3 While Loop

Finally, let us define the DFG of a command $\mathtt{C}$ of the form $\mathtt{C}:=\mathtt{while\ E\ do\ C_{\_}{1};}$. This definition splits into two steps. First, we define a matrix $\mathrm{M}(\mathtt{C_{\_}{1}^{\ast}})$ representing iterations of the command $\mathtt{C_{\_}{1}}$; then we deal with the condition of the loop in the same way we interpreted the conditional above.

When considering iterations of $\mathtt{C_{\_}{1}}$, the first occurrence of $\mathtt{C_{\_}{1}}$ will influence the second one and so on. Computing the DFG of $\mathtt{C_{\_}{1}^{n}}$, the $n$-th iteration of $\mathtt{C_{\_}{1}}$, is just computing the power of the corresponding matrix, i.e. $\mathrm{M}(\mathtt{C_{\_}{1}^{n}})=\mathrm{M}(\mathtt{C_{\_}{1}})^{n}$. But since the number of iteration cannot be decided a priori, we need to add all possible values of $n$. The following expression then expresses the DFG of the (informal) command $\mathtt{C_{\_}{1}^{\ast}}$ corresponding to ”iterating $\mathtt{C_{\_}{1}}$ a finite (but arbitrary) number of times”:

[TABLE]

To ease notations, we note $\mathrm{M}(\mathtt{C_{\_}{1}^{(k)}})$ the partial summations $\sum_{\_}{i=1}^{k}\mathrm{M}(\mathtt{C_{\_}{1}})^{i}$.

Since the set of all relations is finite and the sequence $(\mathrm{M}(\mathtt{C_{\_}{1}^{(k)}}))_{\_}{k\geqslant 0}$ is monotonous, this sequence is eventually constant. I.e., there exists a natural number $N$ such that $\mathrm{M}(\mathtt{C_{\_}{1}^{(k)}})=\mathrm{M}(\mathtt{C_{\_}{1}^{(N)}})$ for all $k\geqslant N$. One can obtain the following bound on the value of $N$.

Lemma 1

Consider a command $\mathtt{C}$ and define $K=\min(i,o)$, where $i$ (resp. $o$) denotes the number of variables in $\mathrm{In}(\mathtt{C})$ (resp. $\mathrm{Out}(\mathtt{C})$). Then, the sequence $(\mathrm{M}(\mathtt{C^{(k)}}))_{\_}{k\geqslant K}$ is constant.

Figure 6 illustrates the computation of $\cdot^{\ast}$. The second step then consists in dealing with the loop condition, using the same constructions as for conditionals.

Definition 5

Let $\mathtt{C}$ be a command of the form $\mathtt{while\ E\ do\ C_{\_}{1};}$. Then $\mathrm{M}(\mathtt{C})=\mathrm{M}(\mathtt{C_{\_}{1}^{\ast}})^{[\mathtt{E}]}$.

2.3 Independence

Our purpose is to move commands around: exchange them, but more importantly to pull them out of loops when possible. We allow these moves only when semantics are preserved: to ensure this is the case, we describe a notion of independence.

Definition 6

If $\mathrm{Out}(\mathtt{C_{\_}{1}})\cap\mathrm{In}(\mathtt{C_{\_}{2}})=\emptyset$ then $\mathtt{C_{\_}{2}}$ is independent from $\mathtt{C_{\_}{1}}$. This is denoted $\mathtt{C_{\_}{1}}\prec\mathtt{C_{\_}{2}}$.

It is important to notice that this notion is not symmetric. As an example, let us consider Figure 7:

Here, $\mathtt{C_{\_}{2}}$ is independent from $\mathtt{C_{\_}{1}}$ but the inverse is not true.

A particular case is self-independence, i.e. independence of a command w.r.t. itself. In that case, we can find non-trivial program transformations preserving the semantics. We denote by $\llbracket\mathtt{C}\rrbracket\equiv\llbracket\mathtt{D}\rrbracket$ the relation ”$\mathtt{C}$ and $\mathtt{D}$ have the same semantics”.

Lemma 2** (Specialization for while)**

If $\mathtt{C_{\_}{1}}$ is self-independent and $\mathrm{Var}(\mathtt{E})\cap\mathrm{Out}(C_{\_}{1})=\emptyset$:

[TABLE]

Remark that we need to keep the loop $\mathtt{While}$ with a skip statement inside because we need to consider an infinite loop if $\mathtt{E}$ is always true to keep the semantic equivalent.

In general, we will consider mutual independence.

Definition 7

If $\mathtt{C_{\_}{2}}\prec\mathtt{C_{\_}{1}}$ and $\mathtt{C_{\_}{1}}\prec\mathtt{C_{\_}{2}}$, we say that $\mathtt{C_{\_}{2}}$ and $\mathtt{C_{\_}{1}}$ are mutually independents, and write $\mathtt{C_{\_}{1}}\asymp\mathtt{C_{\_}{2}}$.

While independence in one direction only, such as in the example above, does not imply that $\mathtt{C_{\_}{1}};\mathtt{C_{\_}{2}}$ and $\mathtt{C_{\_}{2}};\mathtt{C_{\_}{1}}$ have the same semantics, mutual independence allows to perform program transformation that do not impact the semantics.

Lemma 3** (Swapping commands)**

If $\mathtt{C_{\_}{1}}\asymp\mathtt{C_{\_}{2}}$, then $\llbracket\mathtt{C_{\_}{1}};\mathtt{C_{\_}{2}}\rrbracket\equiv\llbracket\mathtt{C_{\_}{2}};\mathtt{C_{\_}{1}}\rrbracket$

Lemma 4** (Moving out of while loops)**

If $\mathtt{C_{\_}{1}}$ is self-independent (i.e. $\mathtt{C_{\_}{1}}\asymp\mathtt{C_{\_}{1}}$), and if $\mathtt{C_{\_}{1}}\asymp\mathtt{C_{\_}{2}}$, then:

[TABLE]

Based on those lemmas, we can decide that an entire block of statement is invariant or quasi-invariant in a loop by computing the DFGs. The quasi-invariance comes with an invariance degree wich is the number of time the loop needs to be peeled to be able to hoist the corresponding invariant. We can then implement program transformations that reduce the overall complexity while preserving the semantics.

3 In practice

This section explains how we implemented the pass which computes the invariance degree and gives the main idea of how the transformation can be performed. In the previous Section, we have seen that the transformation is possible from and to a While language; and from a previous implementation444https://github.com/ThomasRuby/LQICM_On_C_Toy_Parser, we have shown it can be done on C Abstract Syntax Trees.

Compilers, and especially LLVM on which we are working, use an Intermediate Representation to handle programs. This is an assembly-like language that is used during all the stages of the compilation. Programs (in various different languages) are first translated into the IR, then several optimisations are performed (implemented in so-called passes), and finally the resulting IR is translated again in actual assembly language depending on the machine it will run on. Using a common IR allows to do the same optimisations on several different source languages and for several different target architectures.

One important feature of the LLVM IR is the Single Static Assignment form (SSA). A program is in SSA form if each variable is assigned at most once. In other words, setting a program in SSA form require a massive $\alpha$-conversion of all the variables to ensure uniqueness of names. The advantages are obvious since this removes any name-aliasing problem and ease analysis and transformation.

The main drawback of SSA comes when several different paths in the Control Flow reach the same point (typically, after a conditional). Then, the values used after this point may come from any branch and this cannot be statically decided. For example, if the original program is if (y) then x:=0 else x:=1;C, it is relatively easy to turn it into a pseudo-SSA form by $\alpha$-converting the x: if (y) then x${}_{\_}0$:=0 else x${}_{\_}1$:=1;C but we do not know in C which of x${}_{\_}0$ or x${}_{\_}1$ should be used.

SSA solves this problem by using $\varphi$-functions that, at runtime, can choose the correct value depending on the path just taken. That is, the correct SSA form will be if (y) then x${}_{\_}0$:=0 else x${}_{\_}1$:=1; X:=$\varphi$(x${}_{\_}0$, x${}_{\_}1$); C.

While the SSA itself eases the analysis, we do have to take into account the $\varphi$ functions and handle them correctly.

3.1 Preliminaries

First, we want to visit all loops using a bottom-up strategy (the inner loop first). Then, as for the Loop Invariant Code Motion (LICM) pass, our pass is derived from the basic LoopPass. Which means that each time a loop is encountered, our analysis is performed.

At this point, the purpose is to gather the relations of all instructions in the loop to compose them and provide the final relation for the current loop. We decided to define a Relation object by three SmallPtrSet of Value*, listing the variables, the propagations and the initializations. Furthermore we represent the dependencies by a DenseMap of Value* to SmallPtrSet<Value*>. This way of representing our data is not fixed, it’s certainly optimizable, but we think it’s sufficient for our prototype analysis and examples. We will discuss the cost of this analysis later.

Then a Relation is generated for each command using a top-down strategy following the dominance tree. The SSA form helps us to gather dependence information on instructions. By visiting operands of each assignment, it’s easy to build our map of Relation. With all the current loop’s relations gathered, we compute the compositions, condition corrections and the maximums relations possible as described previously. Obviously this method can be enhanced by an analysis on bounds around conditional and number of iterations for a loop. Finally, with those composed relations we compute an invariance degree for each statement in the loop.

The only chunks considered in the current implementation are the one consisting of while or if-then-else statements.

3.2 Invariance degree computation

In this part, we will describe an algorithm – using the previous concepts – to compute the invariance degree of each quasi-invariant in a loop. After that, we will be able to peel the loop at once instead of doing it iteratively. To simplify and as a recall, Figure 8 shows a basic example of peeled loop.

The invariance degrees are given as comment after each Quasi-Invariant statements. So b=y+y is invariant of degree equal to one because y is invariant, that means it could be hoisted directly in the preheader of the loop. But b is used before, in b=b+1, so it’s not the same b at the first iteration. We need to isolate this case by peeling one time the entire loop to use the first b computed by the initial b. If b=y+y is successfully hoisted, then b is now invariant. So we can remove b=b+1 but we need to do it at least one time after the first iteration to set b to the new and invariant value. This is why the loop is peeled two times. The first time, all the statements are executed. The second time, the first degree invariants are removed. The main work is to compute the proper invariance degree for each statement and composed statements. This can be done statically using the dependency graph and dominance graph. Here is the algorithm. Let suppose we have computed the list of dependencies for all commands in a loop.

This algorithm is dynamic. It stores progressively each degree needed to compute the current one and reuse them. Note that, for the initialization part, we are using LLVM methods (canSinkOrHoist, isGuaranteedToExecute etc…) to figure out if an instruction is movable or not. These methods provide the anchors instructions for the current loop.

3.3 Peeling loop idea

The transformation will consists in creating as many preheaders basic blocks before the loop as needed to remove all quasi-invariants out of the loop. Each preheader will have the same condition as the .cond block of the loop and will contain the incrementation of the iteration variable. The maximum invariance degree is the number of time we need to peel the loop. So we can create as many preheaders before the loop. For each block created, we include every commands with a higher or equal invariance degree. For instance, the first preheader block will contain every commands with an invariance degree higher or equal to $1$, the second one, higher or equal to $2$ etc… and the final loop will contain every commands with an invariance degree equal to $\infty$.

4 Conclusion and Future work

Developers expect that compilers provide certain more or less “obvious” optimizations. When peeling is possible, that often means: either the code was generated; or the developers prefer this form (for readability reasons) and expect that it will be optimized by the compiler; or the developers haven’t seen the possible optimization (mainly because of the obfuscation level of a given code).

Our generic pass is able to provide a reusable abstract dependency graph and the quasi-invariance degrees for further loop optimization or analysis.

In this example (Figure 9), we compute the same factorial several times. We can detect it statically, so the compiler has to optimize it at least in -O3. Our tests showed that is done neither in LLVM nor in GCC (we also tried -fpeel_loops with profiling). The generated assembly shows the factorial computation in the inner loop.

Moreover, the computation time of this kind of algorithm compiled with clang in -O3 still computes $n$ times the inner loop so the computation time is quadratic, while hoisting it result in linear time. For the example shown in Figure 9, our pass computes the degrees shown in Figure 11 (where $-1$ represents a degree of $\infty$, that is an instruction that cannot be hoisted).

To each instruction printed corresponds an invariance degree. The assignment instructions are listed by loops, the inner loop (starting with while.cond3) and the outer loop (starting with while.cond). The inner loop has its own invariance degree equal to $1$ (line $9$). Remark that we do consider the phi initialization instructions of an inner loop. Here %fact.0 and %i.1 are reinitialized in the inner loop condition block. So phi instructions are analysed in two different cases: to compute the relation of the current loop or to give the initialization of a variable sent to an inner loop. Our analysis only takes the relevant operand regarding to the current case and do not consider others.

The code of this pass is available online555https://github.com/ThomasRuby/lqicm_pass. To provide some real benchmarks on large programs we need to implement the transformation. We are currently implementing this second pass on LLVM.

Acknowledgments

The authors wish to thank L. Kristiansen for communicating a manuscript [10] that initiated the present work. Jean-Yves Moyen is supported by the European Commision’s Marie Skłodowska-Curie Individual Fellowship (H2020-MSCA-IF-2014) 655222 - Walgo; Thomas Rubiano is supported by the ANR project “Elica” ANR-14-CE25-0005; Thomas Seiller is supported by the European Commision’s Marie Skłodowska-Curie Individual Fellowship (H2020-MSCA-IF-2014) 659920 - ReACT.