This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Move lowering of switches to bit tests to GIMPLE
- From: Steven Bosscher <stevenb dot gcc at gmail dot com>
- To: Richard Guenther <richard dot guenther at gmail dot com>, Tom de Vries <Tom_deVries at mentor dot com>, Jan Hubicka <hubicka at suse dot cz>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 23 Jul 2012 21:59:54 +0200
- Subject: Re: [patch] Move lowering of switches to bit tests to GIMPLE
- References: <CABu31nOx_mcNrshBsKbzwvD9CFkHW4+vggBmCYzgdgoP9iButw@mail.gmail.com> <CAFiYyc23h+XfBTdDv8CM+RCStc1bUbghnu5tDvKs0Y6JX7AyKg@mail.gmail.com>
On Sun, Jul 1, 2012 at 11:58 AM, Richard Guenther
<richard.guenther@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