[Bug ipa/113291] [14/15 Regression] compilation never (?) finishes with recursive always_inline functions at -O and above since r14-2172
cvs-commit at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Mon Jul 22 16:08:51 GMT 2024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113291
--- Comment #11 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-14 branch has been updated by Jan Hubicka
<hubicka@gcc.gnu.org>:
https://gcc.gnu.org/g:9a7d668fc58f817027ec7f9fa7e20a6dce08bddb
commit r14-10486-g9a7d668fc58f817027ec7f9fa7e20a6dce08bddb
Author: Jan Hubicka <jh@suse.cz>
Date: Tue May 14 12:58:56 2024 +0200
Reduce recursive inlining of always_inline functions
this patch tames down inliner on (mutiply) self-recursive always_inline
functions.
While we already have caps on recursive inlning, the testcase combines
early inliner
and late inliner to get very wide recursive inlining tree. The basic idea
is to
ignore DISREGARD_INLINE_LIMITS when deciding on inlining self recursive
functions
(so we cut on function being large) and clear the flag once it is detected.
I did not include the testcase since it still produces a lot of code and
would
slow down testing. It also outputs many inlining failed messages that is
not
very nice, but it is hard to detect self recursin cycles in full generality
when indirect calls and other tricks may happen.
gcc/ChangeLog:
PR ipa/113291
* ipa-inline.cc (enum can_inline_edge_by_limits_flags): New enum.
(can_inline_edge_by_limits_p): Take flags instead of multiple
bools; add flag
for forcing inlinie limits.
(can_early_inline_edge_p): Update.
(want_inline_self_recursive_call_p): Update; use FORCE_LIMITS mode.
(check_callers): Update.
(update_caller_keys): Update.
(update_callee_keys): Update.
(recursive_inlining): Update.
(add_new_edges_to_heap): Update.
(speculation_useful_p): Update.
(inline_small_functions): Clear DECL_DISREGARD_INLINE_LIMITS on
self recursion.
(flatten_function): Update.
(inline_to_all_callers_1): Update.
(cherry picked from commit 1ec49897253e093e1ef6261eb104ac0c111bac83)
More information about the Gcc-bugs
mailing list