'const' and compiler optimization
in [C++]
|
Prev: Use c++ to draw a figure of a graph(data structure)
Next: Non-static singleton setup to control life time
From: shahav on 12 Dec 2009 22:31 In the past, i do remember that 'const' was a matter of documentation that the compiler forces to follow. But now i think things have being changed, e.g. in std::set the key is 'const' for correctness, nevertheless there is a const_cast that the programmer can use... So the question is: does the compiler take advantage of const-ness during optimization? e.g. void foo(const int &end) { for( int i=0; i<(1<<end); i++)// i do expect the shift operation to be moved out of the loop std::cout<<i<<std::endl; for( int i=0; i<(1<<end); i++)// i do expect the shift operation to stay in the loop. foo1(i); } Rabin. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Joe Smith on 13 Dec 2009 08:15 "shahav" <shahav(a)gmail.com> wrote in message news:59154768-93a2-46d0-ba23-4aaa250b5843(a)9g2000yqa.googlegroups.com... > In the past, i do remember that 'const' was a matter of documentation > that the compiler forces to follow. > But now i think things have being changed, e.g. in std::set the key is > 'const' for correctness, nevertheless there is a const_cast that the > programmer can use... > > So the question is: does the compiler take advantage of const-ness > during optimization? Short answer: no but that really does not make any difference. Long answer: Thanks to the existance of const_cast, the compiler has some limitations. Most compilers on most platforms will place any static const objects in a read only section of the resulting executable, which the OS will subsequently map to a read only memory page. Otherwise, most compilers will not directly take advantage of const in optimizations, even though a few other circumstances permit it to do so. However, one of the stages of the optimization process is to convert the program to some form of static single assignment (SSA) form. In that language, all variables are const. Variables that change are treated as multiple variables. If a variable in the original program was actully const (regardless of how it was declared), then only one correspnding variable will exist in SSA form. So when optimations are applied to SSA form, nearly every optimization the compiler could have performed based on the const keyword will be get performed at this point. Thus, nothing was relly lost by the compiler by not using the const keyword for optimization. This was covered by the FAQ but the FAQ did not go into the same level of detail as to what the compiler is doing under the hood. I hope this provides some more insight into what the compiler is really doing. For what it is worth, this is largely why the LLVM project is considered rather exciting. LLVM bytecode is a form of SSA. So compilers stop upon producing SSA (or perhaps after doing some optimazation on it) and then outputs LLVM bytecode. The LLVM linker takes the LLVM bytecode of translation units, and can perform whole program optization on it. SSA is still high level enough that many optimzation opportunities are still present, that would no longer be possible if the linker were given assembly. The LLVM linker also performs lower level optimzations that a compiler would normally do after the SSA stage, and before generating an object file. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Martin B. on 13 Dec 2009 08:19 shahav wrote: > In the past, i do remember that 'const' was a matter of documentation > that the compiler forces to follow. > But now i think things have being changed, e.g. in std::set the key is > 'const' for correctness, nevertheless there is a const_cast that the > programmer can use... > > So the question is: does the compiler take advantage of const-ness > during optimization? > > e.g. > > void foo(const int &end) { > for( int i=0; i<(1<<end); i++)// i do expect the shift operation to > be moved out of the loop I don't think the compiler can optimize this. A const reference is just a promise that the referenced thing cannot be modified through this reference. It still can change underneath. E.g.: int glob; void foo(const int &end) { for( int i=0; i<(1<<end); i++) { if(i==2) ++glob; std::cout<<i<<std::endl; } } void main() { foo(glob); } br, Martin -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 13 Dec 2009 08:19
shahav wrote: > In the past, i do remember that 'const' was a matter of documentation > that the compiler forces to follow. > But now i think things have being changed, e.g. in std::set the key is > 'const' for correctness, nevertheless there is a const_cast that the > programmer can use... > > So the question is: does the compiler take advantage of const-ness > during optimization? The compiler cannot take advantage of const that is not at the top level (i.e. not applied directly to a variable). The reasons are: 1. const can be legally cast away 2. there can be another, non-const, mutating alias to the same memory location, even in the same thread 3. another thread may modify the data through a non-const alias 4. a const type may have 'mutable' members that the compiler doesn't know about due to hidden implementations. =========================================== Walter Bright Digital Mars http://www.digitalmars.com Free C, C++, Javascript, D programming language compilers -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |