Introducing the parameters for FDO allows FDO specific tunings. In general, these parameters are kludges lacking a better way of doing it. In the long run, we are working on smarter mechanism to make decisions based on hot program traces and locality regions as well as information such as uArch differences -- however this mechanism is not yet in place.
Thanks, David On Thu, Apr 28, 2011 at 8:08 AM, Richard Guenther <richard.guent...@gmail.com> wrote: > On Thu, Apr 28, 2011 at 4:47 PM, Diego Novillo <dnovi...@google.com> wrote: >> On Wed, Apr 27, 2011 at 22:09, Sharad Singhai <sing...@google.com> wrote: >>> Hi Diego, >>> >>> Thanks for the quick feedback. Here is a an updated version of the patch. >>> >>> 2011-04-27 Sharad Singhai <sing...@google.com> >>> >>> ChangeLog.google-main >>> * params.def: Add new parameters to control peeling. >>> * tree-ssa-loop-ivcanon.c (try_unroll_loop_completely): Use >>> different peeling parameters when profile feedback is available. >>> * loop-unroll.c (decide_peel_once_rolling): Ditto. >>> (decide_peel_completely): Ditto. >>> * doc/invoke.texi: Document new peeling parameters. >>> >>> testsuite/ChangeLog.google-main >>> * gcc.dg/vect/O3-vect-pr34223.c: Add new peeling >>> parameters. >>> * gcc.dg/vect/vect.exp: Allow reading flags in individual >>> tests. >> >> OK for google/main. >> >> Will you be submitting this patch for trunk as well? If you get it >> approved for trunk then you will not need to maintain it in >> google/main :) > > The doc change looks weird, you should have separate entries and > not combine them. Checking just for profile_info != NULL is bogus, > please instead check profile_status == PROFILE_READ. > > Did you do any measurements to decide on the param defaults? > Parameter defaults should be documented. Did you consider > adding a single parameter that scales the existing parameters for > hot loops with profile-feedback? > > Richard. > >> Diego. >> >
