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