[Bug c++/12219] New: inline doesn't always cause inlining, even when it's possible

[Bug c++/12219] New: inline doesn't always cause inlining, even when it's possible

[dbaron at dbaron 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=12219

           Summary: inline doesn't always cause inlining, even when it's
                    possible
           Product: gcc
           Version: unknown
            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

There are cases where inline doesn't cause inlining, but
__attribute__((always_inline)) causes inlining and improves the performance of
the code.  Having to resort to __attribute__((always_inline)) is rather ugly,
especially in code that also has to compile on other compilers.

This is filed as suggested in bug 11680 comment 4.

A testcase is attachment 4487 (from bug 11680).

Steps to reproduce:
 1. Compile attachment 4487 using -O2.
 2. time "<executable> original" and "<executable> slow".
 3. Modify the attachment to comment out the __attribute__((always_inline))
(and, if you want, add |inline|, although C++ says it's implied for methods
defined inside of class defitions, and it doesn't make a difference) in the
class ConvertUTF16toUTF8_slow
 4. recompile

Expected results:
 2. The two take the same amount of time.
 4. There is no change in the size of the binary.

Actual results:
 2. "slow" is faster than "original".
 4. the binary is bigger without the __attribute__((always_inline))

[Bug c++/12219] inline doesn't always cause inlining, even when it's possible

[dbaron at dbaron 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=12219



------- Additional Comments From dbaron at dbaron dot org  2003-09-08 23:02 -------
(I'm seeing this both with gcc 3.3.1 and with the trunk as of 20030908.)

[Bug c++/12219] inline doesn't always cause inlining, even when it's possible

[zack 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=12219



------- Additional Comments From zack at gcc dot gnu dot org  2003-09-09 00:05 -------
Please post results for -O2 -fno-unit-at-a-time and -O2 -funit-at-a-time.  I am
not sure what the current default is for that switch, but this is the sort of
thing that unit-at-a-time mode was intended to address.

[Bug c++/12219] inline doesn't always cause inlining, even when it's possible

[dbaron at dbaron 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=12219


dbaron at dbaron dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WORKSFORME


------- Additional Comments From dbaron at dbaron dot org  2003-09-09 01:36 -------
I thought I saw this earlier today using the trunk, but I must have been using
3.3.  I don't see the bug using the trunk anymore, which is consistent with bug
11680 comment 2.