[Bug ipa/113291] [14 Regression] compilation never (?) finishes with recursive always_inline functions at -O and above since r14-2172

2024-04-18 Thread law at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113291

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P1  |P2
 CC||law at gcc dot gnu.org

[Bug ipa/113291] [14 Regression] compilation never (?) finishes with recursive always_inline functions at -O and above since r14-2172

2024-04-09 Thread hubicka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113291

--- Comment #8 from Jan Hubicka  ---
I am not sure this ought to be P1:
 - the compilation technically is finite, but not in reasonable time
 - it is possible to adjust the testcas (do early inlining manually) and get
same infinite build on release branches
 - if you ask for inline bomb, you get it.

But after some more testing, I do not see reasonably easy way to get better
diagnostics. So I will retest the patch fro #6 and go ahead with it.

[Bug ipa/113291] [14 Regression] compilation never (?) finishes with recursive always_inline functions at -O and above since r14-2172

2024-03-26 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113291

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
Honza is working on this.

[Bug ipa/113291] [14 Regression] compilation never (?) finishes with recursive always_inline functions at -O and above since r14-2172

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

--- Comment #6 from Jan Hubicka  ---
Created attachment 57427
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57427=edit
patch

The patch makes compilation to finish in reasonable time.
I ended up in need to dropping DISREGARD_INLINE_LIMITS in late inlining for
functions with self recursive always inlines, since these grow large quick and
even non-recursive inlining is too slow.  We also end up with quite ugly
diagnostics of form:

tt.c:13:1: error: inlining failed in call to ‘always_inline’ ‘f1’: --param
max-inline-insns-auto limit reached
   13 | f1 (void)
  | ^~
tt.c:17:3: note: called from here
   17 |   f1 ();
  |   ^
tt.c:6:1: error: inlining failed in call to ‘always_inline’ ‘f0’: --param
max-inline-insns-auto limit reached
6 | f0 (void)
  | ^~
tt.c:16:3: note: called from here
   16 |   f0 ();
  |   ^
tt.c:13:1: error: inlining failed in call to ‘always_inline’ ‘f1’: --param
max-inline-insns-auto limit reached
   13 | f1 (void)
  | ^~
tt.c:15:3: note: called from here
   15 |   f1 ();
  |   ^
In function ‘f1’,
inlined from ‘f0’ at tt.c:8:3,


which is quite large so I can not add it to a testuiste.  I will see if I can
reduce this even more.

[Bug ipa/113291] [14 Regression] compilation never (?) finishes with recursive always_inline functions at -O and above since r14-2172

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

--- Comment #5 from Jan Hubicka  ---
There is a cap in want_inline_self_recursive_call_p which gives up on inlining
after reaching max recursive inlining depth of 8. Problem is that the tree here
is too wide. After early inlining f0 contains 4 calls to f1 and 3 calls to f0.
Similarly for f0, so we have something like (9+3*9)^8 as a cap on number of
inlines that takes a while to converge.

One may want to limit number of copies of function A within function B rather
than depth, but that number can be large even for sane code.

I am making patch to make inliner to ignore always_inline on all self-recrusive
inline decisions.

[Bug ipa/113291] [14 Regression] compilation never (?) finishes with recursive always_inline functions at -O and above since r14-2172

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

--- Comment #4 from Jan Hubicka  ---
There is a cap in want_inline_self_recursive_call_p which gives up on inlining
after reaching max recursive inlining depth of 8. Problem is that the tree here
is too wide. After early inlining f0 contains 4 calls to f1 and

[Bug ipa/113291] [14 Regression] compilation never (?) finishes with recursive always_inline functions at -O and above since r14-2172

2024-01-11 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113291

--- Comment #3 from Richard Biener  ---
We're endlessly inlining during IPA.  Honza, please have a look.

[Bug ipa/113291] [14 Regression] compilation never (?) finishes with recursive always_inline functions at -O and above since r14-2172

2024-01-10 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113291

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
Summary|[14 Regression] compilation |[14 Regression] compilation
   |never (?) finishes with |never (?) finishes with
   |recursive always_inline |recursive always_inline
   |functions at -O and above   |functions at -O and above
   ||since r14-2172
   Priority|P3  |P1

--- Comment #2 from Jakub Jelinek  ---
Started with r14-2172-gd88fd2e1d0720e6f892da9ff48e9a301a7ad0ad4