Martin Jambor wrote: > Well, there's mine :-) Specifically, its the "Switch initializations > conversion:" http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00215.html
Do you have an FSF copyright assignment on file? This patch is big enough that we would not be able to include it without that. > Jakub Jelinek had a few comments and I changed the patch according to > them. After that, nothing much happened. If any maintainer likes the > patch, please commit it as I do not have write access to svn. OTOH, if > there are any further concerns, please let me know. I see one technical change that should be made. In particular, please change: > +/* We never create arrays larger than the following constant (given in number > + of elements). */ > +#define MAX_ARRAY_RANGE 0x2000 > + > +/* We never create arrays if the number of branches is not at least the > range > + divided by the following constant. */ > +#define MAX_RANGE_BRANCH_RATIO 8 to use the --param mechanism. Our policy is to have *no* magic numbers for these kinds of things. It's easy enough to allow users to use --param to set the values, and that makes it easy for people (often the compiler developers themselves) to experiment with the values to help fine-tune the defaults. Other than that, the patch looks pretty good to me. However, I'd like a middle-end maintainer to review the patch. Ian, Diego, Roger, would one of you please take a look? Is there any reason to think this patch might generate worse code on some processors or in some modes? For example, while this patch seems it's definitely a code-size win for dense switch statements, do we need some kind of cost model to tell us whether it's a code-size win with less dense switch statements? Do we want want separate params when we're operating under -Os from when we're operating under -O2? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
