On Fri, Apr 20, 2012 at 11:24 AM, Jan Hubicka <hubi...@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
