Re: Set inline-unit-growth to 40

[Qing Zhao <qing.zhao@oracle.com>]

Okay, I see.
thanks.

Qing
> On Jan 15, 2019, at 9:14 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
> 
>> Hi, Honza,
>> 
>> in addition to the code size problems, there are several runtime regression for the SPEC: (If I read the table correctly, if not, let me know)
>> 
>> SPEC/SPEC2006/INT/483.xalancbmk <https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=183.290.0>	146.131	4.89%
> 
> This test seems to be just a noise, if you look on the mainline plots
> there is no noticeable regression and you can see differences +- 4% in
> last 10 runs.
>> 
>> SPEC/SPEC2006/FP/436.cactusADM <https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=171.100.0>	130.967	8.07%	
>> 
>> SPEC/SPEC2017/INT/520.omnetpp_r <https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=172.357.0>	395.582	4.98%	
> 
> Here you can see in the graph both boxes to be yellow which means that
> binary did not changed nor the size changed. It is just measurement error it seems.
>> 
>> SPEC/SPEC2006/FP/435.gromacs <https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=177.90.0>	182.555	11.73%	
> 
> I plan to check on gromacs
> This is LTO+PGO which will be rerun only in day or two so I will see if
> the same regression stays on mainline.
>> 
>> SPEC/SPEC2017/INT/541.leela_r <https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=174.397.0>	452.333	4.17%	
> 
> This was already taken by daily testers and regression does not
> reproduce, so it seems to be noise too.
> 
> Honza
>> 
>> do we have plan to study and fix these run-time regression?
> 
>> 
>> thanks.
>> 
>> Qing
>> 
>>> On Jan 12, 2019, at 12:32 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>>> 
>>> Hello,
>>> this patch sets inline-unit-growth to 40.  The performance changes are
>>> - Firefox, LTO
>>> https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=f7bd026e1a931b9a284d1c85c2577a72dd592820&newProject=try&newRevision=74889968abcc688b8d161863566ed273c0401ee4&framework=1&filter=opt&showOnlyComparable=1&showOnlyImportant=1
>>> After fixes to inlining priorities this makes difference without
>>> profile feedback only.
>>> 
>>> Code size growth is about 9.15% with LTO and 3.95 with LTO and profile
>>> feedback.
>>> - Firefox noLTO
>>> https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=c902b72340a3dca3114f58578c1c8f3e6a1cd89c&newProject=try&newRevision=4974da6f92c144a9c09765b56a564a640069ddb9&framework=1&showOnlyComparable=1&showOnlyImportant=1
>>> With about 7% code size growth
>>> - SPEC
>>> https://lnt.opensuse.org/db_default/v4/CPP/latest_runs_report?num_runs=10&min_percentage_change=0.02&revisions=46e2bd1143b5c60af814916d7673879b34ceb3f6%2Cc0d79cfe9c4ec30823480f2f9b256600e8e3899f
>>> - C++ benchmarks
>>> https://lnt.opensuse.org/db_default/v4/SPEC/latest_runs_report?num_runs=10&all_changes=on&min_percentage_change=0.02&revisions=46e2bd1143b5c60af814916d7673879b34ceb3f6%2Cc0d79cfe9c4ec30823480f2f9b256600e8e3899f
>>> 
>>> I am not entirely happy about the code-size/performance tradeoffs but it
>>> is concerned only for programs built with -O3 or having too many inline
>>> keywords.  I have looked into inlining decisions for Firefox, HHVM and
>>> Clang and inliner gets out of growt bounds way too early and some of
>>> more performance aware projects already sets the limit up.
>>> 
>>> I will tune other metrics down to handle some of the code size problems.
>>> 
>>> Honza
>>> 
>>> Index: ChangeLog
>>> ===================================================================
>>> --- ChangeLog	(revision 267882)
>>> +++ ChangeLog	(working copy)
>>> @@ -1,3 +1,7 @@
>>> +2019-01-05  Jan Hubicka  <hubicka@ucw.cz>
>>> +
>>> +	* params.def (inline-unit-growth): Set to 40.
>>> +
>>> 2019-01-12  Jakub Jelinek  <jakub@redhat.com>
>>> 
>>> 	* tree-ssa-loop-ivopts.c (find_inv_vars): Fix a comment typo.
>>> Index: params.def
>>> ===================================================================
>>> --- params.def	(revision 267882)
>>> +++ params.def	(working copy)
>>> @@ -227,7 +227,7 @@ DEFPARAM(PARAM_LARGE_UNIT_INSNS,
>>> DEFPARAM(PARAM_INLINE_UNIT_GROWTH,
>>> 	 "inline-unit-growth",
>>> 	 "How much can given compilation unit grow because of the inlining (in percent).",
>>> -	 20, 0, 0)
>>> +	 40, 0, 0)
>>> DEFPARAM(PARAM_IPCP_UNIT_GROWTH,
>>> 	 "ipcp-unit-growth",
>>> 	 "How much can given compilation unit grow because of the interprocedural constant propagation (in percent).",
>>