> On Mon, 2020-01-06 at 01:03 -0600, Xiong Hu Luo wrote:
> > Inline should return failure either (newsize > param_large_function_insns)
> > OR (newsize > limit). Sometimes newsize is larger than
> > param_large_function_insns, but smaller than limit, inline doesn't return
> > failure even if the new function is a large function.
> > Therefore, param_large_function_insns and param_large_function_growth
> > should be
> > OR instead of AND, otherwise --param large-function-growth won't
> > work correctly with --param large-function-insns.
> >
> > gcc/ChangeLog:
> >
> > 2020-01-06 Luo Xiong Hu <luo...@linux.ibm.com>
> >
> > ipa-inline-analysis.c (estimate_growth): Fix typo.
> > ipa-inline.c (caller_growth_limits): Use OR instead of AND.
> OK
This patch also seems wrong. Inliner should return failure when
newsize > param_large_function_insns && newsize > limit
The reason is same as with large_unit_insns. We used to have only
growth limits but it has turned out that this gets too
restrictive/random for very small units/growths.
So the logic is meant to be that inlining is OK either
- if function is reasonably small (large_function_insns limit is not
met)
- or it does not grow too much (large-function-growth isnot met)
@item large-function-insns
The limit specifying really large functions. For functions larger than
this limit after inlining, inlining is constrained by @option{--param
large-function-growth}. This parameter is useful primarily to avoid
extreme compilation time caused by non-linear algorithms used by the
back end.
Honza
> jeff
>
