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.
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
