[Bug c++/11680] New: member access of C++ class with all methods inline should be optimized better

["dbaron at dbaron dot org" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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

           Summary: member access of C++ class with all methods inline
                    should be optimized better
           Product: gcc
           Version: 3.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dbaron at dbaron dot org
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu

This is a reduced testcase of the problem described in
http://bugzilla.mozilla.org/show_bug.cgi?id=206682#c25 , being filed as
mentioned in bug 11376 comment 6 and bug 11376 comment 37.  The bug is that gcc
didn't optimize the code in question as well as I think in should.  (Optimizing
code written in a "generic programming" style is needed to encourage people to
write such code...)  In particular, I was working on a class that did UTF-16 to
UTF-8 conversion (and could be used as one of many character sinks with
Mozilla's string classes).

In particular, the code involved a large inline method that involved repeated
use of a member variable (being used as a cursor into the output buffer being
written).  (By default, gcc didn't inline the method.  This was hand-optimized
by using |__attribute__((always_inline))|.  Should I file a separate bug on
this, or is it unlikely to be fixed?)  Once the method was inlined, gcc did not
optimize the use of the member variable as well as it could have.  This was
hand-optimized by assigning from the member variable at the beginning of the
|write| function and assigning back to it at the end.  Since all the methods of
the class are inlined and the compiler can tell that a pointer to the member
variable |mBuffer| is never taken, gcc should have been able to produce code
that was just as fast with or without this second hand-optimization.

This can be tested by comparing the performance of the attached testcase with
the arguments "slow" (forced inline, but without the local variable
hand-optimization) and "fast" (with the local variable hand-optimization).  I
claim that gcc should be producing essentially identical code for these two
cases, so they should perform equivalently.  This is not the case:

> /usr/local/gcc-trunk/bin/g++ -O2 perf.cpp

> time ./a.out fast
1.270u 0.010s 0:01.24 103.2%    0+0k 0+0io 224pf+0w
> time ./a.out fast
1.270u 0.000s 0:01.25 101.6%    0+0k 0+0io 224pf+0w
> time ./a.out fast
1.300u 0.010s 0:01.27 103.1%    0+0k 0+0io 224pf+0w

> time ./a.out slow
4.030u 0.010s 0:04.03 100.2%    0+0k 0+0io 224pf+0w
> time ./a.out slow
4.030u 0.000s 0:04.11 98.0%     0+0k 0+0io 224pf+0w
> time ./a.out slow
4.060u 0.000s 0:04.10 99.0%     0+0k 0+0io 224pf+0w

These measurements were made with the gcc trunk as of today.  The numbers for
the gcc 3.3 release are similar (although gcc 3.3 was slightly slower for the
"fast" version and slightly faster for the "slow" version).