[Bug middle-end/55500] New: [devirt] trunk fails inline-devirt test #7

[Bug middle-end/55500] New: [devirt] trunk fails inline-devirt test #7

[matt at use dot net]

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

             Bug #: 55500
           Summary: [devirt] trunk fails inline-devirt test #7
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: matt@use.net


Created attachment 28802
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28802
test case that fails in trunk but passed with Maxim's devirt patches. added a
loop to induce 'hotness' of the path versus the original test case.

inline-devirt-7.C, which passed using Maxim's patches from 11/2011, do not pass
on current trunk. Current trunk is missing the ipa-iterations patch, which may
be  required for this test case to pass. This test embodies a simple factory
pattern and interface segregation, two C++ best practices. (The weird loop in
main() is to induce "hot" inlining as mentioned in previous bugs.)

00000000004006d0 <main>:
  4006d0:       55                      push   rbp
  4006d1:       bd 03 00 00 00          mov    ebp,0x3
  4006d6:       53                      push   rbx
  4006d7:       48 83 ec 08             sub    rsp,0x8
  4006db:       bf 10 00 00 00          mov    edi,0x10
  4006e0:       e8 db ff ff ff          call   4006c0 <_Znwm@plt>
  4006e5:       48 c7 00 50 0c 40 00    mov    QWORD PTR [rax],0x400c50
  4006ec:       48 c7 40 08 88 0c 40    mov    QWORD PTR [rax+0x8],0x400c88
  4006f3:       00 
  4006f4:       48 89 c7                mov    rdi,rax
  4006f7:       48 89 c3                mov    rbx,rax
  4006fa:       e8 61 02 00 00          call   400960 <_ZN11LinuxSocket4openEv>

[Bug middle-end/55500] [devirt] trunk fails inline-devirt test #7

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-12-17
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |mkuvyrkov at ispras dot ru,
                   |                            |rguenther at suse dot de
     Ever confirmed|0                           |1

--- Comment #1 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
The testcase still has three OBJ_TYPE_REF.

  # ivtmp_25 = PHI <ivtmp_24(3), 3(2)>
  _18 = operator new (16);
  MEM[(struct LinuxSocket *)_18].D.2889.D.2853._vptr.Stream = &MEM[(void
*)&_ZTV11LinuxSocket + 16B];
  MEM[(struct LinuxSocket *)_18].D.2889.D.2854._vptr.Connection = &MEM[(void
*)&_ZTV11LinuxSocket + 72B];
  LinuxSocket::open (_18);
  goto <bb 6>;

  <bb 5>:
  __builtin_puts (&"got it"[0]);

  <bb 6>:
  _19 = MEM[(struct Stream *)_18]._vptr.Stream;
  _20 = *_19;
  _21 = OBJ_TYPE_REF(_20;(struct Stream)_18->0) (_18);


here LinuxSocket::open calls __builtin_puts and thus it is not pure and
therefore
basic folding can not propagate the known valud of  vptr pointers.

We sort of agreed to not mark "NEW" as maloc by default, so I understand that
AA can not easily determine that puts is not touching _18.

Maxim, how this testcase passed with your patches?

Perhaps type based analysis can work out the type and can use the assumption
that in-place-new that would be required to change the type is not allowed to
change type of non-pod, but this kind of anlaysis is not in yet
(I have patch that would make this happen with ctor not being inlined)

[Bug middle-end/55500] [devirt] trunk fails inline-devirt test #7

[matt at use dot net]

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

Matt Hargett <matt at use dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|4.8.0                       |4.9.0

--- Comment #2 from Matt Hargett <matt at use dot net> ---
still fails with current trunk. 

this factory pattern is one of the very common C++ abstraction patterns we got
to devirtualize with Maxim's work in 2010. all our previous tests were building
up to this real issue in the high-performance networking products I was working
on at the time. I'd be surprised if real-world products see a notable speed-up
if this tests {7,8,9} don't pass.

[Bug middle-end/55500] [devirt] trunk fails inline-devirt test #7

[herron.philip at googlemail dot com]

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

Philip Herron <herron.philip at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |herron.philip at googlemail dot co
                   |                            |m

--- Comment #3 from Philip Herron <herron.philip at googlemail dot com> ---
I just tried this test case with:

g++ -O2 -std=c++0x -fdump-tree-optimized test.cc -o test

g++ (GCC) 4.9.0 20131127 (experimental)

And it ran.

[Bug middle-end/55500] [devirt] trunk fails inline-devirt test #7

[matt at use dot net]

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

--- Comment #4 from Matt Hargett <matt at use dot net> ---
Phillip, the problem is not that the program doesn't run properly. It's that
the code isn't inline via de-virtualization when it could be. The main() should
contain a few printf/puts calls and nothing more.