https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123459
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
So I have a different case but same reason, speculative devirt:
../../../../ompi/mca/part/persist/part_persist.h:484:1: error: inlining failed
in call to 'always_inline' 'mca_part_persist_start': --param
max-inline-insns-single limit reached
484 | mca_part_persist_start(size_t count, ompi_request_t** requests)
| ^~~~~~~~~~~~~~~~~~~~~~
../../../../ompi/mca/part/persist/part_persist.h:500:23: note: called from here
500 | err = req->persist_reqs[0]->req_start(req->real_parts,
req->persist_reqs);
|
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
and the reason we do not consider IPA inlining this is
/* Heuristics for inlining small functions work poorly for
recursive calls where we do effects similar to loop unrolling.
When inlining such edge seems profitable, leave decision on
specific inliner. */
if (edge->recursive_p ())
{
if (where->inlined_to)
where = where->inlined_to;
/* Disable always_inline on self recursive functions.
This prevents some inlining bombs such as one in PR113291
from exploding.
It is not enough to stop inlining in self recursive always_inlines
since they may grow large enough so always inlining them even
with recursin depth 0 is too much.
All sane uses of always_inline should be handled during
early optimizations. */
DECL_DISREGARD_INLINE_LIMITS (where->decl) = false;
which resets DECL_DISREGARD_INLINE_LIMITS on the decl, but we still diagnose
the failure to inline. I suppose we can simply check
DECL_DISREGARD_INLINE_LIMITS as well.
