------- Comment #55 from rguenth at gcc dot gnu dot org  2010-03-20 15:12 
-------
(In reply to comment #54)
> (In reply to comment #53)
> > > optimize_function_for_size_p (cfun) is true if attribute(cold) is set
> > > on it or we are optimizing for size.
> > 
> > It is what is presently implemented. As a consequence (illustrated by this 
> > pr),
> > optimize for speed is not obeyed if attribute(cold) is set on. I don't see 
> > the
> > interest of that: If I want optimization for speed, I just want it.
> > 
> > From comment #47, I got the impression that the intended behavior is the
> > following:
> > if optimized for size is on (-Os) then it is overridden if the block is 
> > marked
> > as "hot" (it is not clear for me that it is !attribute(cold)). From this
> > impression the truth table I expect is the following for
> > optimize_function_for_size_p:
> > 
> > "hot"        0      1
> > -Os         1      0
> > -O[1-3]  0     0
> > 
> > and not
> > 
> > "cold"       0    1
> > -Os          1    1
> > -O[1-3]  0    1
> > 
> > as presently implemented.
> 
> The intent is
> 
>            "hot" "cold" nothing
>   -Os        0      1     1
>   -O[1-3]    0      1     0
> 
> implemented is as far as I see
> 
>            "hot" "cold" nothing
>   -Os        1      1     1
>   -O[1-3]    0      1     0
> 
> thus optimize_function_for_{size,speed}_p fully correct for -O[1-3].

The issue is the || !crtl->maybe_hot_insn_p in optimize_insn_for_size_p
which boils down to !maybe_hot_frequency_p (bb->freq) which has at the
end

  if (freq < BB_FREQ_MAX / PARAM_VALUE (HOT_BB_FREQUENCY_FRACTION))
    return false;
  return true;

thus it really only tells if a frequency is hot or not, its negation
doesn't autmatically means its frequency is cold.

Thus, maybe_hot_bb_p should properly honor [!]optimize_size for the
default case where a bb is neither hot nor cold.

In the end this won't save us from the underlying issue in this PR
where frequency scaling makes blocks appear as cold when they are not,
simply due to the loop depth predictors (they should maybe be limited
to a loop depth of 3 or so).  And this is really Honza's area of
expertise (well, at least its all his code).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40106

Reply via email to