On Sun, Jul 1, 2012 at 11:58 AM, Richard Guenther
<richard.guent...@gmail.com> wrote:
> We have to think about the point in the pass pipeline where we want to do
> this (and the rest of) lowering. At the moment switch-conversion runs before
> profile-data is read and thus cannot do a very good job. I think lowering
> somewhere early after IPA optimizations (inlining and then constant
> propagation might affect the optimal lowering?) might be most sensible?
I'd like to put switch lowering just before function splitting (the
profile version and also the non-profile version), because I think
(well, hope) that it will allow split-function to peel off the switch
case with the highest probability. For instance it'd be possible to
change:
func (...)
{
switch (x)
case many:
...
case cases:
...
case that:
...
case are:
...
case unlikely:
...
case hot:
...
}
to:
func (...)
{
if (x == hot)
...
else
func.part (...) // for the unlikely cases
}
For the same reason, I'd like to see Tom's branch-reorganization pass
just before function splitting. So far, I've found this to be a common
opportunity in GCC itself (with profile info on small switches only,
the ones that expand to bit tests -- it's the only part I have working
right now).
In general: IMHO, the sooner switch lowering and/or branch reordering
happens after reading back in profile information, the better, because
(a) the value profile information for branches tends to deteriorate
rather quickly (even cfg cleanups can invalidate it); (b) my branch
profilers tend to be quite large (one counter per range -- I'm still
trying to decide whether to make it a param or a magic number :-) and
if we use the profile info soon then we can drop the histograms soon
and save some memory; and (c) the switch lowering and branch
reordering transformations do not destroy any profile information
themselves.
I'd like to hear Tom and Honza's opinions, too, please! :-)
Ciao!
Steven
