On Wed, 1 Apr 2020, Jan Hubicka wrote:
> > 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.
OK, I'll update the patch accordingly.
Richard.
