> 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.
We do want to preserve cross-module inlining between C and C++, so we
really should go with marking the loops pre-inline about finiteness and
try to preserve the info, otherwise we are going to lose quite some
optimizations.
Honza
>
> Richard.
