This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Move lowering of switches to bit tests to GIMPLE


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]