Possible missed optimization opportunity with const?

Possible missed optimization opportunity with const?

[Toshi Morita]

I was involved in a discussion over the semantics of "const" in C, and the following code was posted: 

#include <stdio.h>
int foo = 0;
const int *pfoo = &foo;
void bar (void)
{
    foo +=3D;
}
int main(void)
{
   int a, b;
   a = *pfoo;
     bar();
     b = *pfoo;
   printf("a: %d, b: %d\n", a, b);
}
 

This code when compiled with gcc 4.8.2 using the optimization option -O3 produces: 

a: 0, b: 1 


So it appears even though pfoo is a const int *, the value *pfoo is read twice. 

Would it be valid for the code to print a:0, b: 0?
If so, is this a missed optimization opportunity?

Toshi 

Re: Possible missed optimization opportunity with const?

[David Brown]

On 17/08/16 02:21, Toshi Morita wrote:
> I was involved in a discussion over the semantics of "const" in C, and the following code was posted:
>
> #include <stdio.h>
> int foo = 0;
> const int *pfoo = &foo;
> void bar (void)
> {
>      foo +=3D;

I assume that's a typo?

> }
> int main(void)
> {
>     int a, b;
>     a = *pfoo;
>       bar();
>       b = *pfoo;
>     printf("a: %d, b: %d\n", a, b);
> }
>
>
> This code when compiled with gcc 4.8.2 using the optimization option -O3 produces:
>
> a: 0, b: 1
>
>
> So it appears even though pfoo is a const int *, the value *pfoo is read twice.
>
> Would it be valid for the code to print a:0, b: 0?
> If so, is this a missed optimization opportunity?
>

No, it would not be valid.  Declaring pfoo as a "const int*" tells the 
compiler "I will not change anything via this pointer - and you can 
optimise based on that promise".  It does /not/ tell the compiler "the 
thing that this points to will not change".

So the compiler is correct in reading *pfoo twice.

Re: Possible missed optimization opportunity with const?

[lhmouse]

In your example the compiler is not given the guarantee that
the object 'foo' in question can only be modified through the pointer.

We can make such guarantee by adding the `restrict` qualifier
to the pointer, like this:

    const int *restrict pfoo = &foo;

With -O3 on GCC 6.1 the modified code produces:

    a: 1, b: 1

However as long as there is a restrict pointer pointing to an object,
modifying it _not_ through that pointer results in undefined behavior.

------------------				 
Best regards,
lh_mouse
2016-08-17

-------------------------------------------------------------
发件人：Toshi Morita <tm314159@yahoo.com>
发送日期：2016-08-17 08:21
收件人：gcc@gcc.gnu.org
抄送：
主题：Possible missed optimization opportunity with const?

I was involved in a discussion over the semantics of "const" in C, and the following code was posted: 

#include <stdio.h>
int foo = 0;
const int *pfoo = &foo;
void bar (void)
{
    foo +=3D;
}
int main(void)
{
   int a, b;
   a = *pfoo;
     bar();
     b = *pfoo;
   printf("a: %d, b: %d\n", a, b);
}
 

This code when compiled with gcc 4.8.2 using the optimization option -O3 produces: 

a: 0, b: 1 


So it appears even though pfoo is a const int *, the value *pfoo is read twice. 

Would it be valid for the code to print a:0, b: 0?
If so, is this a missed optimization opportunity?

Toshi 

Re: Possible missed optimization opportunity with const?

[David Brown]

On 18/08/16 00:44, Toshi Morita wrote:
> David Brown <david.brown@hesbynett.no> wrote:
> 
>> No, it would not be valid.  Declaring pfoo as a "const int*" tells the
>> compiler "I will not change anything via this pointer - and you can
>> optimise based on that promise".  It does /not/ tell the compiler "the
>> thing that this points to will not change".
>>
>> So the compiler is correct in reading *pfoo twice.
> 
> The revised example posted by Kei uses "const int const *pfoo" and GCC
> is able to remove the second read, so this interpretation of const seems
> incorrect?
> 
> Toshi
> 

I didn't see the post you are referring to - was it sent to the mailing
list, or only your email address?

But if I can make a guess here, the difference here is that now the
pointer object "pfoo" itself is const, and therefore cannot be modified
(without causing undefined behaviour).  So the compiler knows that it
will definitely point to "foo", and can use that information to optimise
better.

When "pfoo" was not "const", the compiler does not know that pfoo points
to foo in main - it could point somewhere else.  (In particular, a
file-scope constructor in another module might change it, since pfoo has
external linkage.)  Thus it does not know if bar() changes *pfoo, and it
has to read *pfoo twice.  You would get the same effect by making pfoo
"static", since the compiler then knows that it's value is &foo at the
start of main().