Two Optimization Blockers Limiting the Compiler to Generate Optimized Code
2013-11-20 22:38
447 查看
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:
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:
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:
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.
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.
相关文章推荐
- Question 29: The C++ code below generates a compiler error. Which of the following solutions can be used to correctly access the
- Unable to evaluate expression because the code is optimized or a native frame is on top of the call stack
- Two useful transaction codes to search the T-TCODE where is in SAP menu tree
- Custom tool error: Failed to generate code for the service reference ××××××. Please check other erro
- Response.Redirect出现Unable to evaluate expression because the code is optimized or a native frame……异常解决方法
- Custom tool error: Failed to generate code for the service reference ××××××. Please check other erro
- 【随】Unable to evaluate expression because the code is optimized or a native frame is on top of the call stack 问题解决。
- Inside ARC — to see the code inserted by the compiler
- Inside ARC — to see the code inserted by the compiler
- How to disable compiler optimization for a piece of code
- Unable to evaluate expression because the code is optimized or a native frame is on top of the call stack.
- use code to generate Silverlight Controls at run time, and serialize the control into XAML file
- Inside ARC — to see the code inserted by the compiler
- Code Optimization Using the GNU C Compiler
- BUG: Unable to evaluate expression because the code is optimized or a native frame is on top of the call stack.
- WCF 服务引用生成代码失败 (Failed to generate code for the service reference )
- Custom tool error: Failed to generate code for the service reference ××××××. Please check other error and warning messages for details.
- Use Rome to generate the RSS
- 面试题: generate an equation, by inserting operator add ("+") and minus ("-") among the array to make equationExpression == 0
- The Road to Performance Is Littered with Dirty Code Bombs