On 1/7/20 9:40 AM, Jan Hubicka wrote:
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.
Hello.
The patch was already installed and caused quite significant changes in SPEC
benchmarks:
https://lnt.opensuse.org/db_default/v4/SPEC/latest_runs_report
May I revert the patch?
Thanks,
Martin
Honza
jeff
