Hi,
this patch reduces max-peeled-insns and max-completely-peeled-insns from 400 to
100. The reason why I am doing this is that I want to reduce code bloat caused
by my cunroll work that enabled a lot more unrolling then previously causing
considerable code size regression at -O3.
I do not think those params was ever serviously tunned, or re-tunned after
introduction of tree-ssa peeling. I bootstrapped/regtested x86_64 with few
values - 4000, 200, 100, 50 on spec2000,spec2k6,C++ benchmarks and polyhedron.
I also did partial tests on ia-64 (that is broken quite a lot now, but I wanted
to have some sanity check that these values are not too x86 specific).
With 4000 (and also bumped up max-peel-times/max-completely-peel-times) there
are improvements on
ammp 1360->1460
equake 1800->1840
applu 1450->1500
but i guess those needs to be handled by better heuristic.
Otherwise there are no perfromance regression with going 400->100. With 50
there are tiny performance drops on swim and applu.
I plan to follow by testing the max-peel times parameters and then doing inliner
tests.
Bootstrapped/regtested x86_64-linux, OK?
Honza
* params.def (max-peeled-insns, max-completely-peeled-insns): Reduce to
100.
Index: params.def
===================================================================
--- params.def (revision 193505)
+++ params.def (working copy)
@@ -290,7 +290,7 @@ DEFPARAM(PARAM_MAX_UNROLL_TIMES,
DEFPARAM(PARAM_MAX_PEELED_INSNS,
"max-peeled-insns",
"The maximum number of insns of a peeled loop",
- 400, 0, 0)
+ 100, 0, 0)
/* The maximum number of peelings of a single loop. */
DEFPARAM(PARAM_MAX_PEEL_TIMES,
"max-peel-times",
@@ -305,7 +305,7 @@ DEFPARAM(PARAM_MAX_PEEL_BRANCHES,
DEFPARAM(PARAM_MAX_COMPLETELY_PEELED_INSNS,
"max-completely-peeled-insns",
"The maximum number of insns of a completely peeled loop",
- 400, 0, 0)
+ 100, 0, 0)
/* The maximum number of peelings of a single loop that is peeled completely.
*/
DEFPARAM(PARAM_MAX_COMPLETELY_PEEL_TIMES,
"max-completely-peel-times",
