On Thu, Jun 6, 2013 at 1:33 PM, Xinliang David Li <davi...@google.com> wrote: > ok. Wht is the rational for dropping the limit in trunk? Ideally, > the limit should be lifted up and to enable other heuristics to kick > in.
Here is the message about it from Honza: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01193.html Basically, it was to reduce code bloat, and it didn't show spec regressions. Teresa > > David > > On Thu, Jun 6, 2013 at 1:22 PM, Teresa Johnson <tejohn...@google.com> wrote: >> The default for the max instructions in peeled loops was reduced on >> trunk in r193570. This is causing a performance regression on an internal >> benchmark. This change will revert to the old higher limits. >> >> Google ref b/8839137. >> >> Bootstrapped and tested. Ok for google/4_8? >> >> Thanks, >> Teresa >> >> 2013-06-06 Teresa Johnson <tejohn...@google.com> >> >> * params.def (PARAM_MAX_PEELED_INSNS): Revert to 400. >> (PARAM_MAX_COMPLETELY_PEELED_INSNS): Ditto. >> >> Index: params.def >> =================================================================== >> --- params.def (revision 199753) >> +++ params.def (working copy) >> @@ -306,7 +306,7 @@ DEFPARAM(PARAM_MAX_UNROLL_TIMES, >> DEFPARAM(PARAM_MAX_PEELED_INSNS, >> "max-peeled-insns", >> "The maximum number of insns of a peeled loop", >> - 100, 0, 0) >> + 400, 0, 0) >> /* The maximum number of peelings of a single loop. */ >> DEFPARAM(PARAM_MAX_PEEL_TIMES, >> "max-peel-times", >> @@ -321,7 +321,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", >> - 100, 0, 0) >> + 400, 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", >> >> >> -- >> Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413 -- Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
