Re: Patch ping...

[Jan Hubicka <hubicka at ucw dot cz>]

> 
> I think the patch makes sense (BRANCH_COST is special anyway compared to
> other isns cost), but I'd like to see the bigger picture as well here.  In
> particular, BRANCH_COST (hot, predictable), why isn't that simply
> BRANCH_COST (optimize_size_p, predictable) matching what I possibly
> expect for the other cost interface (insn_cost (optimize_size_p, rtx)).

The reason is that I don't think current paradigm of optimize_size
variable and profile info is good combination.
We have maybe_hot_bb_p and probably_cold_bb_p that use CFG profile to
guess on hotness.  Their names suggest in what direction they are
conservative and it defaults to preferred -O2 behaviour (ie code tends
to be hot unless there is really good reason for otherwise).

I would like to have hot_bb_p predicate that take into accounts the
hints:
 1) hot/cold function attributes
 2) -Os versus optimize_size
 3) function local profile (ie things guarded with __builtin_expect or
 leading to abort)
 4) profile feedback
and decide on hotness.  With -Os defaulting to conservative behaviour
(ie function is hot only if attribute or profile feedback suggest so)
and -O2 defaulting to aggressive behaviour (function is hot if not
declared cold, function local profile is within bounds).

I see that hotness in 90% corelate with !optimize_size, but not in 100%
cases, especially in decision affecting the whole function or unit or
loop or so that might contain both hot and cold stuff.  So I think
hottness is more precise name for what is going on here.

Honza

> 
> Thanks,
> Richard.