[Bug ipa/108802] [11/12/13/14 Regression] missed inlining of call via pointer to member function

2024-03-19 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802

--- Comment #9 from GCC Commits  ---
The master branch has been updated by Martin Jambor :

https://gcc.gnu.org/g:bf838884fac573b4902a21bb82d9b6f777e32cb9

commit r14-9559-gbf838884fac573b4902a21bb82d9b6f777e32cb9
Author: Martin Jambor 
Date:   Tue Mar 19 22:33:27 2024 +0100

ipa: Fix C++ member ptr indirect inlining (PR 114254, PR 108802)

Even though we have had code to handle creation of indirect call graph
edges (so that these calls can than be made direct as part of IPA-CP
and inlining and eventually also inlined) for C++ member pointers for
many years, it turns out that it does not work for lambdas and that it
has been severely broken since GCC 10 when the base class has virtual
functions.

Lambdas don't work because the code cannot work with structures
representing member function pointers because they are passed by
reference instead by value and the code was not ready for that.

The presence of virtual methods broke thinks because at some point C++
FE got clever and stopped emitting the check for virtual methods when
the base class does not have any and that in turn made our existing
testcases not test the necessary pattern matching code.  The pattern
matcher had a small bug which did not matter before
r10-917-g3b47da42de621c but did afterwards.

This patch changes the pattern matcher to match both of these cases.

gcc/ChangeLog:

2024-03-06  Martin Jambor  

PR ipa/108802
PR ipa/114254
* ipa-prop.cc (ipa_get_stmt_member_ptr_load_param): Fix case
looking
at COMPONENT_REFs directly from a PARM_DECL, also recognize loads
from
a pointer parameter.
(ipa_analyze_indirect_call_uses): Also recognize loads from a
pointer
parameter, also recognize the case when pfn pointer is loaded in
its
own BB.

gcc/testsuite/ChangeLog:

2024-03-06  Martin Jambor  

PR ipa/108802
PR ipa/114254
* g++.dg/ipa/iinline-4.C: New test.
* g++.dg/ipa/pr108802.C: Likewise.

[Bug ipa/108802] [11/12/13/14 Regression] missed inlining of call via pointer to member function

2024-03-08 Thread jamborm at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802

--- Comment #8 from Martin Jambor  ---
I have proposed an improved patch on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6r0gkzvi4@virgil.suse.cz/T/#u

[Bug ipa/108802] [11/12/13/14 Regression] missed inlining of call via pointer to member function

2024-02-21 Thread jamborm at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802

--- Comment #7 from Martin Jambor  ---
I have proposed a patch on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6y1bdx3yg@virgil.suse.cz/T/#u

[Bug ipa/108802] [11/12/13/14 Regression] missed inlining of call via pointer to member function

2024-02-19 Thread jamborm at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802

Martin Jambor  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #6 from Martin Jambor  ---
I think I know what to do.

[Bug ipa/108802] [11/12/13/14 Regression] missed inlining of call via pointer to member function

2024-02-16 Thread hubicka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802

--- Comment #5 from Jan Hubicka  ---
I don't think we can reasonably expect every caller of lambda function to be
early inlined, so we need to extend ipa-prop to understand the obfuscated code.
 I disucussed that with Martin some time ago - I think this is quite common
problem with modern C++, so we will need to pattern match this, which is quite
unfortunate.

[Bug ipa/108802] [11/12/13/14 Regression] missed inlining of call via pointer to member function

2023-07-07 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|10.5|11.5

--- Comment #4 from Richard Biener  ---
GCC 10 branch is being closed.