'const' and compiler optimization

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! ]

"shahav" <shahav@gmail.com> wrote in message
news:59154768-93a2-46d0-ba23-4aaa250b5843@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! ]

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! ]

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! ]