Two Optimization Blockers Limiting the Compiler to Generate Optimized Code

Modern compilers employ sophisticated algorithms to determine what values are computed in a program and how they are used[1]. However, compilers apply only safe optimizations to a program, and constraining the compiler to perform only safe optimizations eliminates possible sources of undesired run-time behavior.  But it also means that the programmer must make more of an effort to write programs in a way that the compiler can then transform into efficient machine-level code[1].

      A major optimization blocker is due to memory aliasing. Consider the following two procedures:

void zyb1(int *xp, int *yp)
{
    *xp += *yp;
    *xp += *yp;
}

void zyb2(int *xp, int *yp)
{
    *xp += 2* *yp;
}

      At first glance, both procedures seem to have identical behavior. And function zyb2 is more efficient. It requires only three memory references(read *xp, read *yp, write *xp), whereas zyb1 requires six. Hence, if a compiler is given procedure zyb1 to compile, one might think it could generate more efficient code based on the computations performed by zyb2.

      However, consider the case in which xp and yp are equal. The result of zyb1 will be that the value at xp will be increased by a factor of 4. On the other hand, the result of zyb2 will be that the value at xp will be increased by a factor of 3. The compiler therefore cannot generate code in the style of zyb2 as an optimized version of zyb1.

      A second optimization blocker is on account of function calls. As an example, consider the following two procedures:

int f();

int func1() {
    return f() + f() + f() + f();
}

int func2() {
    return 4*f();
}

It might seem at first that both compute the same result, but with func2 calling f only once, whereas func1 calls it four times. It is tempting to generate code in the style of func2 when given func1 as the source.

      But consider the following code for f:

int counter = 0;

int f() {    
    return counter++;
}

This function has a side effect—it modifies some part of the global program state[1]. In particular, a call to func1 would return 0+1+2+3=6, whereas a call to func2 yields 4·0=0.

      Most compilers do not try to determine whether a function is free of side effects. Instead, the compiler assumes the worst case and leaves function calls intact[1].

References

[1] Randal E. Bryant, David R. O'Hallaron(2011). COMPUTER SYSTEMS A Programmer's Perspective (Second Edition).Beijing: China Machine Press.