[Bug c/47255] Missed optimization with loops, inline functions, and __attribute__((const))

[in-gnu at baka dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47255

--- Comment #2 from Seth Robertson <in-gnu at baka dot org> 2011-01-11 18:40:36 UTC ---
Created attachment 22946
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22946
Revised test program exhibiting missed optimization

Well, my point is that even if I remove the obvious side-effect, gcc cannot
take advantage of the knowledge I am providing it.  If instead of a printf() I
make a system call which will return a (what I know/guarantee is, but is not
declared as, a) ((const)) value (like getgid(), getuid(), or geteuid()) and use
it in the expression, it is likewise not optimized.  I'm attaching a second
test program using these system calls.  Test with `strace ./x 2>&1 | grep get |
wc -l`.  When you compile w/`gcc -O2` you should get the number 12.  When you
compile w/`gcc -O3` or with "-finline-functions -finline-small-functions", you
get 21 (ie. it did more work than necessary).  Of course without any
optimization you get the maximum of 30.

I am perfectly willing to believe that inlining happens first and throws away
the information such that it will miss the opportunity to CSE.  I also believe
that if gcc could intuit that it was const (e.g. pure multiplication
operations) that it wouldn't duplicate the work. I'm just saying this is a
missed optimization.

There could be a dup bug somewhere, but none of the tickets with "pure" or
"const" and "__attributes__" subjects discuss it.  Nor "inline' and 'cse'.