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 switch-conversion after profiling


> On Fri, Apr 20, 2012 at 11:24 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
> >> >
> >> > The original motivation to do switch conversion early was to get function
> >> > bodies smaller (i.e. when inlining the static var don't need duplication, the
> >> > switch code does)
> >> >
> >> > This was motivated by real world examples, i.e. mesa that inlines function converting
> >> > error codes into strings. At one point we estimated it to be of 0 size (because it
> >> > has only switch that was ignored and string constants that are zero cost) and we
> >> > ended up completely exploding by inlining it everywhere.
> >>
> >> Well, I never really believed this theory ;)
> >
> > :) It was a bug in the cost functions (it now has switch statement estimation code in it
> > for this reason), but anyway it shows that converting those kind of switch constructs
> > helps to get more inlining and code sharing.
> 
> Well, there are a lot of things that eventually lead to code size savings.  But
> in early opts we only want to do things that _always_ lead to code size savings.

Agreed, we should do only transforms that are win code size and performance wise.
But the switch conversion code does that (at least in the cases we speak about).

> And things that do not affect debugging (I'm still thinking of doing a -Og or
> re-doing -O1 to only do early opts - still having switch conversion in that set
> sounds odd).

Converting swtich to table lookup kills the statements in the case labels and degrade
debug info. But this is not too different from what copy propagation/DCE and other things
we definitely want in early opts does. It does not seem to be that disturbing for
debugger to me.

Honza
> 
> > Still it seems to me that we are mixing two essentially independent things - one is
> > set of recognizers for trivial switch constructs that can be easilly converted into
> > smaller and faster switch free code. This IMO makes sense to do early.
> >
> > Second is expanding switch constructs into decision trees (i.e. lowering) that
> > makes sense to be later after profile is built and code is resonably optimized.
> >>
> >> > I think we should retain this and perhaps have always win conversions done early
> >> > and real coversion (of switches to decision trees) done much later.
> >> > Switch expansion hides what the code really does and some of the late optimizers
> >> > will probably benefit from knowing that switch is really a switch.
> >> >
> >> > I would expect that somewhere before second VRP makes most sense.
> >>
> >> No, I think before loop opts it makes most sense as you can end up
> >> creating vectorizable code. ?After first VRP because such VRP can
> >> remove dead cases.
> >
> > Hmm, before loop opts it makes sense indeed.
> >>
> >> Richard.
> >>
> >> > Honza


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