[Bug ipa/114703] Missed devirtualization in rather simple case

[hubicka at ucw dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114703

--- Comment #3 from Jan Hubicka  ---
> Yep, 'new' memory escapes.
Yep, this is blocking a lot of propagation in common C++ code.
Here it may help to do speculative devirtualization during IPA stage
that will let the late optimization to get rid of the speculation (since
after inlning we will know that the virtual call does not overwrite
virtual table pointer).  This is technically not too hard to add.  We
can optimistically rule out (some) may aliases while walking the alias
oracle.   I will take a look next stage1.

[Bug ipa/114703] Missed devirtualization in rather simple case

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114703

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
Yep, 'new' memory escapes.

[Bug ipa/114703] Missed devirtualization in rather simple case

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114703

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug ipa/114703] Missed devirtualization in rather simple case

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114703

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-04-12
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
The problem I think is we don't realize that `operator new` can't touch the
other memory that was just allocated partly because the escape analysis is not
flow sensitive .