This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add working-set size and hotness information to fdo summary (issue6465057)


> +                {
> +                  cs_prg->num = cs_tprg->num;
> +                  /* Allocate the working set array for the merged summary.  */
> +                  if (ws_cnt)
> +                    {
> +                      cs_prg->working_set_count = ws_cnt;
> +                      cs_prg->working_sets = (gcov_ws_info_t *) malloc (
> +                          ws_cnt * sizeof (gcov_ws_info_t));
> +                    }
> +                }
> +              else if (cs_prg->num != cs_tprg->num
> +                       || ws_cnt != cs_prg->working_set_count)
> +                goto read_mismatch;
> +              /* Copy over this run's working set information if either this is
> +                 the first run, the total size of the profile (sum_all) is much
> +                 (50%) larger for this run (need to check this before updating
> +                 cs_prg->sum_all below), or this run has a larger working
> +                 set in the largest (99.99% of sum_all) bucket.  */
> +              if (ws_cnt
> +                  && (cs_prg->runs == 1
> +                      || (cs_tprg->sum_all
> +                          > (cs_prg->sum_all + cs_prg->sum_all / 2))
> +                      || (cs_tprg->working_sets[ws_cnt - 1].num_counters
> +                          > cs_prg->working_sets[ws_cnt - 1].num_counters)))
> +                memcpy (cs_prg->working_sets,
> +                        cs_tprg->working_sets,
> +                        ws_cnt * sizeof (gcov_ws_info_t));
>  	      cs_prg->sum_all += cs_tprg->sum_all;

Hmm, when you run i.e. gcc bootstrap  where the program is run couple hundred
times, this will end up really inaccurate, since it will probably just store
the histogram of insn-attrtab compilation, right?

Why you don't simply write the histogram into gcov file and don't merge the values
here (i.e. doing the cummulation loop in GCC instead of within libgcov)?
By default you are streaming 128 values that is the same as needed to stream the histogram.
I suppose we can have environment variable to reduce the histogram size - I guess in smaller
setups smaller histogram will run just fine...

Honza


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]