[PATCH, 4.9/4.10] Profile based option tuning

[Jan Hubicka]

> I guess some optimizations are controlled only by "optimize_size", not
> by the profile.
> Other optimizations are controlled by the profile.
> So this patch does not have very much effectiveness (only 0.9% size reduction).

0.9% size reduction counts as very much in compiler developers perspective :).
Indeed not all optimizations have detailed size/speed gates - I basically
reviewed the compiler for places that seemed important to me.  I think the
proper fix would be to figure out from where the reduction comes from
and fix the offending pass.
Do you have any idea where you get the savings?

Honza

> 
> 2014-07-23 17:26 GMT+08:00 Richard Biener <richard.guenther@gmail.com>:
> > On Wed, Jul 23, 2014 at 2:39 AM, Pengfei Yuan <0xcoolypf@gmail.com> wrote:
> >> In the experiment, about 60% (1019/1699) profile data files are empty
> >> (all counters are zero).
> >
> > Well, but you are globally overriding options even for the parts with
> > profile.  The whole point of profile-feedback is to get at the interesting
> > parts (those with non-zero counters).
> >
> > What you say is that not enough parts of the compiler care for
> > the actual profiles and thus portions with all-zero counters are
> > treated as if they were hot?  Then better fix that.
> >
> > Richard.
> >
> >> 2014-07-22 21:39 GMT+08:00 Richard Biener <richard.guenther@gmail.com>:
> >>> On Mon, Jul 21, 2014 at 7:13 AM, Pengfei Yuan <0xcoolypf@gmail.com> wrote:
> >>>> Hi,
> >>>>
> >>>> This patch tunes optimization options based on profile data:
> >>>> * Disable PGO options if profile is not available or empty.
> >>>> * Optimize for size if profile is available but empty.
> >>>
> >>> Err ... these don't seem interesting cases to "optimize" for?
> >>>
> >>> Richard.