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.
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).

> 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]