* Possible missed optimization opportunity with const? [not found] <1637972460.15325965.1471393300211.JavaMail.yahoo.ref@mail.yahoo.com> @ 2016-08-17 0:25 ` Toshi Morita 2016-08-17 14:15 ` David Brown 2016-08-17 14:27 ` lhmouse 0 siblings, 2 replies; 4+ messages in thread From: Toshi Morita @ 2016-08-17 0:25 UTC (permalink / raw) To: gcc 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Possible missed optimization opportunity with const? 2016-08-17 0:25 ` Possible missed optimization opportunity with const? Toshi Morita @ 2016-08-17 14:15 ` David Brown [not found] ` <1646493700.16522102.1471473899633.JavaMail.yahoo@mail.yahoo.com> 2016-08-17 14:27 ` lhmouse 1 sibling, 1 reply; 4+ messages in thread From: David Brown @ 2016-08-17 14:15 UTC (permalink / raw) To: Toshi Morita, gcc 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <1646493700.16522102.1471473899633.JavaMail.yahoo@mail.yahoo.com>]
* Re: Possible missed optimization opportunity with const? [not found] ` <1646493700.16522102.1471473899633.JavaMail.yahoo@mail.yahoo.com> @ 2016-08-18 13:04 ` David Brown 0 siblings, 0 replies; 4+ messages in thread From: David Brown @ 2016-08-18 13:04 UTC (permalink / raw) To: Toshi Morita, gcc 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(). ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Possible missed optimization opportunity with const? 2016-08-17 0:25 ` Possible missed optimization opportunity with const? Toshi Morita 2016-08-17 14:15 ` David Brown @ 2016-08-17 14:27 ` lhmouse 1 sibling, 0 replies; 4+ messages in thread From: lhmouse @ 2016-08-17 14:27 UTC (permalink / raw) To: Toshi Morita, gcc 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-08-18 13:04 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1637972460.15325965.1471393300211.JavaMail.yahoo.ref@mail.yahoo.com> 2016-08-17 0:25 ` Possible missed optimization opportunity with const? Toshi Morita 2016-08-17 14:15 ` David Brown [not found] ` <1646493700.16522102.1471473899633.JavaMail.yahoo@mail.yahoo.com> 2016-08-18 13:04 ` David Brown 2016-08-17 14:27 ` lhmouse
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).