On Wed, 1 Apr 2020, Jakub Jelinek wrote:
> On Wed, Apr 01, 2020 at 03:36:30PM +0200, Richard Biener wrote:
> > @@ -512,7 +512,10 @@ can_inline_edge_by_limits_p (struct cgraph_edge *e,
> > bool report,
> > /* When devirtualization is disabled for callee, it is not safe
> > to inline it as we possibly mangled the type info.
> > Allow early inlining of always inlines. */
> > - || (!early && check_maybe_down (flag_devirtualize)))
> > + || (!early && check_maybe_down (flag_devirtualize))
> > + /* It's not safe to inline a function where loops maybe
> > + infinite into a function where we assume the reverse. */
> > + || check_maybe_down (flag_finite_loops))
> > {
> > e->inline_failed = CIF_OPTIMIZATION_MISMATCH;
> > inlinable = false;
>
> Couldn't the above care only if the function has any loops?
> Otherwise, won't it prevent cross-language LTO inlining too much?
> Or instead of disabling inlining arrange for a safe flag_finite_loops value
> for the resulting function (set some flag in cfun of the function that would
> be considered together with flag_finite_loops (so that we don't have to
> create further OPTIMIZATION_NODEs) and disable finite loops opts if we've
> inlined !flag_finite_loops function into flag_finite_loops one)?
I guess I can split out this hunk from the patch - it's a separate
issue affecting also C++ with mixed option CUs. Yes, ideally we'd
simply initialize loop->finite_p from flag_finite_loops at CFG
construction time and then only ever check the flag on the loop
structure. That would leave us with infinite loops for loops
we only discover later though. It also opens up the possibility
of a per-loop #pragma.
Richard.
