The document discusses compiler optimization and how it relates to unreachable code. It provides examples of code using constants, globals, and enums to illustrate how and when compilers will optimize away unreachable function calls. The key points are:
1) Code using a constant integer in an "if" condition that always evaluates to false may or may not be optimized away, depending on the compiler and optimization level.
2) Using "const volatile" prevents optimization, while a plain global variable generally does not allow optimization, as the compiler cannot assume the variable's value.
3) Higher optimization levels and inter-procedural optimization across translation units can further reduce unreachable code. The linker may invoke the compiler again during
The document discusses compiler optimization and how it relates to unreachable code. It provides examples of code using constants, globals, and enums to illustrate how and when compilers will optimize away unreachable function calls. The key points are:
1) Code using a constant integer in an "if" condition that always evaluates to false may or may not be optimized away, depending on the compiler and optimization level.
2) Using "const volatile" prevents optimization, while a plain global variable generally does not allow optimization, as the compiler cannot assume the variable's value.
3) Higher optimization levels and inter-procedural optimization across translation units can further reduce unreachable code. The linker may invoke the compiler again during
The document discusses compiler optimization and how it relates to unreachable code. It provides examples of code using constants, globals, and enums to illustrate how and when compilers will optimize away unreachable function calls. The key points are:
1) Code using a constant integer in an "if" condition that always evaluates to false may or may not be optimized away, depending on the compiler and optimization level.
2) Using "const volatile" prevents optimization, while a plain global variable generally does not allow optimization, as the compiler cannot assume the variable's value.
3) Higher optimization levels and inter-procedural optimization across translation units can further reduce unreachable code. The linker may invoke the compiler again during
The document discusses compiler optimization and how it relates to unreachable code. It provides examples of code using constants, globals, and enums to illustrate how and when compilers will optimize away unreachable function calls. The key points are:
1) Code using a constant integer in an "if" condition that always evaluates to false may or may not be optimized away, depending on the compiler and optimization level.
2) Using "const volatile" prevents optimization, while a plain global variable generally does not allow optimization, as the compiler cannot assume the variable's value.
3) Higher optimization levels and inter-procedural optimization across translation units can further reduce unreachable code. The linker may invoke the compiler again during
Copyright:
Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online from Scribd
Download as pdf or txt
You are on page 1/ 1
The Joy of
Programming The Basics of Compiler Optimisers S.G. GANESH It is fun to write programs that do not work and see how they fail (or work, by chance!). In this column, we use this idea to understand the basics of the optimiser part of a compiler.
recently read an interesting article [C++ Report, of a const variable also—enum { val = 0 }. Why? Because
I Vol. 6, no. 3, ‘How to write buggy programs’ by enums are just constant values and are only for integral Andrew Koenig], which is about writing incorrect values. programs. I’ve taken the following (slightly How about this statement: const volatile int val = 0;? modified) piece of code from that article to Yes, first, it is valid to qualify a variable with both const and illustrate how compiler optimisers work: volatile: the volatile keyword tells the compiler optimiser not to optimise the code involving that variable and the extern void foo(); const keyword says that the programmer cannot int main() { programmatically change the value of the variable. So, a if(0) foo(); compiler will not optimise the code and the linker will give } an unsat for this program. What if the variable is a plain global variable (int val;)? The foo function is just declared and is not defined in the The program will almost always result in an unsat for foo. program. The if condition always evaluates to ‘false’. Should Why? Note that the global variables can be modified by any this program link fine or result in a linker error complaining function in the program, which might be available from some that the definition of foo is not found? That will depend on other translation unit (independent program file) also. the compiler. Some smart compilers see that the statement Though it is clear from the control flow of the program that for if(0) will never get executed, and will therefore not the value of val cannot be changed before the if condition is generate a call to foo at all—so the linker won’t complain. executed, in general, the optimiser cannot assume anything However, not all compilers do such smart work in default about the value of val. compilation mode and hence we might get a linker error. Global variables put compiler optimisers into much (Such compilers might detect the ‘unreachable function call’ trouble. Globals will require the optimisers to do extensive at higher levels of optimisation!) The following is what I got analysis across translation units, which usually takes too when I tried a compiler: much time. And compiler optimisers are not expected to take unreasonable amounts of compilation time to do $ cc foo.c runtime speedups; so, typically, optimisers do not perform ld: Undefined symbol foo; first referenced in file foo.o much optimisation on global variables. $ cc –O foo.c But optimisers do perform optimisation for functions $ across translation units, which is known as Inter-Procedural Optimisation (IPO). IPO can yield significant performance Try it and see how your compiler behaves. Sounds improvements for the program, and it is typically invoked at interesting, isn’t it? higher optimisation levels (usually, -O3 level and above). We Now, what if we modify the expression in the if all know that the compiler invokes the linker for linking condition, as shown: programs. But, since only the linker knows the details about all translation units (the .o files) when it attempts to create const int val = 0; the final shared library or executable, for IPO, the linker will int main() { invoke the compiler (optimiser) again and do the actual if(val) foo(); linking work later! }
By: S.G. Ganesh is a research engineer in Siemens
Yes, the compiler might detect the unreachable code at a (Corporate Technology). He has authored a book called higher optimisation level and can remove the call to foo. ‘Deep C’ (ISBN 81-7656-501-6). You can reach him at Even the compiler can optimise it fine for an enum instead sgganesh@gmail.com
122 DECEMBER 2007 | LINUX FOR YOU | www.linuxforu.com
