From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12855 invoked by alias); 27 Jul 2003 05:13:55 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 12846 invoked by uid 48); 27 Jul 2003 05:13:52 -0000 Date: Sun, 27 Jul 2003 05:13:00 -0000 From: "dbaron at dbaron dot org" To: gcc-bugs@gcc.gnu.org Message-ID: <20030727051349.11680.dbaron@dbaron.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c++/11680] New: member access of C++ class with all methods inline should be optimized better X-Bugzilla-Reason: CC X-SW-Source: 2003-07/txt/msg03111.txt.bz2 List-Id: 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).