This is the mail archive of the
mailing list for the GCC project.
Re: [patch] Move switch-conversion after profiling
On Fri, Apr 20, 2012 at 11:24 AM, Jan Hubicka <email@example.com> 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.
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
> 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.
>> > Honza