[PATCH, middle-end] Switch initializations conversion (take four)

[Mark Mitchell]

Martin Jambor wrote:

> since we are again in stage 1, I am re-submitting an improved the pass
> converting constant assignments in switch statements into assignments
> from a static array. 

Thank you.

> I know  that some  people were not  convinced about the  usefulness of
> this pass. I would therefore like to stress again that the overhead is
> very low  as it only  examines the last  statements of every BB  and I
> believe  Honza thinks  that  the improvements  for  inlining of  large
> switch initializations are substantial.  I have measured the number of
> conversions when  bootstrapping gcc some  time ago but I  somehow lost
> the results  but I remember they  were slightly better  than before. I
> will try to do that again soon.

Optimization is a quantitative question: the whole point is to make the 
program smaller, faster, etc.  So, all non-obvious optimization patches 
should come with quantitative information, in addition to qualitative 
information.

In particular, which benchmark(s), on which platform(s), with which 
flags did you use to measure improvement?  And how much improvement did 
you see?  And, what benchmark(s) on which platforms which which flags 
did you use to measure costs?  And how high were the costs?

For example, if you said "this patch makes CSiBE on ARM EABI with -Os 1% 
smaller" and "I measured the time required to build libstdc++ on ARM 
EABI with default flags with this patch and it made the compiler 
0.00001% slower", then that would be strongly compelling.  There might 
be some follow-up questions, but, without that kind of information it's 
hard to know whether we should invest further in the patch.

I hope that's not discouraging.  Personally, I think this is a good 
idea, and might be a big win on some codes.  Even if the benchmark is a 
single real-world application you have at hand -- rather than some 
well-known benchmark suite -- the patch might be worthwhile if the costs 
are low enough.  But, we need to have some quantitative information in 
order to evaluate it.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713